Обновить

Комментарии 23

с чего вдруг хватит? эксель еще всех переживет

Статья смешная, спасибо, но я не особо понял причин, по которой автор хочет отказаться от Excel. Скорость работы, долгое погружение разработчика в чужие скрипты, неоптимизированный бизнес-процесс? То есть понятно, что для данных существуют БД, но если нужно сделать что-то быстро и на коленке...

Автор указал на основные проблемы.

почти никогда эти файлы не выглядят так, что их можно без боли скормить pandas и сразу получить аккуратный DataFrame.

Думаю, многим знакома ситуация, когда:

  • таблица начинается где-то с 7-й строки

  • заголовок размазан на несколько рядов

  • названия колонок незначительно отличаются от файла к файлу

Другие частые проблемы:

  • перенос строки внутри ячейки;

  • пользователь вместо того, чтобы удалить столбец, решил скрыть его;

  • формулы, макросы, объединение ячеек и прочие продвинутые фичи, затрудняющие машиночитаемость.

Я в качестве быстрого решения предпочитаю CSV, который так же открывается в в Excel и LibreOffice. Чтобы с без лишних телодвижений открывалось на любом компьютере независимо от софта и языка ОС, использую Unicode little endian + BOM. Разделитель - точка с запятой (чтобы не кавычить запятые).

Ещё есть TSV, который удобнее читать и править в блокноте, но открытие в Excel требует лишних телодвижений.

Для более важных или более объёмных данных - только БД.

Если бы читали внимательно, то поняли суть проблемы: автор не предлагает отказываться от excel, автор предлагает без танцев с бубном простой способ парсить их

Ммм...

What Should I Do Instead?

Anything. I am begging you on my hands and knees, anything. Write a SQLite database on your local hard drive. Do some garbage in Python. Encode the data in binary using a series of pebbles on your front lawn. If necessary, I will personally call your manager and explain the problem. I will actually do this. It's easy, I swear. They're all definitely easier than being defenestrated, which is the only alternative I am offering.

автор коментария "Хватит использовать Excel." имеется ввиду.

  1. Ссылка на репозиторий битая

  2. Что насчёт объединённых ячеек? С ними есть какая-то логика работы? Например, если объединено несколько строк, повторять значение на каждой строке.

  3. Не пробовали использовать совместно с парсингом таблиц в PDF? Там тоже крайне весело.

Ссылку поправил, спасибо!

про объединенные ячейки пока не думал, запишу себе, спасибо за мысль)

С pdf тоже не работал, но подозреваю что можно реализовать provider :)

Я примерно в этом направлении и думал. Провайдер как раз потребуется, но не возникнет ли заморочек.

А то мне тут довелось парсить замороченную таблицу... было весело.

Хм, будет сложно, но вполне реально) либо по верху заголовок забрать, либо всю иерархию и накинуть валидаторы.

В теории сработает)

Актуально, как никогда. Сейчас собираю через базу аналитику рекламы и ботов, важно все эти тонны данных грузить в таблицу для дальнейшей визуализации и приходится использовать сложные app scripts. Пока строк десятки тысяч не вылажу за лимиты в 6 минут, но они уже приближаются в сотне.

Изучу вашу библиотеку, может найду какое-то решение для себя.

Спасибо!

Тут уже нужно какой нибудь питон использовать с пандас и нумпаем, и подобными библиотеками, а данные хранить в БД вроде Sqlite

Эксель при большом количестве данных начинает сильно тупить. Да и само взаимодействие с ним крайне неудобное

Лучше Excel никто не парсит Excel. Обратите внимание на скрытые строки, высоту строк, объединенные ячейки. Запишите свои действия в макрос Excel VBA. Спросите DeepSeek, как лучше решать поставленную задачу, максимально расписав требования.

Классная библиотека! Спасибо!

