Есть ли жизнь после Microsoft Office?

Когда речь идет об автоматизации бизнес‑процессов, существенная часть разговора неизменно будет касаться использования офисного пакета. Есть такой интернет‑мем: гигантская конструкция, названная «финансовая система мира», тремя четвертями своего веса опирается на небольшую подпорку, названную «Excel». И пока все вокруг не заполонили рои интеллектуальных агентов, табличный редактор остается основным инструментом человека для обработки и представления структурированной информации. Вероятно, когда корабль человеческих возможностей начнет тонуть в океане данных, именно разнообразные электронные таблицы последними покинут палубу.

Эксель, ворд — это уже имена нарицательные, подобно ксероксу (Xerox Corporation — это название компании, а то, что мы называем «ксерокс» — это копир, это все знают). Исходя из контекста, под ними понимают как приложения офисных пакетов (Microsoft Office, “МойОфис”, «Р7-Офис» и др.), так и отдельные файлы. В быту, в «быстрых» переговорах, когда нужно донести мысль, это удобно. Но в технических или юридических документах требуется точность, там нельзя таблицу обозвать «экселькой». Однако это не самая большая проблема.

Но вот представим, что поезд импортозамещения на предыдущей станции под названием «Экосистема Microsoft — ОС Windows» на долго не остановился и во всю мощность своих тяговых электродвигателей пронесся к станции «Вселенная Unix — ОС Linux»: семейство операционных систем Windowsрано или поздно будет удалено с большинства российских компьютеров, следом в небытие отправится пакет MicrosoftOffice (поскольку без танцев с бубном под Linux он категорически не устанавливается, а в защищенной корпоративной среде даже этого бубна нет в наличии). Дойдет ли очередь до файлов — кто знает…

«А почему, собственно, до файлов должно быть кому‑то какое‑то дело?» — спросит скептически настроенный читатель. И вот это‑то и самое интересное.

До боли всем известные файлы с расширениями xlsx (xlsm), docx (docm) и pptx (pptm) частично базируются на серии форматов файлов для хранения электронных документов Office Open XML (OOXML). Но именно что «частично». В общих чертах эту историю можно изучить по ссылке. С той частью спецификации формата, которая открыта, можно ознакомиться здесь, но на свой страх и риск — там свыше 6,5 тыс. страниц. При этом надо помнить, что Microsoft не раскрыло «свою» часть спецификации. Таким образом, файлы OOXML — это если и не черный ящик, то совершенно точно не белый.

Более‑менее по монополии Microsoft “бьет” (в хорошем смысле) другой стандарт — OpenDocument Format (ODF), который «…был совместно и публично разработан различными организациями, доступен для всех и может быть использован без ограничений…», о нем можно почитать здесь. Спецификация формата: ссылка (тут с объемами дело обстоит попроще, «всего‑то» чуть больше 1 тыс. страниц). Этот формат уже несколько лет потихоньку пробирается в российские офисные системы и известен под масками файлов с расширениями ods, odt и odp. Да, в быту их еще называют по старому «экселями» и «вордами», а также «файлами МойОфис» или «файлами LibreOffice», хотя это файловые форматы, к приложениям жестко не привязанные.

«А нам‑то с этого какая печаль?» — спросит начинающий о чем‑то догадываться читатель. Все просто: у всех нас, у всей России есть Распоряжение Правительства РФ от 05.03.2022г. № 430-р, которым США отнесены к недружественным государствам. При этом не секрет, что компания Microsoft — это американская компания. А еще в России издан ГОСТ Р ИСО/МЭК 26300–2010, являющийся адаптацией версии 1.0 спецификации Open Document Format for Office Applications. Да, стандарт 2010 года, вступил в силу в 2011 году, охватывает версию 1.0 (текущая версия спецификации — 1.3, датируется 2021 годом), но уже что‑то, есть на что юридически опереться.

Если на одну чашу поместить частично закрытую спецификацию недружественной компании из недружественной страны, а на другую — полностью открытый формат, легализованный путем издания госстандарта, весы государственной информационной безопасности качнутся очевидно в какую сторону.

«Соль, соль‑то в чем?» — спросит нетерпеливый читатель. Казалось бы: ну не будет ОС Windows и Microsoft Office, взамен будет ОС на базе Linux и отечественный офисный пакет, возьми любой — умеет и с OOXML работать, и с ODF. Запретят первое — в моду войдет второе. Так в чем же дело? А все дело в автоматизации!

