Ms office

Compound File это довольно сложный универсальный бинарный формат файлов, лежащий в основе форматов офисных документов до MS Office 2007 (doc, xls, ppt, msg, ), отчасти MS Office 2007+ (например vbaProject.bin внутри xlsm) и других.
Под катом краткое описание как Compound File устроен внутри, которое, надеюсь, будет полезно как ликбез и поможет читателю лучше понимать что делают утилиты или про что пишут в статьях про CFB файлы.


Устройтсво CFB файла сильно напоминает устройство диска с FAT. Логически CFB хранит древовидную структуру объектов, подобную файловой системе с директориями (тип объекта в CFB STORE) и файлами (в CFB STREAM). Каждый объект имеет имя.
Весь файл разбит на сектора размером 512 байт для v3 и 4096 байт для v4. Это, на мой взгляд, главная разница между v3 и v4. Дальше цифры для примеров я буду приводить для v3 (и в скобках для v4). В начальном секторе хранится заголовок файла и начало таблицы DIFAT (см. ниже). Значение содержимого других секторов определяется динамически по таблицам DIFAT и FAT (да, она прям так и называется, как в файловой системе), фиксированных значений сектор n содержит информацию типа t больше нет.
Всего максимум может быть 0xFFFFFFFA секторов. Номера секторов больше 0xFFFFFFFA являются маркерами и фактически ни на какой сектор не указывают. Например 0xFFFFFFFE (EndOfChain) означает, что текущий сектор последний в списке.

DIFAT

DIFAT Double Indirection File Access Table. Это массив 4х байтных номеров секторов, в которых находится FAT. Первые 109 записей хранятся в первом секторе файла (пять из них выделены жёлтым внизу КДПВ). Если файл больше 6.8 Мбайт (436 Мбайт для v4), то следующие сектора DIFAT хранятся как односвязный список. Номер первого сектора из этого списка хранится в заголовке. В кажом из этих секторов хранится 127 (1023) указателей на сектора с FAT, а в последних 4х байтах номер следующего сектора DIFAT.

FAT

FAT File Access Table. Это массив из 4х байтных значений. Работает так же, как в одноимённой файловой системе. Каждому сектору в файле (кроме заголовочного) соответствует 4х байтное значение в FAT.
Для чтения потока данных (STREAM) нужно знать длину потока (в байтах) и номер первого сектора этого потока. Номер следующего сектора всегда записан в элементе FAT, соответствующем текущему сектору. В элементе FAT, соответствующем последнему сектору в потоке, будет записано значение 0xFFFFFFFE (EndOfChain).

Directory

Это структура, которая хранит информацию обо всех остальных объектах в файле, аналог структуры каталогов. Сама она хранится в виде потока данных, длина и первый сектор которого записаны в заголовке файла. Представляет из себя массив 128 байтных записей. Каждая запись соответствует хранимому объекту. Объекты в directory имеют имя и бывают 4х видов:

1. ROOT корень дерева каталогов. В directory хранится в элементе 0, имя всегда Root Entry. По сути является директорией, но хранит информацию о потоке данных с MiniStream (см. ниже).
2. STORE директория. Логически является вместилищем других объектов типа STORE или STREAM. Физически дочерние объекты хранятся в виде списка (ещё точнее чёрно-красного дерева), а в STORE хранится указатель на один из дочерних объектов. Никакой поток данных к STORE не прицеплен, но есть ClSid GUID приложения, к которому относится содержимое этой директории.
3. STREAM файл. Хранит информацию о потоке данных (первый сектор и длина); дочерних объектов и ClSid нет.
4. UNKNOWN пустой объект. Запись, (почти) забитая 0, чисто технически нужна для дополнения списка Directory до длины, кратной длине сектора.

У каждого объекта есть временные метки: время создания и время модификации, правда часто они просто заполнены 0.
Пример дерева директорий небольшого doc файла:
Root_storage:Root Entry 06090200-0000-0000-c000-000000000046
- Stream:\x01CompObj[106]
- Stream:\x01Ole[20]
- Stream:1Table[4640]
- Stream:Data[374]
- Stream:\x05SummaryInformation[172]
- Stream:WordDocument[198510]
- Storage:ObjectPool 00000000-0000-0000-0000-000000000000
- Stream:\x05DocumentSummaryInformation[116]

MiniStream и MiniFAT

В принципе описанного выше достаточно для хранения данных, но в CFB предусмотрена ещё оптимизация для хранения коротких потоков данных меньше 4096 байт.
При хранении потока данных, длина которого не кратна длине сектора, в последнем секторе остаётся некоторое количество неиспользуемых байт. Чем больше сектор тем больше таких байт в среднем остаётся. Для борьбы с этой проблемой все небольшие (меньше 4096 байт) потоки данных хранятся не в обычных секторах по 512 (4096) байт и FAT, а в отдельном потоке, разбитом на сектора по 64 байта. Этот поток называется MiniStream, а информация для сцепления его секторов в потоки хранится в MiniFAT. Работает это всё совершенно аналогично основной FAT.
И MiniFAT, и MiniStream хранятся как обычные (не Mini) потоки данных. Номер первого сектора и длина MiniFAT хранятся в заголовке, а информация о MiniStream в объекте Root Entry (логической причины хранить именно там не вижу).
Получается такая матрёшка: файл разделён на 512 (4096) байтные сектора, а один из потоков, состоящих из этих секторов, рассматривается как последовательность 64 байтных секторов, и в нём уже хранятся мини потоки данных.
Откуда читать поток данных: из большой FAT или из MiniStream, определяется только по его размеру (меньше 4096 из MiniStream, иначе как обычный поток).