Много приходится парсить абсолютно разных Excel, тоже уже давно написали свою библиотеку, по функционалу следующее сделано (писали на .NET + Epplus и результаты льются в postgre):

  • Шаблоны загрузки пишет аналитик в конфиге JSON. Вынесли, чтобы не тратить время программистов на внесение данных в код;

  • Конфиг каждый содержит инфу - режим парсинга (у нас их несколько, так данные могут иметь сложную структуру); с какого листа читать, с какой строки/колонки, какое количество колонок, также содержит весь маппинг колонок excel на конечные поля БД;

  • Парсер выполняет два блока проверок: механические и логические. Набор проверок для каждой колонки также прописывается в конфиге флагами;

  • Механические проверки - контроль уникальности значений по колонке, проверка соответствия типов данных целевым, проверка на кириллицу/латиницу там где нужно, удаление непечатетаемых символов, удаление лишних пробелов там где нужно;

  • В механические проверки также входит нормализация данных - замены по справочнику (справочник ведётся в postgre) - меняются "штук" на "шт" и и.д., и замены на id, там где нужна совсем чистая нормализация;

  • Логические проверки - много всяких дополнительных правил нетиповых, которые сложно засунуть в конфиг;

  • Также пришлось решать много специфических вопросов касательно самого excel - сбросы фильтров, обработки ошибок в формулах, пересчет формул для книг где задан ручной расчет формул, работа с формулами, использующими промежуточные значения в таблицах, парсинг xlsb (пришлось использовать отдельную библиотеку Sylvan)

    Библиотека сэкономила кучу времени, так как внести изменения или добавить новый источник теперь занимает минут 20, при этом сам парсер трогать не надо, только поработать с конифгами и при необходимости с конечными таблицами в SQL.

Рекомендую сперва заливать в бд данные из Экселя as is так сказать. А все проверки, нормализации, удаления непечатетаемых символов и т.п. делать уже следующим шагом.

А то будет сложно понять почему в базе сейчас что-то не то что ожидается, в случае когда исходный эксель уже исчез/изменился/удалился/не доступен

соглашусь, мы уже почти пришли к этому - raw слой для записи первичных данных. единственное что пока сдерживает - большая волатильность части источников, когда колонки могут меняться местами, добавляться/удаляться - в таком случае при наличии "сырого" слоя, приходится помимо просто правки конфигов, еще пересоздавать "сырые" таблицы, и учитывать это в пайплайне - в каких периодах времени, какие виды таблиц использовать. а так для стабильных исходников - первичный слой вполне удобно.

Я делал похожую задачу для геймдизайнеров, для выгрузки json-конфигов игры из Excel/GoogleSheet.Только делал полностью универсальное решение.

Дизайнеры настраивают семантику синтаксиса прямо в документе Excel (чаще сразу в GoogleSheet), поддерживается неограниченный уровень вложенности (описывается семантикой).

Заполнение конфигов(20-30к строк) при ребалансе игры делается не неделю, а 15 минут).
Программистов к парсингу больше не привлекают, даже после изменения структуры конфигов/таблиц, дизы всё сами делают.

Если интересно вот ссылка на гитхаб (внутри есть инструкция как с этим работать)
https://github.com/saigor33/TableToJsonUniversalParser

Слышал у аналитиков "какую бы крутую талзу вы не испольовали" все равно на каком-то шаге есть эксель ;)

Спасибо за инструмент, поиграюсь.

Для .NET написал обертку над NPOI. Для python pandas, на мой взгляд, хватает. Тут если действительно поток кривых файлов надо обрабатывать, но в любом случае под каждый тип свой обработчик писать, хоть и с библиотекой.

Когда-то решал обратную задачу: красиво вывести DataFrame в Excel с учётом объединения ячеек и разбивки по страницам для печати. Сильно ускорило подготовку отчётов

У каждого своя головная боль. Я например как менеджер проекта по разделам энергетика, слаботочка вынужден иметь дело с десятками спецификаций и их сканов. Данные приходят в виде чего угодно. Как знаете проектировщики предпочитают свои спецификации не создавать в чем-то удобном, а напрямую рисовать в виде линий и фрагментов многострочного текста прямо в Автокад. Плюс еще логисты, бухгалтера и сметчики извращаются кто во что горазд. Поставщики тоже стараются.

Достал меня весь этот зоопарк и за вечер с помощью ии написал для себя библиотеку макросов для пользовательских команд. То что раньше занимало часы, теперь занимает минуты 4.

От эксель избавляться не нужно. Нужно просто правильно им пользоваться.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации