Пользователь
98,4
рейтинг
14 декабря 2010 в 21:35

Разработка → Внутренности вордовских файлов: просто ужас из песочницы

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

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

А теперь вот жизнь заставила (или подкинула возможность) все-таки разобраться во внутренностях всем хорошо известных документов, тем более, что в Штирлица теперь играть не обязательно, достаточно скачать с сайта «Майкрософта» официальные спецификации.

Что тут можно сказать? Невольно вспоминается старый пошлый анекдот: ну ужас. Ну просто ужас, но ведь не ужас-ужас-ужас.

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

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

Итак, как же устроены вордовские файлы?

Контейнер

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

Формат контейнера называется по-разному — docfile, ole storage, compound document file. Уже сам разнобой в названиях намекает на то, что он не сильно-то и нужен, поскольку действительно полезная вещь обычно имеет одно и четкое название. Основная его идея — иметь возможность запихать в один файл несколько других. Самым разумным было бы (как и сделали в OpenOffice) упаковать все в архив ZIP (можно без архивации, если она не нужна). Формат известен огромному множеству программ, компактен, легко разбирается. Но в «Майкрософте», очевидно, процветает синдром «Not invented here». Главное — изобрести велосипед, пусть и трехколесный, но собственный.

В принципе, формат OLE Storage достаточно разумен и не производит впечатление чего-то совсем идиотского. Но… он совершенно не нужен. Фактически, это что-то типа файловой системы FAT16, засунутой внутрь отдельного файла. Это не то что стрельба из пушки по воробьям, а истребление этих самых воробьев ядерными торпедами. В документе, внутри которого лежит несколько файлов, не нужна файловая система, находящаяся не менее чем на уровне ФС времен ДОС.

Итак, файлы CDF (как их называет юниксовская утилитка file) начинаются с заголовка. В заголовке отведено место под первую сотню записей ТРФ (таблицы размещения файлов, в просторечии — ФАТ). ФАТ там самый натуральный, очень похож на то, что можно найти на досовских дискетках. Остальные записи ТРФ лежат в отдельных секторах, соединенных связанным списком. Дополнительные сектора бывают только в больших (>7мб) файлах.

По табличке ФАТ/ТРФ можно собрать содержимое любого внутреннего файла (в терминологии МС он называется потоком, но это только запутывает дело), если знать, с какого блока он начинается. Начальные блоки разных структур написаны, естественно, в заголовке. Дальше из таблицы можно вытянуть всю цепочку секторов, в котором записано содержимое этого псевдофайла.

В частности, у CDF есть корневой каталог, физически размазанный по куче секторов. Это самый настоящий каталог, опять-таки, очень напоминающий старый досовский. Правда, для эффективности (или для выпендрежа) он выполнен не просто линейным списком, а сбалансированным двоичным деревом. Это значит, что в него без потери эффективности поиска можно записывать десятки тысяч отдельных записей. Зачем это нужно в файле, в котором записей бывает обычно штук пять, ну иногда, двадцать, ну максимум сто штук (презентация с огромным количество картинок) — знают только в Редмонде. Кстати, имена файлов в каталоге хранятся в UTF16 — тоже на всякий случай.

По каталогу можно определить начальный сектор любого файла и с помощью ТРФ вытянуть всю его цепочку размещения.

Но это еще не все.

Поскольку размер блока немаленький (обычно 512 байт, по спецификации возможно также 4096), то при хранении мелких псевдофайлов, теоретически можно потерять много свободного места. Поэтому существует отдельное хранилище, поделенное на блочки по 64 байта. Хранилище опять-таки вытягивается по цепочке ФАТ.

Чтобы указать, какие блочки какому файлу принадлежат, существует отдельная табличка ФАТ или, вернее сказать, миниФАТ.

Итак, чтобы добраться до вордовского документа, надо сделать следующее:

1. Прочитать заголовок CDF
2. Загрузить в память ФАТ — таблицу размещения файлов, собрав ее по цепочке секторов.
3. Загрузить табличку МиниФАТ, собрав ее по цепочке ТРФ
4. Загрузить хранилище блочков, собрав ее по цепочке ТРФ
5. Загрузить корневой каталог, собрав ее по цепочке ТРФ
6. Разобрать каталог и преобразовать его во что-то читаемое
7. Найти в каталоге запись WordDocument
8. Если это маленький файл, то собрать его с помощью миниТРФ из хранилища для блочков.
9. Если большой, то вытянуть с диска сектора по цепочке ТРФ.

Уф, вроде все.

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

Единственное, что можно предположить — все это сделано для того, чтобы была возможность дописывать подфайлы, не трогая начало основного файла. Надо заметить, что, во-первых, это не сильно востребованная операция, поскольку все программы обычно записывают документы от начала до конца в один проход. Исключение составляет только MS Word и то только в пресловутом режиме быстрого сохранения, проклятом пользователями. А во-вторых, даже в этих условиях все равно не получится не трогать начало основного файла, поскольку надо обновлять каталоги, ТРФ и заголовки.

В общем, «Майкрософт» в своем амплуа. Зачем делать просто, если можно сложно и запутанно?

WordDocument

Формат CDF при всей своей монструозности хотя бы логичен и не очень сложен (если сравнивать с остальным содержимым вордовского документа). Его описание занимает всего каких-то двадцать страниц — тьфу по сравнению с 300 страницами формата Ворда.

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

Достаточно посмотреть на заголовок, который занимает чуть ли не треть файла. Заголовков целых три. Сначала идет один небольшой, в котором половина записей зияет дырами «Reserved» или «Not used». Раньше, в мезозое, там явно что-то лежало, но потом было выкинуто на свалку истории. Здесь же имеется версия записавшей программы, по которой в коде, похоже, выполняется огромный switch/case.

Затем идет второй заголовок, состоящий из шестнадцатибитовых слов. В нем нет вообще ничего полезного. В его начале прописан размер явно с таким расчетом, что здесь будут в будущем откладываться панцири простейших.

После этого идет третий заголовок, на этот раз современный, из длинных слов (32 бита). Он немерянной длины, в начале тоже указывает количество записей с прицелом на дальнейшее расширение, и в основном представляет собой список, где искать различные таблицы и куски файла — пары начало/размер. Сами таблицы, кстати, лежат не здесь, а в отдельном псевдофайле CDF под названием 0Table или 1Table (возможны варианты).

В первом заголовке написана длина самого текста и его начало. Очевидно, что во времена царя Гороха именно так его и можно было прочитать. Текст лежал одним большим куском. Забавно, что можно читать его так и сейчас, но… не всегда! На десять читаемых файлов найдется такой, у которого в середине окажутся невразумительные куски, в конце — сноски, которых там быть не должно, а в самом начале — большой кусок текста, который стерли в прошлом году. Кроме того, половина файла окажется написана китайскими иероглифами. Прискорбно заметить, что известная утилита catdoc Витуса Вагнера в некоторых случаях именно такие результаты и дает, из чего можно сделать вывод, что формат она разбирает недокорректно.

Жизнь на самом деле гораздо сложнее. Когда-то в файлах действительно был только текст, однако со временем под давлением пользователей и маркетинга накапливались различные «фичи». Под них отвели отдельные потоки — под простые сноски, под сноски концевые, под колонтитулы, под какие-то textbox (то еще извращение — на вид текст, но не текст. Назначение толком не ясно).

Начала этих потоков указаны в специальных местах заголовка, но самый первый заголовок почему-то показывает общую длину — не самого текста, а текста плюс все этих извращений. Вот и первая причина, почему в вывод многих утилит попадают надписи типа Page 1.

Где-то в архее в редактор добавили быстрое сохранение. Смысл его в том, что файл целиком не переписывается, а добавления и изменения просто дописываются в его конец, что теоретически должно быть быстрее. Предполагалось радовать этим пользователей, но фактически они остались недовольны. Особой разницы в скорости записи при этом не получается, но в файле образуется много мусора, причем из кусков, которые теоретически уже стерты. Если там была какая-нибудь секретная информация, то простым просмотром дампа файла ее можно легко обнаружить.

Для поддержки быстрого сохранения была заведена особая таблица огрызков (piece table), в которую записывается начало каждого куска и его адрес в файле. Длины нет, но ее можно высчитать, вычтя начало текущего куска из начала следующего. Однако тут тоже надо быть осторожным, поскольку огрызки перечисляются из всех потоков. Слава богу, что они идут в определенном порядке, поэтому, зная общую длину текста, легко вовремя остановиться.

Теоретически, этот сложный формат задействован только, если в заголовке установлен специальный флажок fComplex. Но… Вот на этом очередном «но» тоже прокалываются многие конверторы.

Уже в наше время в документы добавили возможность записи в Юникоде. При этом встала проблема (как по мне, надуманная): а ведь файлы получаются ровно в два раза длиннее. Поскольку ПО разрабатывают американцы, которые в душе вообще не верят в существование других азбук, и тайно считают, что всякие странные буквы бывают только в диссертациях про Древнюю Грецию, да и там встречаются только иногда, первое, что пришло им на ум — отделить чистые символы ASCII от грязных юникодовских. Первые писать по байту на символ, вторые — как получится.