Где же текст/картинка/таблица/макрос?

CFB используется как хранилище, позволяющее сохранить данные разных приложений в одном файле. Если вы хотите докопаться до человекочитаемых данных, то надо парсить потоки данных, извлечённые из CFB, в соответствии с форматом данных приложения. Эта тема выходит за пределы данной статьи (но см. ссылки).

Выводы

По идее такая структура файла была разработана для ускорения внесения отдельных изменений в файл без его полной перезаписи. Не думаю, что это свойство ценно сейчас для обычных офисных документов размером несколько мегабайт.
В общем структура файла CFB просто кладезь для стеганографии, основанной на формате файла. Т. е. сделать совершенно корректный файл, который при открытии в ворде покажет Hello world, а внутри будет ещё много, которые правильный парсер будет считать просто мусором вообще не проблема.
С другой стороны огромный простор для ошибок, путаницы и т.п., огромное количество избыточных записей. Например, можно зациклить цепочку секторов, образующую поток. Наивный парсер при чтении такого файла зависнет.
P.S. Файлы MS Office 2007 и старше (docx, xlsx, pptx, docm,) имеют совершенно другой формат. Внутри там тоже дерево директорий, только вместо CFB там используется ZIP (да, их можно прям раззиповать). Однако макросы, например, хранятся внутри документа в файле vbaProject.bin, который является Compound файлом.

Ссылки

• Сам CFB очень хорошо (на мой взгляд) документирован: [MS-CFB]: Compound File Binary File Format
• [MS-DOC]: Word (.doc) Binary File Format для тех, кто хочет полноценно разобрать doc.
• [MS-OVBA]: Office VBA File Format Structure о том, как хранятся макросы, в том числе в Office 2007+ (docm, xlsm, ...)
• Ещё пара статей на Хабре про парсинг DOC от Rembish:
  Текст любой ценой: WCBFF и DOC и Текст любой ценой: Miette
  
• Для практического анализа файлов MS Office (как до 2007 Офиса, так и после), в том числе подозрительных, рекомендую набор утилит OleTools. Их можно использовать и как отдельные программы, и как модули Python.
• Ещё полезный набор утилит OleDump
• CFB extractor, появившийся в процессе написания этой статьи. Из полезного умеет доставать из CFB файла все потоки данных (включая потоки, не имеющие соответствующей записи в директории).

Продолжаю свой цикл статей, посвященный конвертации различных текстовых файлов с помощью решений, реализованных на языке C#.

С момента моей последней публикации Конвертация xls в xlsx и xml на C# прошло более полугода, за которые я успел сменить как работодателя, так и пересмотреть свои взгляды на некоторые аспекты коммерческой разработки. Сейчас, работая в международной компании с совершенно иным подходом к разработке ПО (ревью кода, юнит-тестирование, команда автотестеров, строгое соблюдение СМК, заботливый менеджер, очаровательная HR и прочие корпоративные плюшки), я начинаю понимать, почему некоторые из комментаторов интересовались целесообразностью предлагаемых мной велокостылей, когда на рынке есть очень достойные готовые решения, например, от e-iceblue. Но давайте не забывать, что ситуации бывают разные, компании тем более, и если потребность в решении какой-то задачи с использованием определенного инструментария возникла у одного человека, то со значительной долей вероятности она возникнет и у другого.

Итак, дано:

1. Неопределенное множество файлов в формате .doc, которые нужно конвертировать в xml (например, для парсинга и организации автоматизированной навигации внутри текста), желательно с сохранением форматирования.
2. На сервере памяти чуть больше, чем у рыбки, а на процессоре уже можно жарить яичницу, да и у компании нет лишней лицензии на Word, поэтому конвертация должна происходить без запуска каких-либо офисных приложений.
3. Сервис должен быть написан на языке C# и в последующем интегрирован в код другого продукта.
4. На решение задачи два дня и две ночи, которые истекли вчера.

Поехали!

• Во-первых, нужно сразу уяснить, что старые офисные форматы файлов, такие как .doc и .xls, являются бинарными, и достать что-нибудь человекочитаемое из них без использования текстовых редакторов/процессоров не получится. Прочитать об этом можно в официальной документации. Если есть желание поковыряться поглубже, посчитать нолики с единичками и узнать, что они означают, то лучше сразу перейти сюда.
• Во-вторых, несмотря на наличие бесплатных решений для работы с .doc, большинство из них написаны на Python, Ruby и чем угодно еще, но не C#.
• В-третьих, найденное мной решение, а именно библиотека b2xtranslator, является единственным доступным бесплатным инструментом такого рода, еще и написана при поддержке Microsoft, если верить вот этому источнику. Если вдруг вы встречали какие-нибудь аналоги данной библиотеки, пожалуйста, напишите об этом в комментариях. Даже это душеспасительное решение не превратит .doc в .xml, однако поможет нам превратить его в .docx, с которым мы уже умеем работать.

Довольно слов давайте к делу

Установка b2xtranslator

Для работы нам понадобиться библиотека b2xtranslator. Ее можно подключить через менеджера пакетов NuGet.