Не зря в самом начале был вспомнен мем про мировую финансовую систему и Excel. Если у всего остального мира особых проблем с Microsoft нет, то у России с недавних пор — выше крыши. Одним щелчком транслировать в другую экосистему всё, что автоматизаторы понаделали за последние пару‑тройку десятилетий, не получится. Грядет полноценная миграция с оформлением техзаданий и техпроектов, созданием команд и погонями за дедлайнами. Это как перенастраивать конвейер под выпуск новой модели автомобиля: одни расходы, прибыль видится где‑то за горизонтом. А в нашем случае даже модель не новая, старую бы суметь выпускать с тем же качеством…

В общем, профессиональный опыт осторожно просигнализировал о в некотором смысле неизбежном будущем без привычных и уже со многих сторон автоматизированных офисных приложений. Что мы сделали? Погрузились в репозиторий Python, изучили доступные модули, библиотеки, пакеты и фреймворки, связанные с разработкой ODF‑файлов. Другие языки программирования не исследовались. Изучение вопроса осуществлялось в ноябре 2025 года, поэтому если с тех пор где‑то что‑то годное «выстрелило» — это будет отличной новостью. Пока же, увы, все не очень хорошо. Настолько, что впору запасаться сердечными гликозидами. На всякий случай.

Что нам показалось важным в вопросах обработки табличных документов (файлов с расширением ods):

минимально приемлемая объектная модель (рабочая книга, рабочие листы, диапазоны, ячейки, диаграммы, формулы, последняя ячейка диапазона, стили) с сопутствующим набором методов (хотя бы уровня openpyxl);
чтение/запись данных;
чтение/запись параметров форматирования.

Какие инструменты обнаружились: pandas в связке с odfpy, собственно odfpy, pyexcel‑ods3 и плагин pyexcel‑odsr3, непосредственно pyexcel целиком, ezodf, odsgenerator, odsparsator, odfdo, tablib.

Что важно в обработке текстовых документов (файловое расширение odt):

своя объектная модель (документ, страницы, секции, абзацы, фрагменты (runs), стили, таблицы, диапазоны, ячейки) с соответствующими методами (целевой ориентир — python‑docx);
чтение/запись текстовых и табличных данных;
чтение/запись параметров форматирования и текста, и таблиц.

Что удалось найти: odfpy, odfdo, ezodf.

Тот случай, когда много — не значит хорошо. И даже, казалось бы, общие для табличных и текстовых документов odfpy, odfdo и ezodf полны сюрпризов и совершенно не спасают ситуацию: библиотеки редко обновляются (поддержка ezodf вообще прекращена с 2015 года); «рваный» функционал; мало примеров (odfpy, odfdo), причем некоторые не работают (как у odfdo); нет документации или она фрагментарная (присутствует только «быстрый старт» (quickstart)); нет своих объектов (в odfpy используется обход xml‑дерева; в pyexcel, odsgenerator и odsparsator — обычный питоновский словарь) или объектная модель недостаточна (odfdo).

Пожалуй, рабочей является только связка pandasи odfpy, позволяющая извлекать данные из ods‑файла и записывать фрейм данных обратно. При этом существует огромный пласт задач, требующих отформатированного вывода информации, который удобен человеческому глазу. Как известно, библиотека pandasдля этого не предназначена. Если автоматизированный процесс должен обеспечить подсветку одних значений зеленым, других — желтым, третьих — красным, то тут просто не с чем работать.

«И что тогда делать?» — спросит расстроенный читатель. Точного ответа нет. Наш вариант: если на вход автоматизированному процессу приходит ODF‑файл, то он с помощью одного из офисных приложений преобразуется в «рабочий» формат (xlsx/xlsm/docx), после чего обрабатывается с использованием pandas, openpyxl и python‑docx. Своего рода файловый адаптер‑конвертер. Но, конечно же, это не устраняет необходимость в инструменте для прямой работы с файлами ods и odt.

Таким образом, хотелось бы подсветить проблему автоматизации обработки ODF‑файлов в языке программирования Python с использованием открытого ПО и без задействования каких‑либо офисных приложений, а также обратить внимание на наш опыт: вполне вероятно, что весь путь исследования открытого ПО придется периодически повторять, пока не обнаружится что‑то приемлемое. Или же начать всерьез задумываться о разработке собственной библиотеки/модуля. Ну а что: тот же архив xml‑файлов, те же xml‑деревья, даже xml‑теги местами те же, да и спецификация у ODF выглядит попроще, чем у OOXML. А вот как перестать бояться и начать делать — это задача другой статьи.