Из этой идеи возникла, например, элегантная кодировка UTF-8, где двухбайтовые символы кодируются хитрыми последовательностями в духе кодирования Хаффмана. В «Майкрософте» сделали то же самое, только не так красиво. Раз уж у нас есть таблица огрызков, то запишем туда заодно и какие куски текста написаны в чистом ASCII (на самом деле сp1252), а какие — на всякого рода невразумительных алфавитах, требующих Юникода и, соответственно два байта на символ. Поэтому нынешние файлы всегда нужно разбирать с помощью таблицы кусков, невзирая на всякие там флажки. Юникодовские фрагменты там берутся как есть, только надо учитывать, что количество читаемых байтов должно быть в два раза больше количества читаемых символов. Однобайтовые фрагменты отмечаются в адресе установленным вторым слева старшим битом (почему не первым?). Чтобы узнать настоящий адрес, нужно этот бит сбросить, а адрес разделить на два (!).

Если учесть, что сама эта таблица огрызков тоже занимает место, а еще больше места в файле занимают разные двоичные деревья и таблички цепочек секторов от формата CDF, то размеры экономии текста на символах Юникода не поразят воображения даже в древнегреческих диссертациях. О файлах на великом и могучем языке и говорить нечего. Положили бы все в UTF-16 и не страдали. Ну заархивировали бы поток, раз уж так жаба давит.

После героических усилий по чтению текста, в нем самом, как ни странно, нет ничего сложного. Обычный текст (с поправкой на кодировку), кое-какие коды ниже пробела играют служебную роль. Например, 0х9 обозначает, как и положено, табуляцию, 0хА — конец страницы, 0х7 — конец ячейки таблицы и т.д. Единственная тонкость связана с полями. Начало содержимого поля обозначается как 0х13, конец поля — 0х15, имя и параметры поля отделяются символом 0х14 от того, что, собственно, видно в тексте пользователю. Но… Вторая часть может иметь в себе вложенное поле, чего многие программы не учитывают. В результате в тексте остаются огрызки вроде INCLUDEPICTURE или PAGEREF *.

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

Выдрав текст, дальше в формат я углубляться не стал. Это уже занятие для молодых и сильных духом — разобрать все эти таблицы с такими многообещающими названиями как CHP, PAPX, SHST, PLCF и все в том же духе. Занятие совсем уже для титанов — вопроизвести форматирование в точности, как это делает сам Ворд.

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

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

Думаю, что «Майкрософт» столько лет его не открывала не потому, что боялась конкуренции, а просто потому что было… стыдно.

Дополнительная литература:


Официальное описание формата:
http://msdn.microsoft.com/en-us/library/cc313153(office.12).aspx

