Почему форматы файлов Microsoft Office настолько сложны?
Вслед за публикацией спецификаций, описывающих формат файлов Microsoft Office, Joel Spolsky написал неплохую статью, объясняющую почему формат этих файлов настолько сложен и, на первый взгляд, специально запутан до невозможности.
A normal programmer would conclude that Office’s binary file formats:
- are deliberately obfuscated
- are the product of a demented Borg mind
- were created by insanely bad programmers
- and are impossible to read or create correctly.
Если коротко, то проблема в том, что эти форматы имеют длинную историю и при их разработке преследовались совсем другие цели нежели преследовались бы при разработке формата «офисных» файлов сейчас. Это, кстати, касается и OOXML, так как этот формат по-прежнему должен поддерживать практически все возможности, которые предоставляют бинарные форматы.
Выводы в статье тоже заслуживают внимания. Если вы не пишете клон Microsoft Office (иными словами OpenOffice или StarOffice), то вполне вероятно, что идея реализовать работу с «офисными» форматами в полном объеме не слишком хороша. Вместо этого стоит либо воспользоваться OLE автоматизацией, которую приложения Microsoft Office вполне поддерживают, либо стоит выбрать формат по проще, но, при этом, совместимый с офисом.
Совет использовать OLE – это хорошо, но требует наличия Windows и MS Office, что не всегда получается.
А насчет совместимости форматов – в том же экселе, эту совместимость регулярно ломали, вводили новые типы записей и изменяли существующие. Но при этом, даже при введении новых записей оставались странные архитектурные решения – например, длина строки может быть 1 или 2 байта, и надо угадывать, что такое 2-й байт – флаги, описывающие строку, или все-таки 2-й байт поля длины. Аналогично, после разрыва между записями SST может начать использовать однобайтовую кодировку вместо 2-байтовой, и наоборот, и также без явного указания того, что произошло изменение представления данных
А никто и не обещал, что будет легко.
Вполне возможно, что на это были свои причины. Так же вполне вероятно, что это прогрммистская глупость просочилась в релиз.
Для формирования документов Microsoft Office ни компонентами ни OLE-автоматизацией не пользуюсь.
Посмотрите здесь MS Word и web-фреймворк. Продолжение
У меня приложение умеет писать в формат Word и Excel. По крайней мере так пользователю кажется. Реально – для первого случая используется функция ExportRTF, для второго – ExportHTML.
Это понятно, что во время создания формата файлов, разработчиками MS двигали определенные идеи и вполне реальные проблемы, которые они прекрасно решили. А решили они прекрасно, ведь формат файла жив и решает поставленные задачи хорошо. С другой стороны, не пора ли изменить это? Может стоит создать новый формат, который будет таким же быстрым и универсальным, но чистым от мусора? Ведь если мусор не чистить, когда-нибудь он переполнит корзину и рассыпеться на улицу? Или вы рекомендуете использовать OOXML? Мне кажеться, его разбор будет медленнее, чем doc.
Формат файла отражает функциональность приложения как зеркало. Если, скажем, перевести Word на новый 100% архитектурно правильный формат, то из Word’а придется большую часть существующей функциональности. И это будет уже не Word, а совсем другое приложение. И результат будет точно таким же как если написать новый текстовый процессор с нуля. Понадобиться немало времени, чтобы он отвоевал популярность пользователей у Word’a. Самое смешное, что к тому моменту, когда популярность будет таки завоёвана, новый процессор обрастёт не меньшим количеством архитектурных несуразиц.
К сожалению, более простой формат не всегда работает. Пример – импорт CSV, который зависит от локейла.
Естественно, а иначе бы зачем существовал более сложный формат?
Здесь вы говорите о том, что цели изменились, а раз они изменились, не следует ли переписать с целью оптимизации. Меня именно это запутало. Я так понимаю, не смотря на цели, вы считаете, что все было сделано правильно? Я просто не изучал формат, но меня взволновало, что один из сотрудников считает формат не оптимальным.
Вообще блог оставляет двоякое впечатление. С одной стороны, приятно, что сотрудники MS без проблем используют технологии конкурентов (в данном случае поиск Google), а с другой стороны, раз уж сами сотрудники не пользуются своей поисковой системой, то почему мы должны? Меня этот вопрос заинтересовал больше, потому что тестировал в последнее время разные поисковые системы и меньше всего мне понравился ask.com, а вот что использовать google или live пока не решил. на данный момент по умолчанию установлен поисковик MS и пока он находит мне все, что нужно и помещает это в первые ряды.
Переписать можно, только получится совсем другое приложение. С другим набором функций и возможностей. А что прикажете делать пользователям, которые используют функции предыдущей версии?
Все было сделано более менее в соответствии с поставленными целями. А то, что цели меняются со временем, так это нормально. С Кассандрами везде напряженка, особенно на бирже.
Да пользуйтесь тем, чем Вам удобнее пользоваться. С чего вы взяли, что Вы должны пользоваться именно live.com и ничем другим?
Я считаю, что работник компании, должен пользоваться продуктами своей фирмы. Это же лишний тестер
. Ну действительно, непонятное ощущение, что сотрудник не хочет пользоваться работой своей фирмы. Это то же самое, что если все линуксоиды будут писать Linux, а сами будут работать в Windows. Это никто не поймет. Это то же самое, что производитель Ford будет сам ездить на Chrysler, а сотрудник Колы будет пить Пепси.
А я независим и не принадлежу никакой организации, поэтому использую то, что мне нравиться. И как я сказал, сейчас тестирую live и вполне доволен. Вас я не уговариваю использовать live, а просто высказал свое мнение.
Работник компании должен компании только то, что написано в контракте/трудовом договоре/etc. Все остальное, и уж тем более то, чем занимается человек в свободное от работы время, позвольте оставить на его собственное усмотрение. Или вы отказываете работникам McDonalds в возможности есть здоровую пищу?
Вы знаете, я тоже не принадлежу никакой организации.
(Not a kernel guy: перенес сюда)
> Воспользоваться OLE автоматизацией
А линукса, конечно же, не существует?
Это был не единственный вариант, предложенный в статье.