Однако я настоятельно рекомендую скачать ее из официального git-репозитория по следующим причинам:

• a) Библиотека представляет собой комбайн, работающий с различными бинарными офисными документами (.doc, .xls, .ppt), что может быть избыточным
• b) Проект достаточно долго не обновляется и вам, возможно, придется доработать его напильником
• c) Задача, с которой я столкнулся, как раз потребовала внесения некоторых изменений в работу библиотеки, а также изучения ее алгоритмов и используемых структур для успешной интеграции в свое решение
  Для дальнейшей работы нам понадобиться подключить в свое решение два проекта из библиотеки: b2xtranslator\Common\b2xtranslator.csproj и b2xtranslator\Doc\b2xtranslator.doc.csproj

Конвертация .doc в .docx

Конвертация документов строится по следующему алгоритму:

1. Инициализация дескриптора для конвертируемого файла.
   Для этого необходимо создать экземпляр класса StructuredStorageReader, конструктор которого в качестве аргумента может принимать или путь до файла, или последовательность байтов (Stream), что делает его крайне удобным при работе с файлами, загружаемыми по сети. Также обращаю внимание, что так как библиотека b2xtranslator является комбайном для конвертации бинарных офисных форматов в современный OpenXML, то независимо от того, какой формат мы хотим конвертировать (.ppt, .xls или .doc) инициализация дескриптора всегда будет происходить с помощью указанного класса (StructuredStorageReader).
   

   StructuredStorageReader reader = new StructuredStorageReader(docPath);
   

2. Парсинг бинарного .doc файла с помощью объекта класса WordDocument, конструктор которого в качестве аргумента принимает объект типа StructuredStorageReader.
   

   WordDocument doc = new WordDocument(reader);
   

3. Создание объекта, который будет хранить данные для файла в формате .docx.
   Для этого используется статический метод cs public static WordprocessingDocument Create(string fileName, OpenXmlPackage.DocumentType type) класса WordprocessingDocument. В первом аргументе указываем имя нового файла (вместе с путем), а вот во втором мы должны выбрать тип файла, который должен получиться на выходе:
   a. Document (обычный документ с расширением .docx);
   b. MacroEnabledDocument (файл, содержащий макросы, с расширением .docm);
   c. Template (файл шаблонов word с расширением .dotx);
   d. MacroEnabledTemplate (файл с шаблоном word, содержащий макросы. Имеет расширение .dotm).
   

   WordprocessingDocument docx = WordprocessingDocument.Create(docxPath, DocumentType.Document);
   