Дж. Спольски, «Почему форматы Офиса так сложны?»
http://www.joelonsoftware.com/items/2008/02/19.html
Юрий Жиловец @gatoazul
карма
133,0
рейтинг 98,4
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (211)

  • +60
    >>Самым разумным было бы (как и сделали в OpenOffice) упаковать все в
    >>архив ZIP (можно без архивации, если она не нужна). Но в
    >>«Майкрософте», очевидно, процветает синдром «Not invented here».
    >>Главное — изобрести велосипед, пусть и трехколесный, но собственный.

    .docx (Office Open XML) — формат по-умолчанию, начиная с Word 2007. Там всё хранится в архивах, а внутри XML.

    .doc разрабатывался лет 20 назад. В несовременности его обвинять можно, как и любой формат 20 летней давности.
    • +13
      TEX?
      • 0
        Я сравнивал форматы физического хранения, где в одном реальном файле находится несколько логических. (автор критикует, что в Office до 2007 не используются ZIP архивы)
        А Tex да, формат хороший. Но это скорее декларативный язык программирования.
        • +4
          Я вот к этому:
          >> В несовременности его обвинять можно, как и любой формат 20 летней давности.

          TEX имел достаточно мало редакций.
          • +2
            И тем не менее, при всех красивых словах о его исключительной архитектуре и красоте, он добавляет приносит долю красноглазия. И если в Word можно забить на некоторые огрехи, то при использовании TeX-а так и хочется их исправить, что убивает время :)
            • +9
              Вы подменяете понятия.
              Я лишь указал на наличие качественного формата которому свыше 20-ти лет.

              Холиварить на тему TeX vs Word не вижу смысла:
              Word — текстовый процессор (ну в каком-то приближении :)
              TeX — система вёрстки.
              • 0
                Нисколько, это намеренный уход от темы, хотя и похожий на троллинг.

                Вот именно, в TeX же формат текстовый. А картинки? А остальное? EPS? Ну так там тоже бывает чёрт ногу сломит. И то, нужно всегда держать в голове с пяток способов сделать из TeX PDF со своими заморочками посередине и своим набором пакетов, которые при этом будут глючить :)
                • +6
                  Либо EPS, либо PDF, уж определитесь. А то вы во всех грехах TeX вините.

                  За неимением кармы прокомментирую здесь и всех кто указывает на дату разработки формата .doc (CDF).

                  Посмотрите заодно и дату разработки .zip.
                  • +4
                    Zip не применялся в Office раньше как формат файлов из-за относительной неэффективности. Когда издержки стали меньше выйгрыша — стал применяться zip.

                    Джоэл Спольски:
                    www.joelonsoftware.com/items/2008/02/19.html

                    These are binary formats, so loading a record is usually a matter of just copying (blitting) a range of bytes from disk to memory, where you end up with a C data structure you can use. There’s no lexing or parsing involved in loading a file.
                  • 0
                    Не важно, в каком формате будет результат, я говорю лишь о том, что одним plain TeX не обойтись. А проблем с ТеХом особых и нет, вопрос как быстро они решаются :)
          • +1
            3 основные и около 7 минорных обновлений последней редакции (последняя версия — 2008 г.).

            При этом надо понимать, что ТеХ решает узкоспециализированную задачу, которая с момента создания языка практически не изменилась ;)
        • 0
          ZIP — тоже формат физического хранения, где в одном реальном файле находится несколько логических. И тоже 20-летней давности. Но это не мешает ему быть относительно логичным.
          • +1
            Я говорил не про логичность, а про современность. ZIP 20 летней давности несовременен. Но ZIP развивался плавно. С помощью Windows API чить файлы офисовского формата очень легко. А разбирать руками ZIP формат — намного сложнее. Всё относительно.
            • +1
              >С помощью Windows API чить файлы офисовского формата очень легко. А разбирать руками ZIP формат — намного сложнее.

              Хорошее у Вас сравнение получилось: читать формат1 при помощи готового парсера VS разбирать формат2 руками :)

              Давайте я Вам ещё подкину: с помощью библиотеки libzip читать zip-файлы очень легко. А разбирать руками JSON — намного сложнее %)
              К чему я это? К тому, что сравнивать надо или «разбирать либой VS разбирать либой», или «разбирать руками VS разбирать руками». В первом случае различия минимальны, во втором — ZIP побеждает с большим отрывом. Можете для сравнения глянуть сорцы любого опенсорсного zip-парсера и прикинуть, уложится ли в такой же объём парсер офисных форматов :)
              • –1
                Я про то, что в Windows есть стандартные средства для работы с Office форматом файлов. Написать аналогичную библиотеку для других платформ — дело максимум месяца. Строк кода там совсем немного. Меньше 500. Гораздо сложнее разбираться с телом самого документа. Но это другой вопрос. ZIP описывает формат _до_ собственно документа (там может лежать хоть картинкиь, хоть AutoCAD файлы. Парсеру ZIP всёравно). Только хранение. Самое сложное в работе с Office файлами — это то, что отсутствует в ZIP — работа с документом.

                Кстати, парсер XML — вещь весьма нетривиальная.
      • +4
        TEX — это не формат! TEX хранится в простом текстовом формате, TEX — это возможно расширение файла, и это typesetting system (отсюда en.wikipedia.org/wiki/TeX).
        • –1
          Ну doc я тоже могу блокнотом открыть :)
          А при определенном навыке даже что-то прочитать смогу.
          У ТЕХа текстовая сериализация, что подразумевает сложный парсер, у doc — двоичная сериализация и парсер попроще.
          • +2
            Судя по тексту топика, парсер doc не только не проще парсера tex, он и не проще системы управления межконтинентальными ракетами.
            • +1
              Это если с нуля его писать, придется воспроизводить все ошибки в архитектуре ворда за 20 лет.
            • +1
              Парсер TeX элементарен, но это непростой императивный язык, код на котором нужно ещё выполнить чтобы получить данные. После разбора .doc получаем готовые данные.

              Конечно, реализация TeX открыта и всем доступна для портирования на свою любимую платформу и применения в любых целях, поэтому его сложность, в отличие от .doc, на практике не имеет никакого значения.
      • 0
        Это не формат, а язык разметки.
      • 0
        TeX корректно сравнивать даже не знаю с чем… С bat/cmd? Или с недо-sh :]
        • 0
          С postscript?
        • +2
          TeX — скриптовый язык? o.O

          Обычно я прошу поделиться травкой, но, боюсь, эта для меня слишком.
          • 0
            А какой? В нем можно дефить свои последовательности, счетчики, сбрасывать данные на диск :) Это уж точно не формат данных.
            • +1
              Это язык, описвающий документ для системы вёрстки, который стал Тьюринг-полным только благодаря (*заглядывает в википедию*) Гаю Стилу.

              Хотите сказать Java тоже аналог bat или sh? И циклы есть и файловый ввод-вывод. Только назначение (и, соответственно, набор фич) у sh, TeX и Java немного разное.

              Как упомянули выше, TeX можно сравнить только с ps, который на самом деле ЯП, но почему-то весь мир считает, что это формат данных. Отличие лишь в том, что с ps в современном мире больше работают программы, а с TeX — люди.
              • +1
                Аналог — это не я придумал ;) Я всего лишь хочу сказать, что помещать в один контекст форматы данных для которых нужен парсер и «форматы» для которых нужен интерпретатор — наверное не стоит.

                C сравнением с ps я молчаливо согласился, если что, хотя тут сравнение сродне sh-java имхо :]

                Все же интересно, много ли людей работают с TeX'ом (plain)? ^_^
                • +1
                  Не встречал ни одного. Все работают с ConTeXt или LaTeX.
    • +2
      Видимо, чтобы ненавидеть MS особенно тщательно, нужно игнорировать все, что они делают. Вместо этого нужно под микроскопом разбирать 21-е прерывание и смаковать неудачные вызовы. Ведь что ни говори, а API они делать не умеют, совсем не умеют.
      • 0
        Под Windows скорее разбирают прерывание 2E
    • +7
      Office Open XML не лучший пример… столько рожали и родили такого монстра. Одно описание, если не ошибаюсь 6000 страниц! Да и в принципе от бинарного старого они далеко не ушли, просто в XML перевели (даже битовые маски оставили… в xml!!!)
      • +9
        Ошибаетесь. 7000 страниц. Плюс несовместимость с XML (в плане проверки по DTD) и множество прочих «вкусняшек». Я думаю, нас это все еще долго будет «радовать».
    • 0
      То есть 20 лет назад писать гавенный код было нормой? )

      По моему автор совсем не обвиняет код в несовременности.
      • 0
        Почему «гавенный код»? Где вообще что-то про код? Compound file — оптимизированный бинарный формат общего назначения, для которого в Windows есть прекрасный API. И почти любой программист за неделю напишет его парсер в Unix среде (формата хранения, не контента). Более того, под Linux есть несколько хороших библиотек (http://pole.berlios.de/).
        Если бы 20 лет назад кто-то предложил использовать ZIP формат и не дай Бог что-то похожее на XML, как предлагает автор, то его бы просто послали.
        Вся сложность .doc формата вытекает из сложности редактора и наличия множества его обратно совместимых версий.

        Так что формат неплох, просто он оптимизировался под аппаратные требования 20 летней давности, из-за чего сейчас кажется устаревшим. Джоел про это хорошо пишет. 20 лет назад было нормой писать под 386 процессор и единицы мегабайт памяти, сохранять данные на дискете. Исходя из этого ставились требования. Про Linux, кстати ни в домашней, ни в корпоративной среде никто тоже не знал.
        • 0
          Давайте сразу забудем про 20 лет и будем говорить честно — этому формату 13 лет. Про Linux и Mac, а тем более про Unix было уже давно известно. А OOXML — хотя и новый формат, совсем не образец для подражания.
          DOC формат очень громоздкий и под запись на дискету не очень оптимизированный, большие документы приходилось разбивать.
          Сложный формат — лишний сложный код. Выполнялся такой код долго даже на машинах того времени, так что ни о каких 386x речь вообще не идет.
          Почему ZIP+XML (или что-то типа того) плохо использовать не понимаю. XML очень избыточный, ZIP хорошо жмет XML, степенью сжатия можно контролировать скорость открытия/закрытия.

          Вывод: Microsoft пишет плохой код, создает плохие форматы — потому что у нее маленькая конкуренции в конкретной сфере и вместо того что бы выпускать хорошие программы, она давит конкурентов, как в случае с OOXML. Microsoft начинает выпускать хорошие программы только для сфер где они безнадежно отстали от конкурентов (что бы их догнать) или где они потерпели сокрушительное поражение (чтобы реабилитироватся).
          • 0
            >>Давайте сразу забудем про 20 лет и будем говорить честно — этому формату 13 лет.
            Спецификация Word 6 формата [1993 год]:
            docfile: An OLE 2.0 compatible multi-stream file
            hackipedia.org/File%20formats/Microsoft%20Office/doc%20(pre-office%202007)/Microsoft%20Word%20for%20Windows%206.0%20Binary%20File%20Format.doc.pdf

            Спецификация Word 97 формата:
            docfile: An OLE 2.0 compatible multi-stream file. Word files are .doc files.
            www.google.co.uk/url?sa=t&source=web&cd=1&ved=0CBYQFjAA&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F5%2F0%2F1%2F501ED102-E53F-4CE0-AA6B-B0F93629DDC6%2FWord97-2007BinaryFileFormat(doc)Specification.pdf&ei=iFgPTbSvBImW8QPSm7mCBw&usg=AFQjCNFS1P-DDpZsh7snMmOxGBrLIHJGZg

            В 1993 году формат был в продакшене. Разрабатывался он ранее. Поэтому формату 19 лет минимум.

            >>Про Linux и Mac, а тем более про Unix было уже давно известно
            Microsoft Word есть на Macintosh c 1984 года. На десктопах Linux и сейчас не более 1%, а тогда его в расчёт просто не брали. Но для случаев, когда нет Word, есть переносимый формат — RTF.

            >>А OOXML — хотя и новый формат, совсем не образец для подражания.
            Какой формат — образец для подражания? Я генерировал вручную и разбирал OOXML — ничего сложного.

            >>Почему ZIP+XML (или что-то типа того) плохо использовать не понимаю.
            В Office форматах многие бинарные части – это C структуры. Для их загрузки достаточно загрузить блок с диска в память. Никакого процесса парсинга нет. Скорость – огромная. Чтобы компенсировать затраты на парсинг XML нуден более мозный процессор и больше памяти.

            >>Сложный формат — лишний сложный код. Выполнялся такой код долго даже на машинах >>того времени, так что ни о каких 386x речь вообще не идет.

            Наоборот. XML — лишний сложный код. Бинарный формат Office очень прост для обработки. В разы проще XML. И менее затратен.
            • 0
              >В 1993 году формат был в продакшене. Разрабатывался он ранее. Поэтому формату 19 лет минимум.
              Два года многовато для разработки такого формата. Кроме того я думаю на разработку его вообще не ушло времени. Делали так как проще для того что-бы побыстрее выпустить версию. Никто не задумывался о том чтобы сделать формат удобным, просто каждый выпуск довешивал в него разные фичи.
              Не нужно называть это форматом который появился 19 лет назад. Он все это время разрабатывался. Автор занимается разбором формата которому не больше 7ми лет.

              >Бинарный формат Office очень прост для обработки. В разы проще XML. И менее затратен.

              Зато очень сложен для понимания. И даже после понимания, из-за закрытости формата и необходимости поддерживать старые версии, формат выглядит уродливым монстром со всякими CHP, PAPX, SHST, PLCF итд.
              • 0
                >>Два года многовато для разработки такого формата. Кроме того я думаю на разработку его вообще не ушло времени
                Вы заявляете в предыдущих постах, что Microsoft совсем не потратила времени на разработку формата целью которого было убить конкурентов в виде Linux в 1993 году и вообще захватить мир. Это троллинг.

                У формата есть недостатки, но это не самый плохой формат.

                >>Автор занимается разбором формата которому не больше 7ми лет.
                Автор рассматривает ту часть, которая на 95% не менялась с самого начала.
                • 0
                  > Вы заявляете в предыдущих постах, что Microsoft совсем не потратила времени на разработку формата целью которого было убить конкурентов в виде Linux в 1993 году и вообще захватить мир.
                  В предыдущих комментариях я говорю только то что Микрософт разрабатывает все свои продукты спустя рукава, все где конкуренты не обошли Микрософт на несколько кругов.

                  >У формата есть недостатки, но это не самый плохой формат.
                  У любого формата есть недостатки и нету эталона самого плохого формата. Просто этот конкретный формат очень плохой.

                  >Автор рассматривает ту часть, которая на 95% не менялась с самого начала.
                  Нет. Формат стал очень плохим именно из-за того что изначально не был хорошо продуман, а был обвешан со временем разными фичами. Надо рассматривать то что есть, а не то что в идеале.

                  >Это троллинг.
                  Вы наверное плохо представляете что такое «троллинг», для троллинга у меня все карты на руках, я мог бы аппелировать и к вашему возрасту, и к вашей слепой фанатичной преданности Микрософту, и к синдрому «в интернете кто-то не прав», и чему угодно. Честно говоря не скажу что вы хоть сколько нибудь сложная цель для троллинга.
                  Или, что скорее всего, вы достаточно хорошо представляете что такое троллинг и начинаете троллинг, в стиле «Ты тролль» из-за отсутствия аргументов. )
                  • 0
                    >>Просто этот конкретный формат очень плохой.

                    Если этот формат плох, какой формат-конкурент лучше? Где эти хорошие форматы? Чем плох .doc? Бинарностью? Нет, это плюс.
                    • +1
                      К контейнеру как раз у автора претензий не очень много:
                      Формат CDF при всей своей монструозности хотя бы логичен и не очень сложен.

                      Обратите внимание на раздел статьи WordDocument.
                      Претензии к формату в основном сводятся к тому что он не продуманный и соответственно плохо расширяемый. По этой причине, возможно изначально и приемлемый, формат превратился в уродливого монстра после кое-как дабавленных в него множества фич.
                      У этого монстра заголовок на треть файла и забит он зарезервированными и несипользуемыми местами. Он противоречит сам себе игнорируя свой флаг fComplex. И пытается сэкономить места побыстренькому, кодируя английский язык не так как другие.

                      Вот это все множество оговорочек и условностей и превращают формат в «очень плохой». На самом деле если какие-то фичи красиво впихнуть не получается, нужно переделывать формат.
                      • 0
                        И плюс еще кодирует многие важные данные черт знает где, в каких крайне сложных таблицах, причем невозможно, не разбирая таблиц, сказать, допустим, данный символ обыкновенный или представляет собой обновляемое поле.
                    • 0
                      Это хуже, чем аморальность. Это просто плохо написано.
                      (Оскар Уайльд)
  • +12
    Надо заметить, что, во-первых, это не сильно востребованная операция, поскольку все программы обычно записывают документы от начала до конца в один проход.
    Системные требования к 97-ому офису:
    For use on Windows 95/98: 8 (megabytes) MB of memory required to run applications individually (12 MB required to run Microsoft Access); more memory may be required to run additional applications simultaneously
    • +6
      Пожалуйста, впихните в 8 метров оперативы эти ваши программы вместе с данными, которые они записывают в файлы в один проход.
      • +4
        В один проход можно записать хоть 100ГБ, было бы место и поддерживала бы ФС, не понимаю причем тут ОЗУ.
      • +1
        А своп зачем? В смысле, что из свопа читать, что из файла на винте — все равно задействовать винт. Думаю, что МС так и делает, судя по скорости работы 97 офиса на 8М ОЗУ под win95. Но в ДОС это было актуально и, учитывая что формат пошел с тех времен, решение понятно. Непонятно, почему формат не обновляли, ведь обратная совместимость со старыми версиями все равно не гарантировалась, а когда потребовалось кардинально поменять формат — выпустили дополнение к старой версии просто. Могли бы и раньше так делать.
        • 0
          На свопе оверхед больше получается, вообще-то.
          • 0
            Теоретически, если правильно организовать, то нет. В смысле больше, но для пользователя не особенно критично получается. С другой стороны, при большем количестве оперативы, за счет ОС все ускорится, а если с файлом напрямую работать, то надо отдельно этот случай учитывать.

            В прочем, во времена 97го офиса, файлы больше метра были редкостью, только если с картинками или совсем большие, но они и так тормозили, решение не использовать своп помогало мало. Если оно было, конечно.
        • +2
          Зачем отказываться от возможности ускорить обработку файла, тем более что механизм отработанный есть?
          • +1
            Вы имеете в виду работа с кусочками файла, а не целым файлом + своп? на сколько я помню, в реальности такого и небыло, большие файлы долго открывались и сохранялись и жутко тормозили, а в рекламе формата PDF указывалось как одно из преимуществ то, что скорость работы с ним не зависит от размера файла (в противоположность ворду).
      • –4
        Что ж это, мокросовт не удосужились оптимизировать висту, а док оптимизировали для компов с небольшим числом озу?
      • +2
        Несколько способов редактировать файлы размером больше оперативки придумали ещё до того, как дядя Билли написал свой бейсик. Так что это всё гнилые отмазки. Можно ещё вспомнить блокнот, который, в каком, говорите, году таки научился открывать файлы больше 64К размером? Или всё еще не умеет? :). Кстати, если выкинуть из док файлов фат, минифат и микрофат со всеми их сбалансированными деревьями, и прочие ненужные заголовки, то средний размер файлов раза в 2 уменьшится — вот вам и ускорение работы и возможность работы с бОльшими файлами без тормозов и тд.
        • 0
          Придумать-то придумали, но дяде Биллу об этом не сказали — вот он и выкрутился «как мог» :)
        • +1
          Там проблема не в блокноте, а в виндовом контроле текстового поля, которое этим самым лимитом в 64 кило было долго ограничено. Тот же вордпад спокойно переваривал метровые файлы.
          • +1
            Переваривал — хорошее слово. Помню строку состояния типа «обрабатывается… 2%»
  • +5
    Чтобы такой адский труд не пропал, реквестирую модуль на сипане!

    Что касается извлечения всего с форматированием: я выбрал конвертацию .doc -> .rtf прямо в ворде ручками (если документов много, можно нанять китайцев). Распотронить RTF намного легче (хотя тоже не сахар).
    • 0
      RTF c потерями конвертируется. Понятно, что для задачи вытянуть текст годится, но тогда непонятно, почему уже сразу в txt не экспортить, чтобы и rtf не возиться еще.
      • 0
        Да ну ладно. Вы его вообще видели, RTF? Почти всё форматирование, которое только может понадобиться, там есть, плюс таблицы, картинки, ссылки и параметры страниц.
        • 0
          Ну я помню что старый офис говорил что конвертирование будет с потерями, точно в возможностях формата не уверен (за пределами жирного и разноцветного шрифта с ним не работал).
          Важно другое, если все равно заставляете пользователей пересохранять, чтобы выбрать потом текст, почему не сразу txt?
          • 0
            Читаем внимательно:

            > Что касается извлечения всего с форматированием…
          • 0
            Потери там касаются:
            а) макросов и скриптов
            б) hidden данных

            Изредка можно потерять что-то вроде размера полей в таблицах ячеек, не более. И то, это не формат (очень гибкий), а сам Word виноват, что не запихал их в файл.
    • 0
      Можно обойтись и без китайцев, подключившись к Ворду по OLE Automation
      • 0
        Китайцы здесь образные. Я это к тому, что не нашел способа делать все на стороне никсового сервера, но меня это не остановило.
  • +4
    Вы удивитесь, но есть люди, которые сайты делают в Word. То есть набивают документ, ссылки etc. и сохраняют как HTML-документ. Даже предлагают услуги по созданию сайтов именно таким способом, я серьёзно.

    В итоге даже такой «сайт»:



    Выливается вот в такой вот «код»:

    • +19
      спасибо за открытие Америки
      думаю, каждый, кто начинал свои эксперименты по созданию веб-страниц более 7-10 лет назад, хоть когда-то это делал :)
      Ворд НЕ ПРЕДНАЗНАЧЕН для создания веб-документов и их публикации
      тем более о стандартах W3C там речи не шло и не идет
      • 0
        Именно поэтому у меня сайт и код в кавычках :)
      • +8
        Тьфу, а я, дурак, в FrontPage делал :(
        • –4
          Самая лучшая среда разработки — Блокнот :) Высокая скорость запуска, выбор шрифта, не перегруженный интерфейс :)
          • 0
            в нем Zen Coding не работает
          • +2
            А обои интересные есть?
          • 0
            find&replace тупит :-(
    • +3
      Какие чудесные названия! UseAsianBreakRules, DontGrowAutofit и особенно LatentStyles! Боюсь предположить, что это за латентные стили
    • 0
      А когда вставляют в fck или tiny? Тоже самое, только разрабами поддерживается. По умолчанию только ck стал чистить, но с tidy не сравнится.
    • 0
      Какие все дураки — один Вы — умный…
      Только почему-то не поймёте никак, что документ, сохранённый так соответствует исходному документы и может быть засунут обратно в ворд практически без искажений. А для извращенцев, клепающих в ворде сайты есть опция, которая даёт намного более чистый html. Но куда проще подлить желчи, чем разобраться…
      • +1
        А для извращенцев, клепающих в ворде сайты

        … был давно придуман биореактор.
      • +1
        Странно, что никому не нужной (я бы даже сказал, противоестественной) функции чтения вордовского файла из html без искажений уделено гораздо больше внимания, чем намного более востребованной — сгенерировать по тексту простенький html. Да и появилась вторая функция намного позже первой.
    • +1
      Попробуйте написать в ворде одно слово, задать ему цвет, сохранить в html, а затем откройте в блокноте и посчитайте количество строк. Вы заплачете, я гарантирую!
    • +1
      А у нас была горе-редактор, которая делала так: открывала статью в MS Word, нажимала заветные Ctrl+C и вставляла в редактор CMS, вместе с вышеприведенной билибирдой. Ох, какие странички на сайте были…
      • +1
        Не зря у меня была привычка копипасты из Word перегонять промежуточным пунктом через блокнот, чтобы остался только plain text.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +16
      >Если вы хотите работать с ними, используйте Windows API для OLE.

      Который, разумеется, доступен на любой платформе на выбор?
      • –10
        Хм… А что, zip, tar, bzip2 доступен на любой платформе на выбор? Или может ELF формат кросплатформенный? О чём вообще речь?
        • +8
          >А что, zip, tar, bzip2 доступен на любой платформе на выбор?

          Ну что ж, давайте сравним: zip, tar, bzip2 доступны на Windows, Linux, Mac OS, *BSD, VxWorks, QNX (это из тех, с которыми мне приходилось сталкиваться, но я уверен, что список этот неполный). Давайте теперь заслушаем список платформ, на которых доступен Windows API для OLE :)
          • –14
            Не путайте «много где» с «на любой платформе».
            • +12
              Ну так и Вы не равняйте «не существует на единицах узкоспециализированных платформ» (назовите, кстати, парочку для примера? ;)) и «существует на одной-единственной платформе».
              • +1
                рискну, не оправдывая — ReactOS и Windows (-
          • –3
            хабр съел пост…
            Да, архиваторы — неудачный пример (в винде ведь всё есть =) ). А вот ELF, думаю, вполне подойдёт.
            Windows API для OLE доступен на 90+% копьютеров (не считая Wine и виртуальных машин).
            • +9
              >Да, архиваторы — неудачный пример (в винде ведь всё есть =) ). А вот ELF, думаю, вполне подойдёт.

              Вы уверены, что сравнивать формат офисных документов и формат исполняемых файлов одной конкретной платформы — корректно?

              Windows API для OLE доступен на 90+% копьютеров

              Задача автоматического разбора документов — не вполне типичная задача для десктопа, не находите?
              А в «более другом» сегменте компьютеров 90 процентами Винды и не пахнет.
              • +1
                >сравнивать формат офисных документов и формат исполняемых файлов
                Я думал, что вы примерно понимаете, что это за формат (compond document и OLE)… Похоже, что нет. Сompond document format позволяет внедрять в/объединять документы, созданные любыми (поддерживающими соответствующие интерфейсы) программами. Таких программ немало и написаны они далеко не только MS. Представьте, что вам надо в документе Word использовать графики из Excel, формулы, какие-нибудь хитрые схемы, например, из CAD программы. Можно встроить функциональность всех этих программ в Word, но очевидно, что это неправильный путь. Можно заставить пользователя вместо схем/графиков/моделей/и т.д. вставлять в документ скриншоты (и обновлять их во всех документах каждый раз, когда что-нибудь изменится). Логичное решение задачи — создание системы позволяющей, связывать объекты, созданные разными приложениями. Реализовано это в виде набора программных интерфейсов (позволяющих другой программе открывать/редактировать/сохранять объекты, созданые другой программой) и единого места, где программы, поддерживающие OLE могут регистрировать свои классы. Формат сериализации, очевидно, был бинарным, потому, что текстовый формат компьютеры бы не потянули (да и сейчас большинство форматов на всех платформах бинарны).

                Основных проблем с имплементацией этого для *nix две.
                Во первых, количество людей, которым нужен автоматический разбор документов и которые ну просто обязаны делать это на неродной платформе и без использования эмуляторов/виртуальных машин примерно равно нулю. Если умножить этот ноль на тот ноль денег, которые эти люди готовы заплатить за такую возможность, то получится ноль в квадрате. Поставив себя на место MS, я не вижу ни одной причины думать об использовании их офисных программ/форматов на *nix (и уж тем более, в те времена, когда доля линукса была не 1%, а 0%).
                Во вторых, в *nix отсутствует инфраструктура, на которой основаны форматы. Там нет ничего, что бы хотя бы отдалённо напоминало OLE или COM. Да что там COM… нет даже (стандартного) способа связать тип файла с соответствующим приложением. Есть несколько различных простеньких реализаций, но стандартного способа нет. Как можно сделать формат «для всех платформ», если на других платформах необходимая инфраструктура находится там в таком зачаточном состоянии? Не предлагаете же Вы всё делать под «общий знаменатель»?
                • 0
                  >Я думал, что вы примерно понимаете, что это за формат (compond document и OLE)… Похоже, что нет.

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

                  >Поставив себя на место MS, я не вижу ни одной причины думать об использовании их офисных программ/форматов на *nix

                  А Вам где-то показалось, что я требовал от МС где-то думать об этом? Вам показалось. Перечитайте первый мой комментарий в данной ветке: я всего лишь прозрачно намекнул, что предложение «почему бы не использовать OLE API» могло оказаться немного не в кассу ввиду целевой платформы, отличной от семейства Windows — только и всего. А уж какой подтекст в этом увидели Вы — ведомо лишь Вам одному.
                  • –1
                    Я просто уже привык, что на сайтах с обилием агрессивно настроеных ненавистников MS «какая-то программа/формат есть только в Windows» означает «MS пытается заставить всех использовать винду, используя специфичные для винды фичи»…
                • +1
                  Кстати, в Редмонде тоже не дураки сидят, офис стоит на порядок дороже ОС, поэтому там я думаю прикинули в столбик и поняли, что не стоит заморачиватся, писать версию под *nix, увеличивая стоимость продукта, т.к. люди не будут отказываться от продукта, если для его работы надо потратить еще 1/10 часть на ось
                • 0
                  > Там нет ничего, что бы хотя бы отдалённо напоминало OLE или COM. Да что там COM…

                  Потому что они не нужны. И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.

                  > нет даже (стандартного) способа связать тип файла с соответствующим приложением.

                  Непонятно, что тут имеется ввиду. Чем mime-type не устраивает? Что, существует другой способ связать программу с типом файла?
                  • –2
                    >Потому что они не нужны.
                    Я нигде не утверждал, что они нужны. Я просто констатировал факт, что их нет. А так, да, они не нужны. В винде не нужны, потому, что она их переросла (постепенный переход к .Net), а в линуксе — потому, что он до такого ещё не дорос.
                    Как паровой двигатель, не нужный ни первобытным племенам, ни современным людям.
                    >И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
                    Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…
                    >Чем mime-type не устраивает?
                    Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.

                    • +3
                      file
                      • +2
                        Ну куда же Вы со своим отсталым «file» (который однозначно идентифицирует MIME-type файла по его заголовку) из каменного века? Прогресс — он ить в трёх-четырёх заветных буковках после точечки в конце имени файла! :)
                        • –2
                          Ну почему-же сразу отсталый. Процессоры же становятся всё быстрее — циклы некуда девать. Какой смысл быстро искать «буковки после точечки» в быстрой хэш таблице? Лучше откроем файл (а ещё лучше, сначала закачаем его из сети), вдумчиво почитаем его, и гордо ответим, что это «что-то напоминающее XML».
                          • 0
                            Да, точно, Вы правы. Для определения MIME-type совершенно необходимо прочитать весь файл целиком, без этого — ну просто никак! Поэтому для того, чтобы смотреть HD-видео под Linux нужен как минимум суперкомпьютер с 32 гигами оперативы — нужно же прочитать весь файл целиком и проанализировать его!

                            Жгите ещё!
                            • –1
                              Эээ… Вы как-бы понимаете хотя бы примерно сколько операция надо тупо на то, чтобы открыть файл и прочитать пару байт? А чтобы потом применить строковую регулярку? И на сколько порядков больше операций надо сделать в случае, если файл находится не на локальной машине?

                              //Клуб противников эффективных алгоритмов всё ширится…
                              • 0
                                Вы как бы понимаете, что сравниваются не отдельные задачи «применить строковую регулярку к имени файла» VS «открыть файл, прочитать пару байт, применить строковую регулярку», а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
                                На сколько порядков больше времени потребует запуск самой программы+чтение программой файла (целиком) по сравнению с чтением пары байт? Сколько Вы выиграете своей регуляркой по имени файла? 0.01%? Внушает! Видимо, слова «premature optimization» и «bottle neck» Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.

                                // клуб противников здравого смысла всё ширится…
                                • –1
                                  На всякий случай, уточню, что обсуждение сейчас идёт о эффективности использования расширений файлов для определения типа содержимого.
                                  >а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
                                  Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой. Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере». Или «показать в папке с большим количеством документов только документы Word»

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

                                  >Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
                                  В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
                                  • 0
                                    >Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой.

                                    «Да что там COM… нет даже (стандартного) способа связать тип файла с соответствующим приложением. Есть несколько различных простеньких реализаций, но стандартного способа нет.» (15 декабря, 18:59)

                                    «Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.» (16 декабря 17:55)

                                    Скажите, для чего нужен «способ связать тип файла с приложением», как не для того, чтобы открыть его этим приложением?

                                    >Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере».

                                    И каким боком тут связь файла с приложением? Ну зашли, ну показали. Какая разница, с каким приложением у меня связан тот или иной тип файла (и связан ли вообще)?

                                    >Или «показать в папке с большим количеством документов только документы Word»

                                    «Только документы с расширением doc/docx», Вы хотели сказать? Это не то же самое, что и «только документы Word», как Вы сами понимаете. Так вот, открою страшную тайну: в Linux тоже можно оперировать масками файлов и точно так же показать только doc/docx :)

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

                                    Выделение подстроки — не зависит от количества, но Вы опять «забываете», что это не отдельная задача «выделить подстроку», а находится она в контексте «определить приложение, ассоциированное с данным расширением», для чего Вам придётся сделать что? Правильно: прошерстить хэш-таблицу. Зависит ли скорость данной операции от количества типов файлов — решите сами.
                                    Хотя Вы опять можете сказать «я же не сказал, что контекст именно такой» %)

                                    >В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.

                                    Я беру тот контекст, который Вы сами задали (дважды): «связать тип файла с программой». Для какой цели это может понадобиться — у меня вариантов как-то немного.
                                  • +1
                                    Определять тип файла только по расширению — вообще-то дурная идея.

                                    Вы скажете мне, какой программой создан файл .dat? Это video-cd, или что?

                                    Другой пример: .far (треккерная музыка или служебный файлик far manager).

                                    Или распространённые общие имена: в .bin может быть что угодно — что ж теперь, не определять, что именно там?

                                    И напоследок: ваша винда всё равно читает содержимое файлов. Хотя бы для того, чтобы выдрать/построить иконки, или вытянуть теги mp3, указать автора документа офиса, и т. п… К тому же, если их не читает оболочка, их до оболочки прочитает антивирус.
                                    • +1
                                      А теперь внимание!

                                      .doc может быть документом Microsoft Word или текстом с разметкой AsciiDoc!
                      • –2
                        Какой-то плохонький способ…
                        $ file --mime SVG.svg
                        SVG.svg: text/xml

                        Но главное — не в этом. Думаю, Вы понимаете, что я имел в виду стандартно расширяемое решение. То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.
                        можно, конечно смело делать >>magic, но ясно, что это решение плохое.
                        • +2
                          >То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.

                          Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается… Шмяк!
                          • –1
                            Так что там с SVG? Файл есть, поддержка есть, типа нет… грустно как-то

                            >Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается
                            Вы, кажется, всё никак не поймёте, что я прошу.
                            Но с каждым разом всё ближе, так что надежда на понимание есть.
                            Итак, чем меня не устраивают Desktop Entry файлы? Я просил, повторяю, «стандартный (чтобы всеми признавался и везде работал) способ». Desktop Entry поддерживается на уровне DE. Соответственно, не все DE поддерживают это. Опять же такую схему поддерживают не все терминалы. Но какие-то подвижки есть, этого нельзя не признать. (Если бы они ещё выкинули на помойку формат файлов в INI стиле...) Глядишь, лет через 5 кто-нибудь начнёт делать подобную систему для библиотек, а не только для программ.

                            P.S. «Desktop entry files should have the .desktop extension, except for files of Type Directory which should have the .directory extension.» Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
                            • +2
                              Так что там с SVG? Файл есть, поддержка есть, типа нет… грустно как-то

                              file SVG.file
                              SVG.file: SVG Scalable Vector Graphics image

                              • –2
                                Как я уже говорил:
                                $ file --mime SVG.svg
                                SVG.svg: text/xml

                                Мне кажется, это проблема…
                                • 0
                                  … древности ПО в вашей системе. Обновиться не пора?
                            • +1
                              >Вы, кажется, всё никак не поймёте, что я прошу.

                              Так Вы каждый раз разное просите. То связать тип файла с приложением, то зачем-то «зайти в сетевой каталог и показать 1000 файлов».

                              >Итак, чем меня не устраивают Desktop Entry файлы? Я просил, повторяю, «стандартный (чтобы всеми признавался и везде работал) способ».

                              Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org. А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».

                              >Desktop Entry поддерживается на уровне DE.

                              А Вам на уровне ядра надо, что ли?

                              >Соответственно, не все DE поддерживают это.

                              И? Хотите я Вам напишу оболочку для Windows, которая не будет поддерживать виндовый стандартный механизм связывания типов файлов с приложениями — что это докажет по Вашей логике?

                              >Опять же такую схему поддерживают не все терминалы.

                              Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?

                              >Если бы они ещё выкинули на помойку формат файлов в INI стиле...

                              И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!

                              >Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?

                              А именно затем, недогадливый Вы наш, что в задаче «быстро распарсить несколько сотен .desktop-файлов» та самая операция «открыть файл — определить содержимое — закрыть [ненужный] файл» как раз может оказаться боттл-неком, т.к. никакой сторонней программы в данном случае не запускается, и обработка происходит тут же. Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
                              Очень странно объяснять подобную элементарщину столь яростному поборнику эффективности.
                              • –3
                                >Так Вы каждый раз разное просите. То связать тип файла с приложением, то зачем-то «зайти в сетевой каталог и показать 1000 файлов».
                                Не, я прошу то же самое, что и в начале — «связать тип файла с приложением». Но я не говорил для чего именно. Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.

                                >Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org.
                                Я понимаю, что он, видимо наиболее стандартный способ. Но есть разница между словами «наиболее хороший» и «хороший». Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
                                >А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
                                Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы. Хотя хотелось бы, конечно, чтобы Desktop Entry файлы поддерживались обычными шеллами типа bash и POSIX шеллами типа ksh.

                                >Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
                                Например, он мог бы запускать установленную в данной системе по умолчанию программу обработки данного типа файла при выполнении команды ./file. (как альтернативу используемой сейчас схеме запуска скриптов через hashbang)

                                >И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
                                Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас). Это должен быть один их открытых мировых стандартных форматов. XML для этого вполне подойдёт. Быстро-распарсиваемых? Это не нужно. Распарсить достаточно один раз. Важен только быстрый доступ.

                                >Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
                                Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач? Думаю, не будет ошибкой, если я скажу, что этот класс задач больше, чем задачи, для которых обязательно нужно лезть внутрь файла. Если Вы наконец поняли, что расширения тоже важны для определения типа файла, то, я думаю, дискуссию по этому вопросу можно закончить.
                                • +1
                                  >Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.

                                  Я Вас, возможно, несколько удивлю, но показ иконок и связь типа файла с приложением — слегка ортогональные вещи. Они могут быть связаны (как в Винде), но вовсе не обязательно. И если они не связаны, то в ситуации, когда тип файла известен системе, но соответствующее приложение не установлено, всё равно будет показана нормальная иконка. Парадокс, да?
                                  А уж для фильтрации по расширению связь с приложением и вовсе не нужна. Так что контекст пока что остаётся один. Думайте ещё.

                                  >Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.

                                  Да, я понимаю, что Вы пытаетесь витать вокруг да около. Конкретные претензии — в студию. Без обтекаемых «теоретически может быть недостаточно хорош».

                                  >Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы.

                                  Какой «проблемы»? Что существуют некоторые DE, разработчики которых решили положить болт на стандарт? Извините, но это проблемы исключительно тех индивидов, которые сами выбрали себе такое ДЕ, но никак не проблема остальных юзеров и уж тем более не проблема линукса в целом (и механизма desktop-файлов). Я Вам ещё раз говорю: если я напишу оболочку для винды, которая не будет поддерживать стандартный виндовый механизм связи файлов с программами — у винды тоже моментально появится «проблема», наличие которой Вы будете «констатировать»?
                                  Ни в одном вменяемом дистрибутиве по дефолту не поставляется ДЕ, не поддерживающее данный механизм. А уж если кто сознательно ищет приключений на свою пятую точку — то это их проблемы, повторяю, а не линукса.

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

                                  Нет, не соглашусь. Для такой вещи этот формат оптимален. Специфицирован он прекрасно, гибок он ровно настолько, насколько нужно, а «плохорасширяемый» и «с ворохом вендор-проприетарных расширений» — это вообще взаимоисключающие абзацы.

                                  >Это должен быть один их открытых мировых стандартных форматов.

                                  Кому должен и с какой стати? Аргументы в студию.

                                  >XML для этого вполне подойдёт.

                                  Верите-нет, но я был уверен, что услышу именно эти 3 буквы. Так что Вы там про «эффективные алгоритмы» говорили? Как это стыкуется с Вашим стремлением притащить XML со всем его оверхедом туда, где INI — выше крыши?

                                  >Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач?

                                  Мдя, и перед кем я тут распинался… =\
                                  Повторяю ещё раз: эта оптимизация важна лишь там, где она имеет смысл. При парсинге desktop-файлов — имеет, т.к. даёт значительную экономию, позволяя отсеивать файлы по названию, а не распарсив содержимое и обнаружив, что файл «не тот», а вот при ассоциации файлов с приложениями — не имеет никакого смысла, т.к. открыть файл/прочитать несколько байт из начала/закрыть файл занимает порядка 0.01 секунды (если файл ещё не кэширован), что напрочь теряется на фоне времени запуска ассоциированной программы. Напишите Вы уже простейший тест — там едва два десятка строк наберётся.

                                  Всё, не знаю, как у Вас — а у меня пятница, окончание рабочего дня, а свободное время я предпочитаю проводить с семьёй, а не разжёвывая прописные истины каждому встречному-поперечному.
                                  Удачи!
                    • 0
                      > Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…

                      В огороде бузина, в Киеве дядька, а у тебя в башке — каша.

                      Каким образом ты собрался использовать абстрактный вычислитель для реализации компонентов? Какое отношение математическая абстракция вычислительного процесса имеет к реализации программ на конкретной ОС? Какими грибами ты питаешься?

                      Дуй-ка ты свой стоплинукс.сру к таким же невеждам и идиотам. Не о чем с тобой спорить.
                      • –1
                        Если Вы не поняли мою мысль, поясню:
                        говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.

                        А вот сравнивать именованные каналы с библиотеками (в частности COM) — вот это воистину «В огороде бузина, в Киеве дядька». Никакой связи нету. Или вы решили учить сишников, что правильно общаться с библиотеками через UDS, а не вызовы экспортированных функций? Не забудьте потом запостить отчёт на хабр.
                        • 0
                          > Если Вы не поняли мою мысль, поясню:

                          Да тебя вообще очень тяжело понять.

                          > говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.

                          Какой отношение машина Тьюринга имеет к языкам программирования?
                          Какое отношение машина Тьюринга и языки программирования имеют к unix domain sockets?

                          > А вот сравнивать именованные каналы с библиотеками (в частности COM)

                          Не ври, я такого не говорил, это твои фантазии. Я говорил о том, что грамотно используя юниксовые сокеты можно спокойно обойтись без аналогов COM, и результат получится проще и масштабируемее. Компоненты можно без усилий разнести по разным машинам, можно дописать планировщик и получить load balancing.
                • +1
                  По образцу COM написана инфраструктура Firefox (XPCOM), а также инфраструктура OOO. Особого распространения ни то, ни другое не получило.
                  • –1
                    Я думаю, что причина — в специализированности и «нестандартности».
                    Проблема курицы и яйца, опять же. Без инфраструктуры не будет COM классов, если нет COM классов, то инфраструктура не нужна.
                    • +1
                      Причина — в ненужности.
                      • –2
                        >Причина — в ненужности.
                        Зачем повторять мне мои же слова?
                        Я выше уже соглашался, что «паровой двигатель, не нужен первобытным племенам»
        • +1
          Да, формат ELF — межплатформенный, причем исходно разрабатывался таким.
      • –1
        Это, разумеется, проблемы индейцев.
      • +1
        А интересно, в Wine то OLE32.dll должено быть. Оно как бы достаточно стандратное. Мож таки єто АПИ существует не тока на одной платформе?
        • +1
          OLE существует не только на одной платформе примерно так же как менеджер пакетов Portage не только в одном дистрибутиве. Да, его и на виндовс можно поставить, если вам пары дней времени и немного нервов не жалко.
          • 0
            Я больше про то что автор статьи, кроме всего прочего, решил написать то что уже существует.
        • 0
          Сам WINE существует только на x86 и amd64.
    • +16
      Обычно задача автоматической .doc файлов возникает на платформах, крайней далеких от Windows API и OLE.
    • 0
      Схема-то одна, но есть некоторая разница в нюансировке. Как например, между brainfuck и С, хотя и то, и другое — языки программирования.
  • +8
    Эх, автор. Была бы статья не на Хабре — ты бы стал автором новой пропаганды, мессией, который нашел новый способ удара по виндузятникам.
    А так, разбирать старющий формат .doc, сравнивать его с относительно молодыми — толсто.
    • +1
      Вообще-то я хотел поделиться своим опытом с людьми, перед которыми встанет такая же задача разбора. К сожалению, формат .doc, хоть и старющий, но по-прежнему сильно распространенный.
  • +10
    Ну что же вы так ругаете Микрософт? Вы должны понимать, что львиная часть кода (а это тысячи и тысячи часов разработки) нужна для обеспечения обратной совместимости, к которой MS всегда очень трепетно относится. И выбрасывать последние 20 лет разработки тоже никто не станет только ради того, чтобы кому-то было более удобно пользоваться форматом. Legacy такой legacy.
    • +4
      Вроде как для обратной совместимости нужет просто идентификатор версии файла. Старые версии то новые форматы не поддерживают, а в новых предусмотреть для старых версий отдельные обработчики.
      Правда в таком случае сторонним разработчикам совсем бы солоно пришлось, наверное=)
    • +1
      Пример, Lotus 1-2-3, самый популярный табличный процессор своего времени. Формат менялся 4 раза, что никак не повредило его популярности.
      • +8
        Если не повлияло, то где сейчас этот Лотус?
        • +1
          Это другой вопрос, функционала, а не контейнера.
        • +2
          Здесь.

          Да и вообще, система документооборота от IBM весьма популярна.
  • –3
    Из-за постоянных попыток автора съязвить и неудачно с умничать статью было просто противно читать. Видимо, сам по своей же ссылке на статью от Спольски про причины тех или иных решений MS Office он так и не сходил.
    • +1
      Их решения — мои проблемы.
  • –19
    А что мешало просто сервак на винде поставить? Или виртуальную машину?..
    • +1
      Ставить и администрировать отдельный сервер под Windows только для разбора вордовских файлов — накладно. Виртуальная машина + ms office — сильная потеря в производительности.
      • –1
        Вы эту «сильную потерю» измеряли? Я имею в виду нормальные виртуальные машины, конечно…
        • +1
          Можете поверить на слово, что для конкретной задачи накладные расходы времени и памяти даже на один MS office без виртуальной машины были неприемлемыми.
  • +1
    А вот вопрос — почему до сих есть проблемы с открытием вордовых документов в опенофисе/гугльдоках? Нет полноценного конвертора или спецификации неполные?
    • +2
      Достаточно сложный формат, при чем что старый, что новый xml. У опенофиса небольшая команда, скорее всего просто не успевают. Под новый мсный формат новелловцы сделали неплохое расширения для ОО, но тоже не без проблем.
      • 0
        Еще один занудский вопрос — так все-таки спецификации неполные, или у разработчиков руки не доходят?
        Это я к тому, что у гугля-то должно хватить и бабла и программистов допилить полноценный конвертор. А оно все равно как-то не очень работает…
        • +3
          Руки не доходят :) На новый формат документация более 6000страниц.

          ЗЫЖ думаю у гугли на доксах людей работает меньше, чем у мс на офисе.
          • 0
            Мдя, странно. Только отсутствие нормальной читалки документов ворда останавливает несколько компаний вокруг меня от перехода на линукс.
            • +22
              А вы думали зачем МС сотни разрабов на офис? Чтобы своевременно вносить несовместимости.
              • –1
                … десятки полюсов?
                Хабр катится всё дальше… в светлое разумное будущее, конечно.
                • +1
                  Народ оценил шутку, что с вами не так?
        • +4
          Часть структур не описана вообще (про часть забыли, другая часть является секретной), часть описана неправильно (в спецификации одно, а на деле совсем другое). Мне понадобилось 3 (!) различных спецификации, чтобы сделать конвертер.
          • 0
            Это Вы про Open Office форматы? Да, с этим проблема… там, где у OOXML десяток страниц описания формата формул, в спецификации ODF написано «а в этом теге пишем формулу».
            Формулы из OpenOffice.org Calc не совместимы с KSpread? Невелика беда. Зато спецификация компактная.
            • +3
              Нет, я про документацию майкрософт. Не ту что по ссылке (тут лишь описание стуктур), а полную с пояснениями и прочим. Например, чтобы понять, как записывать картинки, мне понадовилось около недели просидеть в компание HIEW. Да и то пришлось костыли придумать.
          • 0
            То-есть существует в природе полноценный конвертер doc?
            • 0
              Да, и он лежит у меня на жестяке :)

              Знаете, наверное где-то к весне я его таки перепишу и выложу под открытой лицензией.
              • +1
                Батенька, это ж архиважная вещь!

                Вот именно из-за отсутствия нормального вордового конвертора приходится даже в линуксе себе отказывать.
                • 0
                  Если на это будет спрос, то тогда конечно. Я всегда думал, что старый формат умирает, и поэтому это никому не нужно.
    • 0
      Причина похожа не ситуацию с браузерами. Как бы они не развивались, все-равно есть ошибки даже на страницах, сверстанных согласно спецификации. Кстати, в офисе по Mac изредка встречаются проблемы с отображением некоторых элементов.
    • 0
      Особенно несовпадения размера шрифтов раздражает
    • 0
      Потому что приходится не только разбирать формат, но и имитировать все глюки Ворда, накопившиеся за 20 лет. Об этом есть у Спольски.
  • +2
    вообще, к работе предков принято относится с уважением

    эволюция автомобилей тоже не с порше 911 начиналась
    • +16
      Однако в порш 911 нет парового двигателя.
    • 0
      Как насчет тщательно разработанной теории эпициклов?
  • +17
    Ох, я целый год писал конвертер вордовских файлов в XML — выучил почти все матерные слова и проклятия.
    • +1
      Результаты трудов существуют где-то в открытой лицензии?
      • +5
        Увы нет — мы писали это для одной корпорации, которая хотела генерировать отчеты в документах различных форматов и из этих же форматов и получать информацию. Мы долго ржали, когда они заявили, что будут так же генерировать и годовые отчеты — там было столько информации, что понадобилось бы несколько миллионов страниц ворда.

        Но когда я уходил оттуда, то исходники все-таки спер. Если переписать модуль compound document (его писал не я, а какой-то индус, судя по коду), то можно наверное и выложить.
        • 0
          И как с того времени, не продвинулось дело?
          • 0
            Не знаю. Я там уже несколько лет, как не работаю
    • 0
      Word начиная с 2003 может сохранять в WordML — подмножество XML
      полагаю, никакие хитрые элементы документа при этом не теряются
      разве недостаточно?
  • +15
    Попробуй теперь распарсить .xls там ещё 2 уровня инкапсуляции. =)
    • +3
      На всякий случай чтобы автор больше не потерял еще неделю жизни на задачу которая решается за 20 минут search.cpan.org/search?query=excel+binary&mode=all
    • +6
      Я парсил и xls. К счастью, OpenOffice.org выложили нормальную спецификацию (майкрософтовская имела кучу ошибок — см. мой коммент выше) и я с помощью этих двух спецификаций управился за пару недель (хотя, большинство кода уже было написано при работе с вордовским форматом).
  • +2
  • +10
    У меня сложилось впечатление, что автор а) мягко говоря не очень компетентен в вопросе и б) статью Спольски, которую сам же и привёл (зачем, интересно?) не читал или не понял, ибо она объясняет абсолютно все вопросы и недоумения автора по поводу этого формата.

    Очень радостно, что тут приведено много занятного (но не нового для сталкивающихся) про ole storage, но тем не менее свои цели формат отлично выполнял, кроме того не надо забывать, что он был разработан тогда, когда «клёвых и современных» форматов не было даже в проекте. У него есть свои плюсы (в данный момент многие из них менее актуальны). Есть и минусы, конечно. Основной минус, который и разобран в статье («сложность» формата) вытекает из его бинарности и необязательности на тот момент в какой-либо переносимости и прочего такого. Да, фактически этот формат похож на сериализованные бинарные структуры (а кто более-менее глубоко программировал на расчудесном MFC догадываются даже почему), но… и что из этого, статья то о чём? Технической инфы мало, на сравнение тоже не тянет. Так, посмеяться что ли просто? :)
    • +1
      Почему некомпетентен? Мой конвертор успешно работает полгода при большой нагрузке и за это время в нем была найдена всего одна ошибка, да и то связанная с ошибками во внутренностях.
  • +5
    Очень хорошо понимаю автора и поддерживаю отношению к формату. За эту вводную статью, также, большое спасибо.

    Тезис критиков о том что формат старый, считаю несостоятельным: раньше как раз тяготели к эффективным бинарным форматам, которые читаются за один проход и, чаще всего, «ложатся» в обычный с-шный struct. С точки зрения быстродействия это наиболее оптимально. Считаю, что имею право рассуждать об этом, так как в течение более 10 лет разрабатываю форматы и протоколы обмена в областях, где важна эффективность и устойчивость к сбоям (соответственно, компьютерные игры, а также промышленная автоматика).

    На мой взгляд (я не претендую на Истину), основной задачей при создании формата было внедрение неочевидной схемы, которую очень трудно воспроизвести в сторонних приложениях. Т.е. задача создать сложнейший формат, который бы сохранил эксклюзивную возможность работы с файлами только в «фирменных» приложениях, была выполнена «на отлично».
    • +3
      Кстати, с тезисом об оптимизации для инкрементальных сохранений, также не согласен: всё то же самое можно было сделать, внедряя более простые схемы. Тем более что в реальных ситуациях, в старых версиях программ, где реальная сложность документов была ниже, подобная реализация была избыточной в квадрате. Даже если предположить, что реализация своего ФАТа была необходима, можно было реализовать гораздо проще. В ситуациях, когда приходилось делать свою мини-файловую систему для хранения разнородных данных в ЕЕПРОМ контроллера, моя реализация была на порядки менее монструозной. А этот, извините, Франкенштейн, вызывает единственную мысль: любой ценой необходимо было сохранить уникальность продукта на рынке. Как показала практика, с этой задачей формат справился.
      • +4
        Кстати, я бы не хотел вешать ярлыки «зла» или «добра». Корпорация имела законное право создать тот формат, который пожелает (создание сложных форматов не преследуется по закону). Также, корпорация имеет право исходить из тех оснований, которые считает нужными. Мало того, Микрософт оказалась достаточно сильной, чтобы отстаивать свои позиции в течение десятилетий. Это, конечно, очень достойный результат.
  • +6
    «Зачем делать просто, если можно сложно и запутанно?»

    А чтобы в «опенофисах» не открывалось.
    • –1
      В смысле, чтобы документы, созданные в RSpread не открывались в OpenOffice.org Calc? Ну да… похоже для этого «опенофисы» и были придуманы…
    • 0
      Именно. Чем сложнее, кривее и запутаннее формат, тем сложнее создать конкурирующее приложение для работы с форматом, являющимся мировым стандартом де-факто.
    • 0
      Да не было никаких опенофисов, когда это разрабатывалось! Не стоит искать злой умысел там, где можно объяснить простым быдлокодом.
      • 0
        Был Word Perfect — очень даже реальный конкурент. Был AmiPro/WordPro.
  • +5
    Когда мне нужно было работать с офисом, я использовал Apache POI. Радуют названия отдельных пакетов: HSSF (Horrible SpreadSheet Format), HWPF (Horrible Word Processor Format), POIFS (Poor Obfuscation Implementation File System), etc.
    • +1
      Аа, да, увидел.
      Но думаю автору полезно будет еще пару раз перечитать
    • +2
      Отличный список маразмов.
      А вот это в мемориаз:
      «То же самое, но хостинг на Linux. Купи сервер на Windows 2003, установи на него лицензионный Word и настрой веб-службу, которая будет делать всё это. Полдня работы на C# и ASP.NET.»
      Теперь, когда меня спросят сложно ли настроить хостинг, я буду отвечать: «Легко! Сначала купите сервер на Windows....»
      • 0
        Всё верно. А желающие заняться ручным разбором под линухами сами выбрали свой путь
      • +1
        Ну, вот так Спольский жжёт. Снова сунулся в оригинал — ничего сверхъестественного, всё именно так.
      • 0
        То же самое, но хостинг на Linux. Купи сервер на Windows 2003…
        Теперь, когда меня спросят сложно ли настроить хостинг, я буду отвечать: «Легко! Сначала купите сервер на Windows....»

        вы не поверите, но очень часто «купи» это самый дешевый путь. к сожалению многие вещи не доступны бесплатно и их приходится покупать, к еще большему сожалению, некоторые нужные вещи купить не у кого (в виду малой востребованности никто их не «производит») и приходится делать самому. и довольно часто это обходится дороже чем купить :/

        навскидку, необходимый для работы комплект можно уложить в килобакс с небольшим (возможно некоторые особенности лиценизирования которые я не учел и удорожат набор, но не думаю что очень сильно). сколько нужно будет заплатить девелоперу за разработку? сколько он убьет времени на написание? а на отладку? неделю? две!? месяц?! больше?!!? а сколько, сколько он стОит?
        • +2
          У меня в комментарии пропущено одно слово, я думал, что тем кто прочитал Спольского будет понятно и не стал поправляться.
          Ещё раз Спольский в вольном пересказе:
          — Как это сделать на linux?
          — Очень просто! Берём windows и делаем на нём.
          Из всей статьи, я согласен только с одним доводом в защиту сложности формата файлов офиса, остальные притянуты за уши.
          • –1
            Как забить гвоздь отверткой?
            Как на PHP работать с SSE регистрами процессора?
    • +1
      Это мой перевод :)

      Ирония судьбы: впоследствии мне приходилось читать… нет, не Word, правда, а Excel.
      • 0
        Отличный перевод. Как по мне статья убедительно показывает причины.
  • –5
    3. Загрузить табличку МиниФАТ, собрав ее по цепочке ТРФ
    4. Загрузить хранилище блочков, собрав ее по цепочке ТРФ
    5. Загрузить корневой каталог, собрав ее по цепочке ТРФ

    Статью на перле генерили?
    • +8
      Минусующие не видят несогласованности рода, или просто за перл обидно?
      Если второе, то окей, я признаю что на перле можно легко и элегантно сгенерить статью даже лучше обсуждаемой.
  • –1
    Я так и не понял: аффтар занимался самообразованием или у него не хватило проницательности найти antiword, который делает в точности что нужно: выдирает текст из doc-файлов?
    • +1
      antiword неправильно работает на некоторых файлах, как и catdoc.
  • +2
    Заголовок следующай статьи: «Внтуренности TAR файлов: просто ужас», и сравнивать в этой статье TAR будет с JSON. Хз, почему, но так что бы из традиции не выбиваться.
    • +3
      TAR — очень простой формат, ничего ужасного там нет. Общий заголовок + последовательно вложенные файлы с собственными заголовками.
  • 0
    Судя по этому комментарию в коде, PSD по внутреннему устройству тоже «хорош».
  • 0
    В нашем проекте тоже был необходим парсинг (полный, а не только выдерание текста) doc-а. Почитав\подумав решили не браться за этот кошмар. Используем b2xtranslator.sourceforge.net/ (.NET библиотека) вот эту либу. Багов хватает, но в целом ничего лучше не нашли. Может пригодится кому…
  • 0
    Анекдот вспомнили не тот. Вот правильный:
    Хочешь увеличить член в 10 тысяч раз? Напиши в блокноте, сохрани в ворде.
  • 0
    Мне страшно теперь думать о внутренностях powerpointa или excel…
    • 0
      В Powerpoint я заглядывал одним глазом — там что-то изощренное, но выглядящее достаточно логичным. Впрочем, исходно это была не майкрософтовская программа.
  • 0
    powerpoint
    • 0
      пропустил апостроф. «powerpoint'a» :)
  • 0
    Предполагаю, что пресловутый OLE Storage — одно из наследий Cairo — объектно-ориентированной ОС на основе OLE, разрабатывавшейся в Microsoft, но выпиленной маркетологами в пользу Windows 2000. Отсюда и таблица файлов, и прочие признаки файловой системы. В Cairo этот OLE Storage наверняка планировался как замена обычным ФС.

    Хранение списка файлов не линейным списком, а двоичным деревом похоже скорее на NTFS, нежели на FAT. Некоторые возможности NTFS, думается, тоже вобрали в себя наработки Cairo, но какие конкретно, затрудняюсь сказать.
  • 0
    Microsoft похоже самостоятельно делает всё возможное для роста популярности OpenOffice

    Аналитики отмечают резкий рост популярности решений OpenOffice (включая StarOffice, IBM Lotus Symphony). Доля этого ПО на рынке составляет 21,5% (данные 2010 года еще)


    И утилит типа Antiword.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.