4. Конвертация данных из бинарного формата в формат OpenXML и их запись в объект типа WordprocessingDocument.
   За выполнение указанной процедуры отвечает статический метод
   

   public static void Convert(WordDocument doc, WordprocessingDocument docx)
   

   
   

   класса Converter, который заодно и записывает получившийся результат в файл.
   

   Converter.Convert(doc, docx);
   

   
   

   В результате у вас должен получиться вот такой код:
   

   using b2xtranslator.StructuredStorage.Reader;using b2xtranslator.DocFileFormat;using b2xtranslator.OpenXmlLib.WordprocessingML;using b2xtranslator.WordprocessingMLMapping;using static b2xtranslator.OpenXmlLib.OpenXmlPackage;namespace ConverterToXml.Converters{    public class DocToDocx    {        public void ConvertToDocx(string docPath, string docxPath)        {            StructuredStorageReader reader = new StructuredStorageReader(docPath);            WordDocument doc = new WordDocument(reader);            WordprocessingDocument docx = WordprocessingDocument.Create(docxPath, DocumentType.Document);            Converter.Convert(doc, docx);        }    }}
   

   
   

   Внимание!
   Если вы используете платформу .Net Core 3 и выше в своем решении, обратите внимание на целевые среды для подключенных проектов b2xtranslator. Так как библиотека была написана довольно давно и не обновляется с 2018 года, по умолчанию она собирается под .Net Core 2.
   Чтобы сменить целевую среду, щелкните правой кнопкой мыши по проекту, выберите пункт Свойства и поменяйте целевую рабочую среду. В противном случае вы можете столкнуться с проблемой невозможности конвертации файлов .doc, содержащих в себе таблицы.
   Я не стал разбираться, почему так происходит, но энтузиастам могу подсказать, что причину стоит искать в 40 строчке файла ~\b2xtranslator\Doc\WordprocessingMLMapping\MainDocumentMapping.cs в момент обработки таблицы.
   Кроме того, рекомендую собирать все проекты и само решение под 64-битную платформу во избежание всяких непонятных ошибок.

   
   
   

   Сохранение результата в поток байтов

   
   

   Так как моей целью при использовании данного решения была конвертация .doc в .xml, а не в .docx, предлагаю вовсе не сохранять промежуточный OpenXML файл, а записать его в виде потока байтов. К сожалению, b2xtranslator не предоставляет нам подходящих методов, но это довольно легко исправить:
   В абстрактном классе OpenXmlPackage (см. ~\b2xtranslator\Common\OpenXmlLib\OpenXmlPackage.cs) давайте создадим виртуальный метод:

   
   

   public virtual byte[] CloseWithoutSavingFile(){    var writer = new OpenXmlWriter();    MemoryStream stream = new MemoryStream();    writer.Open(stream);    this.WritePackage(writer);    writer.Close();    byte[] docxStreamArray = stream.ToArray();    return docxStreamArray;}
   

   
   

   По большому счету, данный метод будет заменять собой метод Close(). Вот его исходный код:

   
   

   public virtual void Close(){     // serialize the package on closing    var writer = new OpenXmlWriter();    writer.Open(this.FileName);    this.WritePackage(writer);    writer.Close();}
   

   
   

   Скажем спасибо разработчикам библиотеки за то, что не забыли перегрузить метод Open(), который может принимать или имя файла, или поток байтов. Однако, библиотечный метод Close(), который как раз и отвечает за запись результата в файл, вызывается в методе Dispose() в классе OpenXmlPackage. Чтобы ничего лишнего не поломать и не заморачиваться с архитектурой фабрик (тем более в чужом проекте), я предлагаю просто закомментировать код внутри метода Dispose() и вызвать метод CloseWithoutSavingFile(), но уже внутри нашего метода после вызова Converter.Convert(doc, docx).
   Для сохранения результата конвертации вызываем вместо docx.Close() метод docx.CloseWithoutSavingFile():

   
   

   public MemoryStream ConvertToDocxMemoryStream(Stream stream){    StructuredStorageReader reader = new StructuredStorageReader(stream);    WordDocument doc = new WordDocument(reader);    var docx = WordprocessingDocument.Create("docx", DocumentType.Document);    Converter.Convert(doc, docx);    return new MemoryStream(docx.CloseWithoutSavingFile());}
   

   
   

   Теперь библиотека b2xtranslator будет возвращать сконвертированный из формата .doc в .docx файл в виде потока байтов. Даже если у вас нет цели получить на выходе .xml, такой метод может оказаться более подходящим для дальнейшей работы с файлами, тем более что стрим всегда можно сохранить в виде файла там, где вам надо.
   Для тех, кому все-таки очень хочется получить на выходе .xml документ, еще и с сохраненной структурой, предлагаю дойти до кухни, сварить кофе покрепче, добавить в него рюмку коньяка и приготовиться к приключению на 20 минут.

   
   

   Конвертация .doc в .xml

   
   

   

   
   

   Теперь, когда, казалось бы, можно воспользоваться классом-конвертором DocxToXml, работа которого была описана вот в этой статье, нас поджидает сюрприз, связанный с особенностями работы b2xtranslator.
   Давайте посмотрим на результат работы библиотеки повнимательнее и сравним с оригинальным .docx файлом, из которого был экспортирован .doc файл для конвертации. Для этого достаточно изменить расширение сравниваемых файлов с .docx на .zip. Вот отличия, которые мы увидим, заглянув внутрь архивов:

   
   
   1. В результате конвертации в новом .docx файле (справа) отсутствуют папки customXml и docProps.
      
   2. Внутри папки word, мы также найдем определенные отличия, перечислять которые я, конечно же, не буду:
      
   3. Естественно, что и метаданные, по которым осуществляется навигация внутри документа, также отличаются. Например, на представленном скрине и далее оригинальный .docx слева, сгенерированный b2xtranslator cправа.
      
      Налицо явное отличие в атрибутах тега w:document, но этим отличия не заканчиваются. Всю "мощь" библиотеки мы ощутим, когда захотим обработать списки и при этом:
      a. Сохранить их нумерацию
      b. Не потерять структуру вложенности
      c. Отделить один список от другого
   
   

   Давайте сравним файлы document.xml для вот этого списка:

   
   

   1.1 Первый.Первый1.2 Первый.Второй1.2.1   Первый.Второй.Первый1.2.2   Первый.Второй.ВторойКакая-то строчка 1.2.3   Первый.Второй.Третий2.  Второй2.1 Второй.Первый
   

   
   

   Вот так будет выглядеть .xml для первого элемента списка.
   

   
   

   -Во-первых, мы видим, что сама структура документов несколько отличается (например, точка внутри строк рассматривается как отдельный элемент, что, как оказалось, совсем не страшно).
   -Во-вторых, у тегов остался только один атрибут (w:rsidR), а вот w:rsidR, w14:textId, w:rsidRDefault, w:paraId и w:rsidP пропали. Все эти особенности приводят к тому, что наш класс-конвертер DocxToXml(про него подробно можно почитать здесь) подавится и поднимет лапки вверх с ошибкой NullReferenceException, что указывает на отсутствие индексирования параграфов внутри документа.
   
   Вместе с тем, если мы попытаемся такой файл отрыть в Word, то увидим, что все хорошо отображается, а таблицы и списки покоятся на своих местах! Магия!
   В общем, когда в поисках решения я потратил N часов на чтение документации, мои красные от дебагера глаза омылись горькими слезами, а один лишь запах кофе стремился показать коллегам мой дневной рацион, решение было найдено!
   Исходя из документации к формату doc и алгоритмов работы b2xtranslator, можно сделать вывод, что исторически в бинарных офисных текстовых документах отсутствовала индексация по параграфам*. Возникает задача расставить необходимые теги в нужных местах.
   За индекс параграфа отвечает атрибут тега paraId, о чем прямо написано здесь. Данный атрибут относится к пространству имен w14, о чем можно догадаться при изучении document.xml из архива .docx. В принципе, на скринах выше вы это тоже видите. Объявление пространства имен в .xml выглядит так:

   
   

   xmlns:wp14="http://personeltest.ru/away/schemas.microsoft.com/office/word/2010/wordprocessingDrawing"
   

   
   

   Теперь давайте заставим b2xtranslator добавлять это пространство имен и идентификатор каждому параграфу. Для этого в файле ~\b2xtranslator\Common\OpenXmlLib\ContentTypes.cs после 113 строки добавим вот эту строчку:

   
   

   public const string WordprocessingML2010 = "http://schemas.microsoft.com/office/word/2010/wordml";
   

   
   

   Кстати, если посмотрите на комментарии в коде, то увидите, что в этом блоке как раз располагаются поддерживаемые пространства имен для вордовых документов:
   
   Далее наша задача заставить библиотеку вставлять в начало файла ссылку на данное пространство имен. Для этого в файле ~\b2xtranslator\Doc\WordprocessingMLMapping\MainDocumentMapping.cs в 24 строке вставим код:

   
   

   this._writer.WriteAttributeString("xmlns", "w14", null, OpenXmlNamespaces.WordprocessingML2010);
   

   
   

   Разработчики библиотеки также позаботились о документации:
   

   
   

   Теперь дело за малым заставить b2xtranslator индексировать параграфы. В качестве индексов предлагаю использовать рандомно сгенерированные GUID может быть, это несколько тяжеловато, но зато надежно!
   
   Переходим в файл ~\b2xtranslator\Doc\WordprocessingMLMapping\DocumentMapping.cs и в 504 и 505 строки вставляем вот этот код:

   
   

   this._writer.WriteAttributeString("w14", "paraId", OpenXmlNamespaces.WordprocessingML2010, Guid.NewGuid().ToString());            this._writer.WriteAttributeString("w14", "textId", OpenXmlNamespaces.WordprocessingML2010, "77777777");
   

   
   

   Что касается второй строчки, в которой мы добавляем каждому тегу параграфа атрибут w14:textId = "77777777", то тут можно лишь сказать, что без этого атрибута ничего работать не будет. Для пытливых умов вот ссылка на документацию.
   Если серьезно, то, как я понимаю, атрибут используется, когда текст разделен на разные блоки, внутри которых происходит индексация тегов, которые могут иметь одинаковый Id внутри одного документа. Видимо, для этих случаев используется дополнительная индексация текстовых блоков. Однако, так как мы используем GUID, который в несколько раз больше индексов, используемых в вордовских документах по умолчанию, то генерацией отдельных индексов для текстовых блоков можно и пренебречь.

   
   

   Вот теперь мы получили .docx-файл, пригодный для дальнейшего преобразования в .xml. Подробнее о том, как работать с ним дальше, вы можете прочитать в этой статье или воспользоваться уже выложенным на github решением.
   

   
   

   В заключение, если у вас на проекте есть возможность воспользоваться платным надежным софтом, то этот путь скорее всего не для вас. Однако же, если вы энтузиаст, пишете свой pet-проект и уважительно относитесь к авторским правам, а также если ваш проект находится в стадии прототипирования и пока не готов к покупке дорогостоящих лицензий, а разработку продолжать надо, то, мне кажется, этот вариант может вам очень даже подойти! Тем более, что у вас есть возможность воспользоваться готовым решением и не заливать свои краснющие зенки визином, изучая документацию и особенности работы некоторых, на первый взгляд, сомнительных решений.

   
   

   Наконец, бонус для тех, кто хочет разобраться, что значат все эти бесконечные теги и их атрибуты в документах .docx и как они мапаются на бинарный .doc: советую заглянуть в файл ~\b2xtranslator\Doc\DocFileFormat\CharacterProperties.cs, а также посмотреть спецификацию для docx и doc.

Так или иначе, свободное программное обеспечение всегда конкурирует с проприетарным, явно или скрыто. Даже если сами авторы свободных программ не противопоставляют их закрытому софту, конкуренция идет в головах пользователей, которые выбирают платные программы или их бесплатные аналоги. Не один десяток лет с переменным успехом идут горячие баталии между сторонниками открытого и закрытого программного обеспечения: Linux против Windows, Gimp против Photoshop и, конечно же, OpenOffice/Libreoffice против Microsoft Office.

В этой статье я сделал обзор текущей ситуации противостояния офисных пакетов, рассказал про опыт крупных организаций, которые пытались перейти на бесплатные офисные пакеты (и почему у них ничего не вышло), а также о грязных способах Microsoft продвинуть свое ПО через взятки.

Немного истории

Почти всегда свободный софт выступает в роли догоняющего. Необязательно из-за того, что платный софт выпускается раньше (хотя чаще всего так и происходит), просто компании, выпускающие платные программы, намного крупнее и богаче, чем энтузиасты freeware и могут позволить себе большие бюджеты на продвижение своих продуктов.

OpenOffice имеет древнего предшественника StarOffice. Он был выпущен в 1985 году компанией Star Division, основанной немецким подростком Марко Беррисом, когда ему было всего 16 лет. Стив Джобс и Билл Гейтс были гораздо старше, когда они основали свои империи! Естественно, силы были неравны, потому что в 1990 году Microsoft была уже крупной и успешной компанией. Сразу после выпуска Windows 3.0 одна только недельная прибыль составила больше 100 000 долларов. Глобально конкурировать с гигантом Билла Гейтса было нереально, но в 1997 году на своей родине продукт Марко завоевал четверть рынка офисного программного обеспечения за счет меньшей цены (Word и Excel тогда стоили примерно по 50 долларов).

Забавный факт: до того, как офисный пакет Microsoft Word стал доминирующим на рынке, в конце 80-х и начале 90-х самым популярным был WordPerfect, и цена на него была около 150 долларов. Конкуренция положительно сказывается на ценах, пока какая-нибудь компания не добивается монополии.

На волне успеха, в 1998 году, Марк делает офисный пакет бесплатным для личных целей, а через год продает свою компанию Sun Microsystems, которая в свою очередь делает StarOffice бесплатным, но уже и для коммерческого использования. В 2000 году был открыт исходный код офисного пакета, и началась история проекта OpenOffice.org. В 2010 году Sun Microsystems была поглощена Oracle, а немного позднее из-за разногласий в политике управления проект разделился на OpenOffice, который берет под крыло фонд Apache, и LibreOffice, развиваемый The Document Foundation. Различия в этих пакетах не настолько велики, как между ними обоими и Microsoft, поэтому дальше речь пойдет преимущественно про OpenOffice.

Microsoft всегда славилась агрессивной политикой продвижения своих продуктов. Огромное количество денег позволяло сильно демпинговать на рынке программного обеспечения и разорять конкурентов. Кроме того, софтверный гигант никогда не стеснялся грязной игры, их торговые представители щедро раздавали взятки и откаты чиновникам, которые принимали решения о внедрении программных продуктов в частных компаниях и государственных организациях. Ответственные лица закупали программные продукты у Microsoft со скидками до 30%, а государству продавали уже по полной цене, прикарманивая разницу. Ходят слухи, что в МТС в 2012 году не просто так стали рекламировать Windows Phone вместо iPhone. В 2013 году разразился скандал: Microsoft взятками продвигала свое программное обеспечение в России, Пакистане, Китае и странах Восточной Европы. До суда дело снова не дошло, но шум был поднят изрядный. Подавляющее большинство подобных нарушений не получается довести до суда, потому что богатая компания успевает обрубить хвосты и подчистить за собой грязь, но в 2019 году ей пришлось выплатить 25 миллионов долларов за досудебное урегулирование дела о коррупции.

Понятно, что фонды, поддерживающие разработку свободного программного обеспечения, не могут позволить себе подобную политику продвижения, как по этическим соображениям, так и финансово. Потому им невероятно сложно выдерживать конкуренцию с софтверным гигантом. Фактически благодаря стараниям Microsoft пакет Microsoft Office стал стандартом для делопроизводства во всем мире. Судебные иски никак не изменили этот факт, а выплачиваемые штрафы и прочие судебные расходы пренебрежимо малы по сравнению с прибылью компании.

Проблемы совместимости, постепенная эволюция

Исходя из сказанного выше, становится понятно, что, если программный пакет позиционируется как конкурент Microsoft Office, ему, волей-неволей, придется обеспечивать совместимость с документами Microsoft, иначе им никто не будет пользоваться. Но в пакете Microsoft Office используется проприетарные форматы файлов. Вплоть до 2008 года, когда под давлением ISO Microsoft была вынуждена открыть форматы своих файлов на условиях FRAND, сторонние офисные программы были вынуждены обеспечивать совместимость с файлами Microsoft Office с помощью реверс инжиниринга. Естественно, это не могло обеспечить полной совместимости и сильно мешало распространению альтернатив. Более того, в опубликованных спецификациях есть много белых пятен, из-за чего даже сейчас все еще нет полной совместимости между Microsoft Office, Libreoffice и OpenOffice.

Кроме того, форматы файлов Microsoft Office очень долго несли на себе бремя обратной совместимости со старыми версиями, которые были чрезвычайно сложными. Открытая документация только на один формат Excel 97-2003 содержит несколько сотен страниц! Из-за этого казалось, что файлы намеренно запутаны и созданы сумасшедшими программистами. Но это не совсем так. Форматы файлов настолько сложны для того, чтобы можно было обеспечить быструю работу с ними на очень старых и медленных компьютерах, даже при большом объеме данных. Ранние версии Microsoft Office были рассчитаны на работу машин с процессорами Intel 386 и всего 1 Мб оперативной памяти, а большие документы приходилось редактировать уже тогда. Потому документ был чем-то вроде контейнера с внутренней файловой системой, очень похожей на Microsoft-DOS, с таблицей разделов, секторами и файлами, содержащими отдельные части документа. Это было необходимо для обеспечения быстрой работы с данными. Например, в пакете версии 95-97 была команда Fast save, которая позволяя делать инкрементальные сохранения, не перезаписывая весь документ, а добавляя изменения в конец файла.

Еще одна причина сложности формата поддержка составных документов, которая позволяет встраивать в один документ часть из другого документа как объекта OLE, например, таблицу из Excel в документ Word, которая будет обновляться, когда изменится файл таблицы.

В работе над пакетом Microsoft Office, чтобы он имел все современные возможности входящих в него программ, были потрачены тысячи человеко-часов компанией, которая имела достаточно средств, чтобы нанимать высококвалифицированных инженеров. Увы, но команды, разрабатывающие OpenOffice и Libreoffice, намного меньше. При том, что нельзя реализовать только 20% самого популярного функционала и надеяться, что 80% пользователей будут довольны вашей программой. Хороший пример Google Docs, при работе с которым иногда очень не хватает возможностей Microsoft Word, не реализованных в облачном редакторе. Потому перед разработчиками конкурентов Microsoft Office стоит практически непосильная задача, с которой они почти справляются. В течении многих лет постепенно были решены многие проблемы совместимости, но перечислим те, которые еще остались и могут представлять проблемы (в основном, на примере OpenOffice):

• Очень долгое время была проблема с графиками и диаграммами, созданными в программе Excel. Если файл Excel открывался в Calc, то часть графиков слетала, а если добавить графики программой Calc, то наоборот они слетали при открытии файла в Экселе. Эта проблема не решена полностью до сих пор. Например: круговая диаграмма и диаграмма пирог из Excel (Calc преобразует в 2D-столбцы), невозможность повернуть ось, в частности, чтобы Y внизу была положительной, отсутствие бухгалтерского формата с символом валюты у левого края ячейки.
• Если в компании практикуется совместное редактирование документов, которые лежат на общем сервере, то перейти на OpenOffice будет сложно или невозможно. Документ, открытый по сети одним пользователем, будет доступен другим только для чтения, а кнопка Редактировать документ, скорее всего, создаст локальную копию.
• В Calc можно обеспечить совместное редактирование, хоть и с некоторыми ограничениями (нельзя удалять и добавлять строки и столбцы). Для решения этой проблемы во Writer надо создать специальный файл типа Составной документ, который придется экспортировать, чтобы потом его мог открыть пользователь Microsoft Office.
• Работа со связанными документами в OpenOffice и Microsoft Office реализована по разному, и потому файлы Microsoft Office, открытые в OpenOffice, потеряют все связи. В Microsoft Office можно вставить документ из другого файла с сохранением связи между ними. При открытии такого документа в OpenOffice связь будет потеряна. Например, диаграмма или таблица из Excel, вставленная в текстовый документ, останется, но если отредактировать документ с таблицей, в текстовом файле изменения уже не отобразятся.
• До сих пор не решена проблема с паролями в документах электронных таблиц. Calc сбрасывает пароль, заданный в файле Excel и наоборот.
• Ограниченное количество словарей для проверки грамматики и орфографии, навскидку, нет финского языка. Нельзя сказать, что он очень распространенный, но Microsoft Office предоставляет гораздо большее разнообразие в этом вопросе.
• Не реализован корректный импорт формата RTF. Он все менее популярен и его поддержка прекратилась аж в 2008 году, но если в компании имеются такие документы, работать с ними будет сложно.
• В пакете OpenOffice до сих пор не работают макросы, написанные на VBA для Microsoft Office.
• Слабая интеграция с облаками. В OpenOffice вообще нет возможности прозрачно работать с документами в облаке, в Libreoffice есть опция Сохранить в облако, можно настроить несколько сервисов, но обеспечить совместную работу с облачным документом, как это реализовано в Office 365 или Google Docs, эти программные пакеты не позволяют.
• Корпоративные пользователи будут недовольны тем, что отсутствует интеграция с Outlook.
• Из небольших и странных несовместимостей: OpenOffice не поддерживает буквицы, а Impress (программа для создания презентаций), не понимает сложные градиенты и анимации PowerPoint, их надо упрощать перед тем, как открыть презентацию OpenOffice. Кроме того, отсутствуют некоторые инструменты чисто отечественной специфики, такие, как автоматическое создание отчетности для налоговой службы и пенсионного фонда. Имеется плохая совместимость с программой 1С. До сих пор есть шероховатости при импорте и экспорте математических формул, а некоторые файлы Microsoft Office слишком долго открываются. Отдельные виды теней и стрелок не поддерживаются в OpenOffice и могут слетать при открытии документа.

Самое любопытное то, что, если создавать текстовые документы по всем правилам, не пытаясь превратить его в чертеж или редактировать в фотошопе заголовки во все цвета радуги, избегать дилетантского форматирования пробелами, пользоваться стилями абзацев и шаблонами, несовместимость документов стремится к нулю. Но такой уровень работы с Офисом (любым) встречается очень редко. Обычно люди используют текстовый процессор на пару процентов от его возможностей, как чуть более продвинутый Блокнот.

Все это создает сложности при миграции с Microsoft Office на открытый и бесплатный софт, несколько примеров ниже это подтверждают.

Самые крупные попытки миграции

В далеком 2003 году власти Мюнхена решили начать проект LiMux. Так назывался дистрибутив на основе Ubuntu с небольшими модификациями для установки на компьютеры муниципальных чиновников. В 2004 году Microsoft прекратила поддержку Windows NT, и надо было решать, как быть: переходить на открытое и бесплатное программное обеспечение или на новую систему от Microsoft и обновлять остальные программы. В 2004 году власти объявили о намерении перейти на открытое программное обеспечение. Фактический он начался в 2005 году и был почти полностью завершен в 2012-2013 годах.

Недолго музыка играла. В 2014 году было сказано, что переход на Linux был катастрофой, и все компьютеры будут обратно переведены на Windows и Microsoft Office. Проблем было несколько.

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

Во-вторых, возникали сложности по конвертации старых документов в новый формат, и особенно сложно было обмениваться документами с другими министерствами и организациями, потому что проблем совместимости тогда было гораздо больше, чем перечислено выше. В департаментах использовалось больше 20 тысяч шаблонов документов Microsoft Office и почти 1000 макросов, которые потребовали серьезных усилий на переделку.

В-третьих, оказалось, что поддерживать парк машин на Linux дороже, потому что пришлось нанять новых программистов и системных администраторов, которые просили больше денег, чем специалисты по обслуживанию Windows, а ко всему прочему, их оказалось сложнее найти. При этом, все компьютеры так и не были переведены на LiMux, часть из них продолжала работать на Windows со всеми вытекающими проблемами совместимости.

Обратный переход обошелся казне почти в 90 миллионов евро и продолжался до 2020 года.
Забавнее всего, что за год сменилась администрация города, были выбраны новые политики, и они снова решили попытаться перевести городскую администрацию на открытый софт. Далеко не всем нравится подобная чехарда, и критики называют это решение политическим, а не рациональным.

Любителям теорий заговора понравится обоснование перехода обратно на Windows. В 2014 году мэром Мюнхена стал Дитер Рейтер, открыто симпатизирующий Microsoft, а в 2016 году исследование эффективности работы муниципальных служб было заказано компании Accenture, которая сотрудничает с Microsoft. Учитывая, что последняя не раз была поймана на взятках, подозрения имеют под собой все основания.

Другая неудачная попытка соскочить с иглы Windows тоже была предпринята в Германии. В 2004 году МИД объявил, что собирается отказаться от продукции Microsoft в пользу открытого ПО. В 2008 году они бодро отрапортовали, что все идет хорошо, экономится много денег, а проблемы совсем незначительные, и через год все закончится. Но в 2011 году Министерство заявило, что отказывается от открытого ПО и возвращается на Windows. Причины были предсказуемы: возникало слишком много проблем в обмене документами с другими ведомствами.

В 2005 году Министерство юстиции Бельгии заявило, что собирается переходить на открытое ПО, а в 2008 половина компьютеров уже работала на SUSE Linux и OpenOffice вместо Microsoft. Основная сложность снова очевидна: проблемы в обмене документами, плюс ко всему не было открытого аналога, который умеет работать с файлами Microsoft Access. Судя по всему, у них это получилось лучше, чем у немцев, потому что другие министерства и администрации городов тоже постепенно переходят на Linux и новостей об громком отказе пока нет, а проблему с Microsoft Access решили переходом на PostgreSQL.

Итоги

Какие выводы можно сделать из всей этой информации? Выгодно ли переходить на открытое ПО и сколько можно сэкономить?

Если говорить о большой компании, где документооборот десятилетиями идет на Microsoft Office, написано множество легаси-кода в макросах, изощренные таблицы с разнообразными диаграммами, а документы разных форматов содержат связи друг на друга, используя OLE, вся отчетность построена на множестве готовых шаблонов, а инфраструктура на Active Directory, переходить на свободное ПО почти невозможно, на грани смерти подобно. Усилия по переучиванию сотрудников, переписыванию шаблонов и макросов, созданию и поддержке новой инфраструктуры несоизмеримы с выгодой отказа от платного ПО.

Большие сложности ожидают компании, которые поддерживают очень активный обмен документами со своими партнерами и заказчиками. Особенно, если среди их адресатов есть дремучие динозавры из абзаца выше.

Если работа компании плотно завязана на специфичный софт типа 1С, то им по любому придется оставить несколько машин работающих на Windows с Microsoft Office, чтобы избежать проблем интеграции с этой чудо-системой. Фирмам, чья специфика подразумевает совместную работу с документами, OpenOffice тоже может создать слишком большие сложности, чтобы оправдать переход от платных конкурентов.

Зато молодая и небольшая компания, не создающая изощренных документов, чья работа не связана с интенсивным обменом документами с другими организациями, легко может отказаться от платного ПО и пользоваться одним из открытых Офисов, даже если они останутся на Windows.
Что касается обычных пользователей, то тут проблем вообще нет. Редко кому при обычном домашнем использовании требуются такие возможности, как связанные документы, совместное редактирование и изощренные макросы. А интерфейс, аналогичный старому Офису, с нормальным выпадающим меню, как у всех программ, куда удобнее, чем нелепые панели, которые были введены каким-то врагом дизайна, и предназначены для использования чужаками или хищниками.

***
И что же выбрать, на мой взгляд?

Google Docs!

Шутки шутками, но облачная модель работы с документами существенно привлекательнее, чем традиционная оффлайновая работа. Речь идет не только о Google Docs, но и о Office 365, Dropbox и множестве других сервисов облачной работы с документами. В них из коробки имеется коллективная работа над документами, там просто разграничивать права, делиться ими с другими пользователями или организациями достаточно послать ссылку, не скачивая или пересылая файлы. Сохранность документа не зависит от капризов софта или неполадок железа. Встроенная версионность куда удобнее, чем Undo/Redo, история которых теряется при закрытии локального документа. Работа с документом или его просмотр доступны практически с любого устройства, где есть браузер, от десктопа до смартфона. Эта статья, как и все остальные, написана в Google Docs. И пусть мне иногда не хватает возможностей полноценного Офиса, это компенсируют другие удобства. А в случае чего, подписка на облачные сервисы стоит на порядок дешевле, чем когда-то приходилось тратить на однократную покупку лицензионного софта.
И на этом поле открытое ПО пока проигрывает большим компаниям и платным решениям.

---

Наши серверы можно использовать для установки любой панели управления.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!