Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 211
>>Самым разумным было бы (как и сделали в OpenOffice) упаковать все в
>>архив ZIP (можно без архивации, если она не нужна). Но в
>>«Майкрософте», очевидно, процветает синдром «Not invented here».
>>Главное — изобрести велосипед, пусть и трехколесный, но собственный.
.docx (Office Open XML) — формат по-умолчанию, начиная с Word 2007. Там всё хранится в архивах, а внутри XML.
.doc разрабатывался лет 20 назад. В несовременности его обвинять можно, как и любой формат 20 летней давности.
>>архив ZIP (можно без архивации, если она не нужна). Но в
>>«Майкрософте», очевидно, процветает синдром «Not invented here».
>>Главное — изобрести велосипед, пусть и трехколесный, но собственный.
.docx (Office Open XML) — формат по-умолчанию, начиная с Word 2007. Там всё хранится в архивах, а внутри XML.
.doc разрабатывался лет 20 назад. В несовременности его обвинять можно, как и любой формат 20 летней давности.
TEX?
Я сравнивал форматы физического хранения, где в одном реальном файле находится несколько логических. (автор критикует, что в Office до 2007 не используются ZIP архивы)
А Tex да, формат хороший. Но это скорее декларативный язык программирования.
А Tex да, формат хороший. Но это скорее декларативный язык программирования.
Я вот к этому:
>> В несовременности его обвинять можно, как и любой формат 20 летней давности.
TEX имел достаточно мало редакций.
>> В несовременности его обвинять можно, как и любой формат 20 летней давности.
TEX имел достаточно мало редакций.
И тем не менее, при всех красивых словах о его исключительной архитектуре и красоте, он добавляет приносит долю красноглазия. И если в Word можно забить на некоторые огрехи, то при использовании TeX-а так и хочется их исправить, что убивает время :)
Вы подменяете понятия.
Я лишь указал на наличие качественного формата которому свыше 20-ти лет.
Холиварить на тему TeX vs Word не вижу смысла:
Word — текстовый процессор (ну в каком-то приближении :)
TeX — система вёрстки.
Я лишь указал на наличие качественного формата которому свыше 20-ти лет.
Холиварить на тему TeX vs Word не вижу смысла:
Word — текстовый процессор (ну в каком-то приближении :)
TeX — система вёрстки.
Нисколько, это намеренный уход от темы, хотя и похожий на троллинг.
Вот именно, в TeX же формат текстовый. А картинки? А остальное? EPS? Ну так там тоже бывает чёрт ногу сломит. И то, нужно всегда держать в голове с пяток способов сделать из TeX PDF со своими заморочками посередине и своим набором пакетов, которые при этом будут глючить :)
Вот именно, в TeX же формат текстовый. А картинки? А остальное? EPS? Ну так там тоже бывает чёрт ногу сломит. И то, нужно всегда держать в голове с пяток способов сделать из TeX PDF со своими заморочками посередине и своим набором пакетов, которые при этом будут глючить :)
Либо EPS, либо PDF, уж определитесь. А то вы во всех грехах TeX вините.
За неимением кармы прокомментирую здесь и всех кто указывает на дату разработки формата .doc (CDF).
Посмотрите заодно и дату разработки .zip.
За неимением кармы прокомментирую здесь и всех кто указывает на дату разработки формата .doc (CDF).
Посмотрите заодно и дату разработки .zip.
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.
Джоэл Спольски:
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.
Не важно, в каком формате будет результат, я говорю лишь о том, что одним plain TeX не обойтись. А проблем с ТеХом особых и нет, вопрос как быстро они решаются :)
3 основные и около 7 минорных обновлений последней редакции (последняя версия — 2008 г.).
При этом надо понимать, что ТеХ решает узкоспециализированную задачу, которая с момента создания языка практически не изменилась ;)
При этом надо понимать, что ТеХ решает узкоспециализированную задачу, которая с момента создания языка практически не изменилась ;)
ZIP — тоже формат физического хранения, где в одном реальном файле находится несколько логических. И тоже 20-летней давности. Но это не мешает ему быть относительно логичным.
Я говорил не про логичность, а про современность. ZIP 20 летней давности несовременен. Но ZIP развивался плавно. С помощью Windows API чить файлы офисовского формата очень легко. А разбирать руками ZIP формат — намного сложнее. Всё относительно.
>С помощью Windows API чить файлы офисовского формата очень легко. А разбирать руками ZIP формат — намного сложнее.
Хорошее у Вас сравнение получилось: читать формат1 при помощи готового парсера VS разбирать формат2 руками :)
Давайте я Вам ещё подкину: с помощью библиотеки libzip читать zip-файлы очень легко. А разбирать руками JSON — намного сложнее %)
К чему я это? К тому, что сравнивать надо или «разбирать либой VS разбирать либой», или «разбирать руками VS разбирать руками». В первом случае различия минимальны, во втором — ZIP побеждает с большим отрывом. Можете для сравнения глянуть сорцы любого опенсорсного zip-парсера и прикинуть, уложится ли в такой же объём парсер офисных форматов :)
Хорошее у Вас сравнение получилось: читать формат1 при помощи готового парсера VS разбирать формат2 руками :)
Давайте я Вам ещё подкину: с помощью библиотеки libzip читать zip-файлы очень легко. А разбирать руками JSON — намного сложнее %)
К чему я это? К тому, что сравнивать надо или «разбирать либой VS разбирать либой», или «разбирать руками VS разбирать руками». В первом случае различия минимальны, во втором — ZIP побеждает с большим отрывом. Можете для сравнения глянуть сорцы любого опенсорсного zip-парсера и прикинуть, уложится ли в такой же объём парсер офисных форматов :)
Я про то, что в Windows есть стандартные средства для работы с Office форматом файлов. Написать аналогичную библиотеку для других платформ — дело максимум месяца. Строк кода там совсем немного. Меньше 500. Гораздо сложнее разбираться с телом самого документа. Но это другой вопрос. ZIP описывает формат _до_ собственно документа (там может лежать хоть картинкиь, хоть AutoCAD файлы. Парсеру ZIP всёравно). Только хранение. Самое сложное в работе с Office файлами — это то, что отсутствует в ZIP — работа с документом.
Кстати, парсер XML — вещь весьма нетривиальная.
Кстати, парсер XML — вещь весьма нетривиальная.
TEX — это не формат! TEX хранится в простом текстовом формате, TEX — это возможно расширение файла, и это typesetting system (отсюда en.wikipedia.org/wiki/TeX).
Ну doc я тоже могу блокнотом открыть :)
А при определенном навыке даже что-то прочитать смогу.
У ТЕХа текстовая сериализация, что подразумевает сложный парсер, у doc — двоичная сериализация и парсер попроще.
А при определенном навыке даже что-то прочитать смогу.
У ТЕХа текстовая сериализация, что подразумевает сложный парсер, у doc — двоичная сериализация и парсер попроще.
Судя по тексту топика, парсер doc не только не проще парсера tex, он и не проще системы управления межконтинентальными ракетами.
Это если с нуля его писать, придется воспроизводить все ошибки в архитектуре ворда за 20 лет.
Парсер TeX элементарен, но это непростой императивный язык, код на котором нужно ещё выполнить чтобы получить данные. После разбора .doc получаем готовые данные.
Конечно, реализация TeX открыта и всем доступна для портирования на свою любимую платформу и применения в любых целях, поэтому его сложность, в отличие от .doc, на практике не имеет никакого значения.
Конечно, реализация TeX открыта и всем доступна для портирования на свою любимую платформу и применения в любых целях, поэтому его сложность, в отличие от .doc, на практике не имеет никакого значения.
Это не формат, а язык разметки.
TeX корректно сравнивать даже не знаю с чем… С bat/cmd? Или с недо-sh :]
С postscript?
TeX — скриптовый язык? o.O
Обычно я прошу поделиться травкой, но, боюсь, эта для меня слишком.
Обычно я прошу поделиться травкой, но, боюсь, эта для меня слишком.
А какой? В нем можно дефить свои последовательности, счетчики, сбрасывать данные на диск :) Это уж точно не формат данных.
Это язык, описвающий документ для системы вёрстки, который стал Тьюринг-полным только благодаря (*заглядывает в википедию*) Гаю Стилу.
Хотите сказать Java тоже аналог bat или sh? И циклы есть и файловый ввод-вывод. Только назначение (и, соответственно, набор фич) у sh, TeX и Java немного разное.
Как упомянули выше, TeX можно сравнить только с ps, который на самом деле ЯП, но почему-то весь мир считает, что это формат данных. Отличие лишь в том, что с ps в современном мире больше работают программы, а с TeX — люди.
Хотите сказать Java тоже аналог bat или sh? И циклы есть и файловый ввод-вывод. Только назначение (и, соответственно, набор фич) у sh, TeX и Java немного разное.
Как упомянули выше, TeX можно сравнить только с ps, который на самом деле ЯП, но почему-то весь мир считает, что это формат данных. Отличие лишь в том, что с ps в современном мире больше работают программы, а с TeX — люди.
Аналог — это не я придумал ;) Я всего лишь хочу сказать, что помещать в один контекст форматы данных для которых нужен парсер и «форматы» для которых нужен интерпретатор — наверное не стоит.
C сравнением с ps я молчаливо согласился, если что, хотя тут сравнение сродне sh-java имхо :]
Все же интересно, много ли людей работают с TeX'ом (plain)? ^_^
C сравнением с ps я молчаливо согласился, если что, хотя тут сравнение сродне sh-java имхо :]
Все же интересно, много ли людей работают с TeX'ом (plain)? ^_^
Видимо, чтобы ненавидеть MS особенно тщательно, нужно игнорировать все, что они делают. Вместо этого нужно под микроскопом разбирать 21-е прерывание и смаковать неудачные вызовы. Ведь что ни говори, а API они делать не умеют, совсем не умеют.
Office Open XML не лучший пример… столько рожали и родили такого монстра. Одно описание, если не ошибаюсь 6000 страниц! Да и в принципе от бинарного старого они далеко не ушли, просто в XML перевели (даже битовые маски оставили… в xml!!!)
То есть 20 лет назад писать гавенный код было нормой? )
По моему автор совсем не обвиняет код в несовременности.
По моему автор совсем не обвиняет код в несовременности.
Почему «гавенный код»? Где вообще что-то про код? Compound file — оптимизированный бинарный формат общего назначения, для которого в Windows есть прекрасный API. И почти любой программист за неделю напишет его парсер в Unix среде (формата хранения, не контента). Более того, под Linux есть несколько хороших библиотек (http://pole.berlios.de/).
Если бы 20 лет назад кто-то предложил использовать ZIP формат и не дай Бог что-то похожее на XML, как предлагает автор, то его бы просто послали.
Вся сложность .doc формата вытекает из сложности редактора и наличия множества его обратно совместимых версий.
Так что формат неплох, просто он оптимизировался под аппаратные требования 20 летней давности, из-за чего сейчас кажется устаревшим. Джоел про это хорошо пишет. 20 лет назад было нормой писать под 386 процессор и единицы мегабайт памяти, сохранять данные на дискете. Исходя из этого ставились требования. Про Linux, кстати ни в домашней, ни в корпоративной среде никто тоже не знал.
Если бы 20 лет назад кто-то предложил использовать ZIP формат и не дай Бог что-то похожее на XML, как предлагает автор, то его бы просто послали.
Вся сложность .doc формата вытекает из сложности редактора и наличия множества его обратно совместимых версий.
Так что формат неплох, просто он оптимизировался под аппаратные требования 20 летней давности, из-за чего сейчас кажется устаревшим. Джоел про это хорошо пишет. 20 лет назад было нормой писать под 386 процессор и единицы мегабайт памяти, сохранять данные на дискете. Исходя из этого ставились требования. Про Linux, кстати ни в домашней, ни в корпоративной среде никто тоже не знал.
Давайте сразу забудем про 20 лет и будем говорить честно — этому формату 13 лет. Про Linux и Mac, а тем более про Unix было уже давно известно. А OOXML — хотя и новый формат, совсем не образец для подражания.
DOC формат очень громоздкий и под запись на дискету не очень оптимизированный, большие документы приходилось разбивать.
Сложный формат — лишний сложный код. Выполнялся такой код долго даже на машинах того времени, так что ни о каких 386x речь вообще не идет.
Почему ZIP+XML (или что-то типа того) плохо использовать не понимаю. XML очень избыточный, ZIP хорошо жмет XML, степенью сжатия можно контролировать скорость открытия/закрытия.
Вывод: Microsoft пишет плохой код, создает плохие форматы — потому что у нее маленькая конкуренции в конкретной сфере и вместо того что бы выпускать хорошие программы, она давит конкурентов, как в случае с OOXML. Microsoft начинает выпускать хорошие программы только для сфер где они безнадежно отстали от конкурентов (что бы их догнать) или где они потерпели сокрушительное поражение (чтобы реабилитироватся).
DOC формат очень громоздкий и под запись на дискету не очень оптимизированный, большие документы приходилось разбивать.
Сложный формат — лишний сложный код. Выполнялся такой код долго даже на машинах того времени, так что ни о каких 386x речь вообще не идет.
Почему ZIP+XML (или что-то типа того) плохо использовать не понимаю. XML очень избыточный, ZIP хорошо жмет XML, степенью сжатия можно контролировать скорость открытия/закрытия.
Вывод: Microsoft пишет плохой код, создает плохие форматы — потому что у нее маленькая конкуренции в конкретной сфере и вместо того что бы выпускать хорошие программы, она давит конкурентов, как в случае с OOXML. Microsoft начинает выпускать хорошие программы только для сфер где они безнадежно отстали от конкурентов (что бы их догнать) или где они потерпели сокрушительное поражение (чтобы реабилитироватся).
>>Давайте сразу забудем про 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. И менее затратен.
Спецификация 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. И менее затратен.
>В 1993 году формат был в продакшене. Разрабатывался он ранее. Поэтому формату 19 лет минимум.
Два года многовато для разработки такого формата. Кроме того я думаю на разработку его вообще не ушло времени. Делали так как проще для того что-бы побыстрее выпустить версию. Никто не задумывался о том чтобы сделать формат удобным, просто каждый выпуск довешивал в него разные фичи.
Не нужно называть это форматом который появился 19 лет назад. Он все это время разрабатывался. Автор занимается разбором формата которому не больше 7ми лет.
>Бинарный формат Office очень прост для обработки. В разы проще XML. И менее затратен.
Зато очень сложен для понимания. И даже после понимания, из-за закрытости формата и необходимости поддерживать старые версии, формат выглядит уродливым монстром со всякими CHP, PAPX, SHST, PLCF итд.
Два года многовато для разработки такого формата. Кроме того я думаю на разработку его вообще не ушло времени. Делали так как проще для того что-бы побыстрее выпустить версию. Никто не задумывался о том чтобы сделать формат удобным, просто каждый выпуск довешивал в него разные фичи.
Не нужно называть это форматом который появился 19 лет назад. Он все это время разрабатывался. Автор занимается разбором формата которому не больше 7ми лет.
>Бинарный формат Office очень прост для обработки. В разы проще XML. И менее затратен.
Зато очень сложен для понимания. И даже после понимания, из-за закрытости формата и необходимости поддерживать старые версии, формат выглядит уродливым монстром со всякими CHP, PAPX, SHST, PLCF итд.
>>Два года многовато для разработки такого формата. Кроме того я думаю на разработку его вообще не ушло времени
Вы заявляете в предыдущих постах, что Microsoft совсем не потратила времени на разработку формата целью которого было убить конкурентов в виде Linux в 1993 году и вообще захватить мир. Это троллинг.
У формата есть недостатки, но это не самый плохой формат.
>>Автор занимается разбором формата которому не больше 7ми лет.
Автор рассматривает ту часть, которая на 95% не менялась с самого начала.
Вы заявляете в предыдущих постах, что Microsoft совсем не потратила времени на разработку формата целью которого было убить конкурентов в виде Linux в 1993 году и вообще захватить мир. Это троллинг.
У формата есть недостатки, но это не самый плохой формат.
>>Автор занимается разбором формата которому не больше 7ми лет.
Автор рассматривает ту часть, которая на 95% не менялась с самого начала.
> Вы заявляете в предыдущих постах, что Microsoft совсем не потратила времени на разработку формата целью которого было убить конкурентов в виде Linux в 1993 году и вообще захватить мир.
В предыдущих комментариях я говорю только то что Микрософт разрабатывает все свои продукты спустя рукава, все где конкуренты не обошли Микрософт на несколько кругов.
>У формата есть недостатки, но это не самый плохой формат.
У любого формата есть недостатки и нету эталона самого плохого формата. Просто этот конкретный формат очень плохой.
>Автор рассматривает ту часть, которая на 95% не менялась с самого начала.
Нет. Формат стал очень плохим именно из-за того что изначально не был хорошо продуман, а был обвешан со временем разными фичами. Надо рассматривать то что есть, а не то что в идеале.
>Это троллинг.
Вы наверное плохо представляете что такое «троллинг», для троллинга у меня все карты на руках, я мог бы аппелировать и к вашему возрасту, и к вашей слепой фанатичной преданности Микрософту, и к синдрому «в интернете кто-то не прав», и чему угодно. Честно говоря не скажу что вы хоть сколько нибудь сложная цель для троллинга.
Или, что скорее всего, вы достаточно хорошо представляете что такое троллинг и начинаете троллинг, в стиле «Ты тролль» из-за отсутствия аргументов. )
В предыдущих комментариях я говорю только то что Микрософт разрабатывает все свои продукты спустя рукава, все где конкуренты не обошли Микрософт на несколько кругов.
>У формата есть недостатки, но это не самый плохой формат.
У любого формата есть недостатки и нету эталона самого плохого формата. Просто этот конкретный формат очень плохой.
>Автор рассматривает ту часть, которая на 95% не менялась с самого начала.
Нет. Формат стал очень плохим именно из-за того что изначально не был хорошо продуман, а был обвешан со временем разными фичами. Надо рассматривать то что есть, а не то что в идеале.
>Это троллинг.
Вы наверное плохо представляете что такое «троллинг», для троллинга у меня все карты на руках, я мог бы аппелировать и к вашему возрасту, и к вашей слепой фанатичной преданности Микрософту, и к синдрому «в интернете кто-то не прав», и чему угодно. Честно говоря не скажу что вы хоть сколько нибудь сложная цель для троллинга.
Или, что скорее всего, вы достаточно хорошо представляете что такое троллинг и начинаете троллинг, в стиле «Ты тролль» из-за отсутствия аргументов. )
>>Просто этот конкретный формат очень плохой.
Если этот формат плох, какой формат-конкурент лучше? Где эти хорошие форматы? Чем плох .doc? Бинарностью? Нет, это плюс.
Если этот формат плох, какой формат-конкурент лучше? Где эти хорошие форматы? Чем плох .doc? Бинарностью? Нет, это плюс.
К контейнеру как раз у автора претензий не очень много:
Формат CDF при всей своей монструозности хотя бы логичен и не очень сложен.
Обратите внимание на раздел статьи WordDocument.
Претензии к формату в основном сводятся к тому что он не продуманный и соответственно плохо расширяемый. По этой причине, возможно изначально и приемлемый, формат превратился в уродливого монстра после кое-как дабавленных в него множества фич.
У этого монстра заголовок на треть файла и забит он зарезервированными и несипользуемыми местами. Он противоречит сам себе игнорируя свой флаг fComplex. И пытается сэкономить места побыстренькому, кодируя английский язык не так как другие.
Вот это все множество оговорочек и условностей и превращают формат в «очень плохой». На самом деле если какие-то фичи красиво впихнуть не получается, нужно переделывать формат.
Формат CDF при всей своей монструозности хотя бы логичен и не очень сложен.
Обратите внимание на раздел статьи WordDocument.
Претензии к формату в основном сводятся к тому что он не продуманный и соответственно плохо расширяемый. По этой причине, возможно изначально и приемлемый, формат превратился в уродливого монстра после кое-как дабавленных в него множества фич.
У этого монстра заголовок на треть файла и забит он зарезервированными и несипользуемыми местами. Он противоречит сам себе игнорируя свой флаг fComplex. И пытается сэкономить места побыстренькому, кодируя английский язык не так как другие.
Вот это все множество оговорочек и условностей и превращают формат в «очень плохой». На самом деле если какие-то фичи красиво впихнуть не получается, нужно переделывать формат.
Это хуже, чем аморальность. Это просто плохо написано.
(Оскар Уайльд)
(Оскар Уайльд)
Надо заметить, что, во-первых, это не сильно востребованная операция, поскольку все программы обычно записывают документы от начала до конца в один проход.Системные требования к 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
Пожалуйста, впихните в 8 метров оперативы эти ваши программы вместе с данными, которые они записывают в файлы в один проход.
В один проход можно записать хоть 100ГБ, было бы место и поддерживала бы ФС, не понимаю причем тут ОЗУ.
А своп зачем? В смысле, что из свопа читать, что из файла на винте — все равно задействовать винт. Думаю, что МС так и делает, судя по скорости работы 97 офиса на 8М ОЗУ под win95. Но в ДОС это было актуально и, учитывая что формат пошел с тех времен, решение понятно. Непонятно, почему формат не обновляли, ведь обратная совместимость со старыми версиями все равно не гарантировалась, а когда потребовалось кардинально поменять формат — выпустили дополнение к старой версии просто. Могли бы и раньше так делать.
На свопе оверхед больше получается, вообще-то.
Теоретически, если правильно организовать, то нет. В смысле больше, но для пользователя не особенно критично получается. С другой стороны, при большем количестве оперативы, за счет ОС все ускорится, а если с файлом напрямую работать, то надо отдельно этот случай учитывать.
В прочем, во времена 97го офиса, файлы больше метра были редкостью, только если с картинками или совсем большие, но они и так тормозили, решение не использовать своп помогало мало. Если оно было, конечно.
В прочем, во времена 97го офиса, файлы больше метра были редкостью, только если с картинками или совсем большие, но они и так тормозили, решение не использовать своп помогало мало. Если оно было, конечно.
Зачем отказываться от возможности ускорить обработку файла, тем более что механизм отработанный есть?
Вы имеете в виду работа с кусочками файла, а не целым файлом + своп? на сколько я помню, в реальности такого и небыло, большие файлы долго открывались и сохранялись и жутко тормозили, а в рекламе формата PDF указывалось как одно из преимуществ то, что скорость работы с ним не зависит от размера файла (в противоположность ворду).
Что ж это, мокросовт не удосужились оптимизировать висту, а док оптимизировали для компов с небольшим числом озу?
Несколько способов редактировать файлы размером больше оперативки придумали ещё до того, как дядя Билли написал свой бейсик. Так что это всё гнилые отмазки. Можно ещё вспомнить блокнот, который, в каком, говорите, году таки научился открывать файлы больше 64К размером? Или всё еще не умеет? :). Кстати, если выкинуть из док файлов фат, минифат и микрофат со всеми их сбалансированными деревьями, и прочие ненужные заголовки, то средний размер файлов раза в 2 уменьшится — вот вам и ускорение работы и возможность работы с бОльшими файлами без тормозов и тд.
Чтобы такой адский труд не пропал, реквестирую модуль на сипане!
Что касается извлечения всего с форматированием: я выбрал конвертацию .doc -> .rtf прямо в ворде ручками (если документов много, можно нанять китайцев). Распотронить RTF намного легче (хотя тоже не сахар).
Что касается извлечения всего с форматированием: я выбрал конвертацию .doc -> .rtf прямо в ворде ручками (если документов много, можно нанять китайцев). Распотронить RTF намного легче (хотя тоже не сахар).
RTF c потерями конвертируется. Понятно, что для задачи вытянуть текст годится, но тогда непонятно, почему уже сразу в txt не экспортить, чтобы и rtf не возиться еще.
Да ну ладно. Вы его вообще видели, RTF? Почти всё форматирование, которое только может понадобиться, там есть, плюс таблицы, картинки, ссылки и параметры страниц.
Можно обойтись и без китайцев, подключившись к Ворду по OLE Automation
Вы удивитесь, но есть люди, которые сайты делают в Word. То есть набивают документ, ссылки etc. и сохраняют как HTML-документ. Даже предлагают услуги по созданию сайтов именно таким способом, я серьёзно.
В итоге даже такой «сайт»:
Выливается вот в такой вот «код»:
В итоге даже такой «сайт»:
Выливается вот в такой вот «код»:
спасибо за открытие Америки
думаю, каждый, кто начинал свои эксперименты по созданию веб-страниц более 7-10 лет назад, хоть когда-то это делал :)
Ворд НЕ ПРЕДНАЗНАЧЕН для создания веб-документов и их публикации
тем более о стандартах W3C там речи не шло и не идет
думаю, каждый, кто начинал свои эксперименты по созданию веб-страниц более 7-10 лет назад, хоть когда-то это делал :)
Ворд НЕ ПРЕДНАЗНАЧЕН для создания веб-документов и их публикации
тем более о стандартах W3C там речи не шло и не идет
Какие чудесные названия! UseAsianBreakRules, DontGrowAutofit и особенно LatentStyles! Боюсь предположить, что это за латентные стили
А когда вставляют в fck или tiny? Тоже самое, только разрабами поддерживается. По умолчанию только ck стал чистить, но с tidy не сравнится.
Какие все дураки — один Вы — умный…
Только почему-то не поймёте никак, что документ, сохранённый так соответствует исходному документы и может быть засунут обратно в ворд практически без искажений. А для извращенцев, клепающих в ворде сайты есть опция, которая даёт намного более чистый html. Но куда проще подлить желчи, чем разобраться…
Только почему-то не поймёте никак, что документ, сохранённый так соответствует исходному документы и может быть засунут обратно в ворд практически без искажений. А для извращенцев, клепающих в ворде сайты есть опция, которая даёт намного более чистый html. Но куда проще подлить желчи, чем разобраться…
А для извращенцев, клепающих в ворде сайты
… был давно придуман биореактор.
Странно, что никому не нужной (я бы даже сказал, противоестественной) функции чтения вордовского файла из html без искажений уделено гораздо больше внимания, чем намного более востребованной — сгенерировать по тексту простенький html. Да и появилась вторая функция намного позже первой.
Попробуйте написать в ворде одно слово, задать ему цвет, сохранить в html, а затем откройте в блокноте и посчитайте количество строк. Вы заплачете, я гарантирую!
А у нас была горе-редактор, которая делала так: открывала статью в MS Word, нажимала заветные Ctrl+C и вставляла в редактор CMS, вместе с вышеприведенной билибирдой. Ох, какие странички на сайте были…
>Если вы хотите работать с ними, используйте Windows API для OLE.
Который, разумеется, доступен на любой платформе на выбор?
Который, разумеется, доступен на любой платформе на выбор?
Хм… А что, zip, tar, bzip2 доступен на любой платформе на выбор? Или может ELF формат кросплатформенный? О чём вообще речь?
>А что, zip, tar, bzip2 доступен на любой платформе на выбор?
Ну что ж, давайте сравним: zip, tar, bzip2 доступны на Windows, Linux, Mac OS, *BSD, VxWorks, QNX (это из тех, с которыми мне приходилось сталкиваться, но я уверен, что список этот неполный). Давайте теперь заслушаем список платформ, на которых доступен Windows API для OLE :)
Ну что ж, давайте сравним: zip, tar, bzip2 доступны на Windows, Linux, Mac OS, *BSD, VxWorks, QNX (это из тех, с которыми мне приходилось сталкиваться, но я уверен, что список этот неполный). Давайте теперь заслушаем список платформ, на которых доступен Windows API для OLE :)
Не путайте «много где» с «на любой платформе».
хабр съел пост…
Да, архиваторы — неудачный пример (в винде ведь всё есть =) ). А вот ELF, думаю, вполне подойдёт.
Windows API для OLE доступен на 90+% копьютеров (не считая Wine и виртуальных машин).
Да, архиваторы — неудачный пример (в винде ведь всё есть =) ). А вот ELF, думаю, вполне подойдёт.
Windows API для OLE доступен на 90+% копьютеров (не считая Wine и виртуальных машин).
>Да, архиваторы — неудачный пример (в винде ведь всё есть =) ). А вот ELF, думаю, вполне подойдёт.
Вы уверены, что сравнивать формат офисных документов и формат исполняемых файлов одной конкретной платформы — корректно?
Windows API для OLE доступен на 90+% копьютеров
Задача автоматического разбора документов — не вполне типичная задача для десктопа, не находите?
А в «более другом» сегменте компьютеров 90 процентами Винды и не пахнет.
Вы уверены, что сравнивать формат офисных документов и формат исполняемых файлов одной конкретной платформы — корректно?
Windows API для OLE доступен на 90+% копьютеров
Задача автоматического разбора документов — не вполне типичная задача для десктопа, не находите?
А в «более другом» сегменте компьютеров 90 процентами Винды и не пахнет.
>сравнивать формат офисных документов и формат исполняемых файлов
Я думал, что вы примерно понимаете, что это за формат (compond document и OLE)… Похоже, что нет. Сompond document format позволяет внедрять в/объединять документы, созданные любыми (поддерживающими соответствующие интерфейсы) программами. Таких программ немало и написаны они далеко не только MS. Представьте, что вам надо в документе Word использовать графики из Excel, формулы, какие-нибудь хитрые схемы, например, из CAD программы. Можно встроить функциональность всех этих программ в Word, но очевидно, что это неправильный путь. Можно заставить пользователя вместо схем/графиков/моделей/и т.д. вставлять в документ скриншоты (и обновлять их во всех документах каждый раз, когда что-нибудь изменится). Логичное решение задачи — создание системы позволяющей, связывать объекты, созданные разными приложениями. Реализовано это в виде набора программных интерфейсов (позволяющих другой программе открывать/редактировать/сохранять объекты, созданые другой программой) и единого места, где программы, поддерживающие OLE могут регистрировать свои классы. Формат сериализации, очевидно, был бинарным, потому, что текстовый формат компьютеры бы не потянули (да и сейчас большинство форматов на всех платформах бинарны).
Основных проблем с имплементацией этого для *nix две.
Во первых, количество людей, которым нужен автоматический разбор документов и которые ну просто обязаны делать это на неродной платформе и без использования эмуляторов/виртуальных машин примерно равно нулю. Если умножить этот ноль на тот ноль денег, которые эти люди готовы заплатить за такую возможность, то получится ноль в квадрате. Поставив себя на место MS, я не вижу ни одной причины думать об использовании их офисных программ/форматов на *nix (и уж тем более, в те времена, когда доля линукса была не 1%, а 0%).
Во вторых, в *nix отсутствует инфраструктура, на которой основаны форматы. Там нет ничего, что бы хотя бы отдалённо напоминало OLE или COM. Да что там COM… нет даже (стандартного) способа связать тип файла с соответствующим приложением. Есть несколько различных простеньких реализаций, но стандартного способа нет. Как можно сделать формат «для всех платформ», если на других платформах необходимая инфраструктура находится там в таком зачаточном состоянии? Не предлагаете же Вы всё делать под «общий знаменатель»?
Я думал, что вы примерно понимаете, что это за формат (compond document и OLE)… Похоже, что нет. Сompond document format позволяет внедрять в/объединять документы, созданные любыми (поддерживающими соответствующие интерфейсы) программами. Таких программ немало и написаны они далеко не только MS. Представьте, что вам надо в документе Word использовать графики из Excel, формулы, какие-нибудь хитрые схемы, например, из CAD программы. Можно встроить функциональность всех этих программ в Word, но очевидно, что это неправильный путь. Можно заставить пользователя вместо схем/графиков/моделей/и т.д. вставлять в документ скриншоты (и обновлять их во всех документах каждый раз, когда что-нибудь изменится). Логичное решение задачи — создание системы позволяющей, связывать объекты, созданные разными приложениями. Реализовано это в виде набора программных интерфейсов (позволяющих другой программе открывать/редактировать/сохранять объекты, созданые другой программой) и единого места, где программы, поддерживающие OLE могут регистрировать свои классы. Формат сериализации, очевидно, был бинарным, потому, что текстовый формат компьютеры бы не потянули (да и сейчас большинство форматов на всех платформах бинарны).
Основных проблем с имплементацией этого для *nix две.
Во первых, количество людей, которым нужен автоматический разбор документов и которые ну просто обязаны делать это на неродной платформе и без использования эмуляторов/виртуальных машин примерно равно нулю. Если умножить этот ноль на тот ноль денег, которые эти люди готовы заплатить за такую возможность, то получится ноль в квадрате. Поставив себя на место MS, я не вижу ни одной причины думать об использовании их офисных программ/форматов на *nix (и уж тем более, в те времена, когда доля линукса была не 1%, а 0%).
Во вторых, в *nix отсутствует инфраструктура, на которой основаны форматы. Там нет ничего, что бы хотя бы отдалённо напоминало OLE или COM. Да что там COM… нет даже (стандартного) способа связать тип файла с соответствующим приложением. Есть несколько различных простеньких реализаций, но стандартного способа нет. Как можно сделать формат «для всех платформ», если на других платформах необходимая инфраструктура находится там в таком зачаточном состоянии? Не предлагаете же Вы всё делать под «общий знаменатель»?
>Я думал, что вы примерно понимаете, что это за формат (compond document и OLE)… Похоже, что нет.
Прекрасно понимаю. Но всё равно не вижу, каким образом могла бы быть проведена аналогия между форматом исполняемых файлов одной конкретной платформы и форматом для хранения данных (да, который на самом деле контейнер для всего-всего-всего, что не меняет его предназначения: хранение данных).
>Поставив себя на место MS, я не вижу ни одной причины думать об использовании их офисных программ/форматов на *nix
А Вам где-то показалось, что я требовал от МС где-то думать об этом? Вам показалось. Перечитайте первый мой комментарий в данной ветке: я всего лишь прозрачно намекнул, что предложение «почему бы не использовать OLE API» могло оказаться немного не в кассу ввиду целевой платформы, отличной от семейства Windows — только и всего. А уж какой подтекст в этом увидели Вы — ведомо лишь Вам одному.
Прекрасно понимаю. Но всё равно не вижу, каким образом могла бы быть проведена аналогия между форматом исполняемых файлов одной конкретной платформы и форматом для хранения данных (да, который на самом деле контейнер для всего-всего-всего, что не меняет его предназначения: хранение данных).
>Поставив себя на место MS, я не вижу ни одной причины думать об использовании их офисных программ/форматов на *nix
А Вам где-то показалось, что я требовал от МС где-то думать об этом? Вам показалось. Перечитайте первый мой комментарий в данной ветке: я всего лишь прозрачно намекнул, что предложение «почему бы не использовать OLE API» могло оказаться немного не в кассу ввиду целевой платформы, отличной от семейства Windows — только и всего. А уж какой подтекст в этом увидели Вы — ведомо лишь Вам одному.
Кстати, в Редмонде тоже не дураки сидят, офис стоит на порядок дороже ОС, поэтому там я думаю прикинули в столбик и поняли, что не стоит заморачиватся, писать версию под *nix, увеличивая стоимость продукта, т.к. люди не будут отказываться от продукта, если для его работы надо потратить еще 1/10 часть на ось
> Там нет ничего, что бы хотя бы отдалённо напоминало OLE или COM. Да что там COM…
Потому что они не нужны. И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
> нет даже (стандартного) способа связать тип файла с соответствующим приложением.
Непонятно, что тут имеется ввиду. Чем mime-type не устраивает? Что, существует другой способ связать программу с типом файла?
Потому что они не нужны. И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
> нет даже (стандартного) способа связать тип файла с соответствующим приложением.
Непонятно, что тут имеется ввиду. Чем mime-type не устраивает? Что, существует другой способ связать программу с типом файла?
>Потому что они не нужны.
Я нигде не утверждал, что они нужны. Я просто констатировал факт, что их нет. А так, да, они не нужны. В винде не нужны, потому, что она их переросла (постепенный переход к .Net), а в линуксе — потому, что он до такого ещё не дорос.
Как паровой двигатель, не нужный ни первобытным племенам, ни современным людям.
>И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…
>Чем mime-type не устраивает?
Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.
Я нигде не утверждал, что они нужны. Я просто констатировал факт, что их нет. А так, да, они не нужны. В винде не нужны, потому, что она их переросла (постепенный переход к .Net), а в линуксе — потому, что он до такого ещё не дорос.
Как паровой двигатель, не нужный ни первобытным племенам, ни современным людям.
>И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…
>Чем mime-type не устраивает?
Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.
file
Ну куда же Вы со своим отсталым «file» (который однозначно идентифицирует MIME-type файла по его заголовку) из каменного века? Прогресс — он ить в трёх-четырёх заветных буковках после точечки в конце имени файла! :)
Ну почему-же сразу отсталый. Процессоры же становятся всё быстрее — циклы некуда девать. Какой смысл быстро искать «буковки после точечки» в быстрой хэш таблице? Лучше откроем файл (а ещё лучше, сначала закачаем его из сети), вдумчиво почитаем его, и гордо ответим, что это «что-то напоминающее XML».
Да, точно, Вы правы. Для определения MIME-type совершенно необходимо прочитать весь файл целиком, без этого — ну просто никак! Поэтому для того, чтобы смотреть HD-видео под Linux нужен как минимум суперкомпьютер с 32 гигами оперативы — нужно же прочитать весь файл целиком и проанализировать его!
Жгите ещё!
Жгите ещё!
Эээ… Вы как-бы понимаете хотя бы примерно сколько операция надо тупо на то, чтобы открыть файл и прочитать пару байт? А чтобы потом применить строковую регулярку? И на сколько порядков больше операций надо сделать в случае, если файл находится не на локальной машине?
//Клуб противников эффективных алгоритмов всё ширится…
//Клуб противников эффективных алгоритмов всё ширится…
Вы как бы понимаете, что сравниваются не отдельные задачи «применить строковую регулярку к имени файла» VS «открыть файл, прочитать пару байт, применить строковую регулярку», а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
На сколько порядков больше времени потребует запуск самой программы+чтение программой файла (целиком) по сравнению с чтением пары байт? Сколько Вы выиграете своей регуляркой по имени файла? 0.01%? Внушает! Видимо, слова «premature optimization» и «bottle neck» Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
// клуб противников здравого смысла всё ширится…
На сколько порядков больше времени потребует запуск самой программы+чтение программой файла (целиком) по сравнению с чтением пары байт? Сколько Вы выиграете своей регуляркой по имени файла? 0.01%? Внушает! Видимо, слова «premature optimization» и «bottle neck» Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
// клуб противников здравого смысла всё ширится…
На всякий случай, уточню, что обсуждение сейчас идёт о эффективности использования расширений файлов для определения типа содержимого.
>а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой. Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере». Или «показать в папке с большим количеством документов только документы Word»
>Сколько Вы выиграете своей регуляркой по имени файла
Выделение подстроки, находящейся после последней точки можно назвать регуляркой лишь с большой натяжкой. Более того, эта операция имеет сложность, не зависящую от количества типов файлов, которые мы умеем различать.
>Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
>а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой. Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере». Или «показать в папке с большим количеством документов только документы Word»
>Сколько Вы выиграете своей регуляркой по имени файла
Выделение подстроки, находящейся после последней точки можно назвать регуляркой лишь с большой натяжкой. Более того, эта операция имеет сложность, не зависящую от количества типов файлов, которые мы умеем различать.
>Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
>Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой.
«Да что там COM… нет даже (стандартного) способа связать тип файла с соответствующим приложением. Есть несколько различных простеньких реализаций, но стандартного способа нет.» (15 декабря, 18:59)
«Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.» (16 декабря 17:55)
Скажите, для чего нужен «способ связать тип файла с приложением», как не для того, чтобы открыть его этим приложением?
>Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере».
И каким боком тут связь файла с приложением? Ну зашли, ну показали. Какая разница, с каким приложением у меня связан тот или иной тип файла (и связан ли вообще)?
>Или «показать в папке с большим количеством документов только документы Word»
«Только документы с расширением doc/docx», Вы хотели сказать? Это не то же самое, что и «только документы Word», как Вы сами понимаете. Так вот, открою страшную тайну: в Linux тоже можно оперировать масками файлов и точно так же показать только doc/docx :)
>Выделение подстроки, находящейся после последней точки можно назвать регуляркой лишь с большой натяжкой. Более того, эта операция имеет сложность, не зависящую от количества типов файлов, которые мы умеем различать.
Выделение подстроки — не зависит от количества, но Вы опять «забываете», что это не отдельная задача «выделить подстроку», а находится она в контексте «определить приложение, ассоциированное с данным расширением», для чего Вам придётся сделать что? Правильно: прошерстить хэш-таблицу. Зависит ли скорость данной операции от количества типов файлов — решите сами.
Хотя Вы опять можете сказать «я же не сказал, что контекст именно такой» %)
>В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
Я беру тот контекст, который Вы сами задали (дважды): «связать тип файла с программой». Для какой цели это может понадобиться — у меня вариантов как-то немного.
«Да что там COM… нет даже (стандартного) способа связать тип файла с соответствующим приложением. Есть несколько различных простеньких реализаций, но стандартного способа нет.» (15 декабря, 18:59)
«Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.» (16 декабря 17:55)
Скажите, для чего нужен «способ связать тип файла с приложением», как не для того, чтобы открыть его этим приложением?
>Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере».
И каким боком тут связь файла с приложением? Ну зашли, ну показали. Какая разница, с каким приложением у меня связан тот или иной тип файла (и связан ли вообще)?
>Или «показать в папке с большим количеством документов только документы Word»
«Только документы с расширением doc/docx», Вы хотели сказать? Это не то же самое, что и «только документы Word», как Вы сами понимаете. Так вот, открою страшную тайну: в Linux тоже можно оперировать масками файлов и точно так же показать только doc/docx :)
>Выделение подстроки, находящейся после последней точки можно назвать регуляркой лишь с большой натяжкой. Более того, эта операция имеет сложность, не зависящую от количества типов файлов, которые мы умеем различать.
Выделение подстроки — не зависит от количества, но Вы опять «забываете», что это не отдельная задача «выделить подстроку», а находится она в контексте «определить приложение, ассоциированное с данным расширением», для чего Вам придётся сделать что? Правильно: прошерстить хэш-таблицу. Зависит ли скорость данной операции от количества типов файлов — решите сами.
Хотя Вы опять можете сказать «я же не сказал, что контекст именно такой» %)
>В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
Я беру тот контекст, который Вы сами задали (дважды): «связать тип файла с программой». Для какой цели это может понадобиться — у меня вариантов как-то немного.
Определять тип файла только по расширению — вообще-то дурная идея.
Вы скажете мне, какой программой создан файл .dat? Это video-cd, или что?
Другой пример: .far (треккерная музыка или служебный файлик far manager).
Или распространённые общие имена: в .bin может быть что угодно — что ж теперь, не определять, что именно там?
И напоследок: ваша винда всё равно читает содержимое файлов. Хотя бы для того, чтобы выдрать/построить иконки, или вытянуть теги mp3, указать автора документа офиса, и т. п… К тому же, если их не читает оболочка, их до оболочки прочитает антивирус.
Вы скажете мне, какой программой создан файл .dat? Это video-cd, или что?
Другой пример: .far (треккерная музыка или служебный файлик far manager).
Или распространённые общие имена: в .bin может быть что угодно — что ж теперь, не определять, что именно там?
И напоследок: ваша винда всё равно читает содержимое файлов. Хотя бы для того, чтобы выдрать/построить иконки, или вытянуть теги mp3, указать автора документа офиса, и т. п… К тому же, если их не читает оболочка, их до оболочки прочитает антивирус.
Какой-то плохонький способ…
$ file --mime SVG.svg
SVG.svg: text/xml
Но главное — не в этом. Думаю, Вы понимаете, что я имел в виду стандартно расширяемое решение. То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.
можно, конечно смело делать >>magic, но ясно, что это решение плохое.
$ file --mime SVG.svg
SVG.svg: text/xml
Но главное — не в этом. Думаю, Вы понимаете, что я имел в виду стандартно расширяемое решение. То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.
можно, конечно смело делать >>magic, но ясно, что это решение плохое.
>То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.
Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается… Шмяк!
Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается… Шмяк!
Так что там с 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.» Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
>Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается
Вы, кажется, всё никак не поймёте, что я прошу.
Но с каждым разом всё ближе, так что надежда на понимание есть.
Итак, чем меня не устраивают 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.» Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
Так что там с SVG? Файл есть, поддержка есть, типа нет… грустно как-то
file SVG.file
SVG.file: SVG Scalable Vector Graphics image
>Вы, кажется, всё никак не поймёте, что я прошу.
Так Вы каждый раз разное просите. То связать тип файла с приложением, то зачем-то «зайти в сетевой каталог и показать 1000 файлов».
>Итак, чем меня не устраивают Desktop Entry файлы? Я просил, повторяю, «стандартный (чтобы всеми признавался и везде работал) способ».
Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org. А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
>Desktop Entry поддерживается на уровне DE.
А Вам на уровне ядра надо, что ли?
>Соответственно, не все DE поддерживают это.
И? Хотите я Вам напишу оболочку для Windows, которая не будет поддерживать виндовый стандартный механизм связывания типов файлов с приложениями — что это докажет по Вашей логике?
>Опять же такую схему поддерживают не все терминалы.
Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
>Если бы они ещё выкинули на помойку формат файлов в INI стиле...
И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
>Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
А именно затем, недогадливый Вы наш, что в задаче «быстро распарсить несколько сотен .desktop-файлов» та самая операция «открыть файл — определить содержимое — закрыть [ненужный] файл» как раз может оказаться боттл-неком, т.к. никакой сторонней программы в данном случае не запускается, и обработка происходит тут же. Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
Очень странно объяснять подобную элементарщину столь яростному поборнику эффективности.
Так Вы каждый раз разное просите. То связать тип файла с приложением, то зачем-то «зайти в сетевой каталог и показать 1000 файлов».
>Итак, чем меня не устраивают Desktop Entry файлы? Я просил, повторяю, «стандартный (чтобы всеми признавался и везде работал) способ».
Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org. А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
>Desktop Entry поддерживается на уровне DE.
А Вам на уровне ядра надо, что ли?
>Соответственно, не все DE поддерживают это.
И? Хотите я Вам напишу оболочку для Windows, которая не будет поддерживать виндовый стандартный механизм связывания типов файлов с приложениями — что это докажет по Вашей логике?
>Опять же такую схему поддерживают не все терминалы.
Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
>Если бы они ещё выкинули на помойку формат файлов в INI стиле...
И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
>Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
А именно затем, недогадливый Вы наш, что в задаче «быстро распарсить несколько сотен .desktop-файлов» та самая операция «открыть файл — определить содержимое — закрыть [ненужный] файл» как раз может оказаться боттл-неком, т.к. никакой сторонней программы в данном случае не запускается, и обработка происходит тут же. Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
Очень странно объяснять подобную элементарщину столь яростному поборнику эффективности.
>Так Вы каждый раз разное просите. То связать тип файла с приложением, то зачем-то «зайти в сетевой каталог и показать 1000 файлов».
Не, я прошу то же самое, что и в начале — «связать тип файла с приложением». Но я не говорил для чего именно. Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.
>Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org.
Я понимаю, что он, видимо наиболее стандартный способ. Но есть разница между словами «наиболее хороший» и «хороший». Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
>А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы. Хотя хотелось бы, конечно, чтобы Desktop Entry файлы поддерживались обычными шеллами типа bash и POSIX шеллами типа ksh.
>Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
Например, он мог бы запускать установленную в данной системе по умолчанию программу обработки данного типа файла при выполнении команды ./file. (как альтернативу используемой сейчас схеме запуска скриптов через hashbang)
>И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас). Это должен быть один их открытых мировых стандартных форматов. XML для этого вполне подойдёт. Быстро-распарсиваемых? Это не нужно. Распарсить достаточно один раз. Важен только быстрый доступ.
>Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач? Думаю, не будет ошибкой, если я скажу, что этот класс задач больше, чем задачи, для которых обязательно нужно лезть внутрь файла. Если Вы наконец поняли, что расширения тоже важны для определения типа файла, то, я думаю, дискуссию по этому вопросу можно закончить.
Не, я прошу то же самое, что и в начале — «связать тип файла с приложением». Но я не говорил для чего именно. Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.
>Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org.
Я понимаю, что он, видимо наиболее стандартный способ. Но есть разница между словами «наиболее хороший» и «хороший». Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
>А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы. Хотя хотелось бы, конечно, чтобы Desktop Entry файлы поддерживались обычными шеллами типа bash и POSIX шеллами типа ksh.
>Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
Например, он мог бы запускать установленную в данной системе по умолчанию программу обработки данного типа файла при выполнении команды ./file. (как альтернативу используемой сейчас схеме запуска скриптов через hashbang)
>И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас). Это должен быть один их открытых мировых стандартных форматов. XML для этого вполне подойдёт. Быстро-распарсиваемых? Это не нужно. Распарсить достаточно один раз. Важен только быстрый доступ.
>Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач? Думаю, не будет ошибкой, если я скажу, что этот класс задач больше, чем задачи, для которых обязательно нужно лезть внутрь файла. Если Вы наконец поняли, что расширения тоже важны для определения типа файла, то, я думаю, дискуссию по этому вопросу можно закончить.
>Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.
Я Вас, возможно, несколько удивлю, но показ иконок и связь типа файла с приложением — слегка ортогональные вещи. Они могут быть связаны (как в Винде), но вовсе не обязательно. И если они не связаны, то в ситуации, когда тип файла известен системе, но соответствующее приложение не установлено, всё равно будет показана нормальная иконка. Парадокс, да?
А уж для фильтрации по расширению связь с приложением и вовсе не нужна. Так что контекст пока что остаётся один. Думайте ещё.
>Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
Да, я понимаю, что Вы пытаетесь витать вокруг да около. Конкретные претензии — в студию. Без обтекаемых «теоретически может быть недостаточно хорош».
>Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы.
Какой «проблемы»? Что существуют некоторые DE, разработчики которых решили положить болт на стандарт? Извините, но это проблемы исключительно тех индивидов, которые сами выбрали себе такое ДЕ, но никак не проблема остальных юзеров и уж тем более не проблема линукса в целом (и механизма desktop-файлов). Я Вам ещё раз говорю: если я напишу оболочку для винды, которая не будет поддерживать стандартный виндовый механизм связи файлов с программами — у винды тоже моментально появится «проблема», наличие которой Вы будете «констатировать»?
Ни в одном вменяемом дистрибутиве по дефолту не поставляется ДЕ, не поддерживающее данный механизм. А уж если кто сознательно ищет приключений на свою пятую точку — то это их проблемы, повторяю, а не линукса.
>Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас).
Нет, не соглашусь. Для такой вещи этот формат оптимален. Специфицирован он прекрасно, гибок он ровно настолько, насколько нужно, а «плохорасширяемый» и «с ворохом вендор-проприетарных расширений» — это вообще взаимоисключающие абзацы.
>Это должен быть один их открытых мировых стандартных форматов.
Кому должен и с какой стати? Аргументы в студию.
>XML для этого вполне подойдёт.
Верите-нет, но я был уверен, что услышу именно эти 3 буквы. Так что Вы там про «эффективные алгоритмы» говорили? Как это стыкуется с Вашим стремлением притащить XML со всем его оверхедом туда, где INI — выше крыши?
>Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач?
Мдя, и перед кем я тут распинался… =\
Повторяю ещё раз: эта оптимизация важна лишь там, где она имеет смысл. При парсинге desktop-файлов — имеет, т.к. даёт значительную экономию, позволяя отсеивать файлы по названию, а не распарсив содержимое и обнаружив, что файл «не тот», а вот при ассоциации файлов с приложениями — не имеет никакого смысла, т.к. открыть файл/прочитать несколько байт из начала/закрыть файл занимает порядка 0.01 секунды (если файл ещё не кэширован), что напрочь теряется на фоне времени запуска ассоциированной программы. Напишите Вы уже простейший тест — там едва два десятка строк наберётся.
Всё, не знаю, как у Вас — а у меня пятница, окончание рабочего дня, а свободное время я предпочитаю проводить с семьёй, а не разжёвывая прописные истины каждому встречному-поперечному.
Удачи!
Я Вас, возможно, несколько удивлю, но показ иконок и связь типа файла с приложением — слегка ортогональные вещи. Они могут быть связаны (как в Винде), но вовсе не обязательно. И если они не связаны, то в ситуации, когда тип файла известен системе, но соответствующее приложение не установлено, всё равно будет показана нормальная иконка. Парадокс, да?
А уж для фильтрации по расширению связь с приложением и вовсе не нужна. Так что контекст пока что остаётся один. Думайте ещё.
>Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
Да, я понимаю, что Вы пытаетесь витать вокруг да около. Конкретные претензии — в студию. Без обтекаемых «теоретически может быть недостаточно хорош».
>Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы.
Какой «проблемы»? Что существуют некоторые DE, разработчики которых решили положить болт на стандарт? Извините, но это проблемы исключительно тех индивидов, которые сами выбрали себе такое ДЕ, но никак не проблема остальных юзеров и уж тем более не проблема линукса в целом (и механизма desktop-файлов). Я Вам ещё раз говорю: если я напишу оболочку для винды, которая не будет поддерживать стандартный виндовый механизм связи файлов с программами — у винды тоже моментально появится «проблема», наличие которой Вы будете «констатировать»?
Ни в одном вменяемом дистрибутиве по дефолту не поставляется ДЕ, не поддерживающее данный механизм. А уж если кто сознательно ищет приключений на свою пятую точку — то это их проблемы, повторяю, а не линукса.
>Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас).
Нет, не соглашусь. Для такой вещи этот формат оптимален. Специфицирован он прекрасно, гибок он ровно настолько, насколько нужно, а «плохорасширяемый» и «с ворохом вендор-проприетарных расширений» — это вообще взаимоисключающие абзацы.
>Это должен быть один их открытых мировых стандартных форматов.
Кому должен и с какой стати? Аргументы в студию.
>XML для этого вполне подойдёт.
Верите-нет, но я был уверен, что услышу именно эти 3 буквы. Так что Вы там про «эффективные алгоритмы» говорили? Как это стыкуется с Вашим стремлением притащить XML со всем его оверхедом туда, где INI — выше крыши?
>Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач?
Мдя, и перед кем я тут распинался… =\
Повторяю ещё раз: эта оптимизация важна лишь там, где она имеет смысл. При парсинге desktop-файлов — имеет, т.к. даёт значительную экономию, позволяя отсеивать файлы по названию, а не распарсив содержимое и обнаружив, что файл «не тот», а вот при ассоциации файлов с приложениями — не имеет никакого смысла, т.к. открыть файл/прочитать несколько байт из начала/закрыть файл занимает порядка 0.01 секунды (если файл ещё не кэширован), что напрочь теряется на фоне времени запуска ассоциированной программы. Напишите Вы уже простейший тест — там едва два десятка строк наберётся.
Всё, не знаю, как у Вас — а у меня пятница, окончание рабочего дня, а свободное время я предпочитаю проводить с семьёй, а не разжёвывая прописные истины каждому встречному-поперечному.
Удачи!
> Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…
В огороде бузина, в Киеве дядька, а у тебя в башке — каша.
Каким образом ты собрался использовать абстрактный вычислитель для реализации компонентов? Какое отношение математическая абстракция вычислительного процесса имеет к реализации программ на конкретной ОС? Какими грибами ты питаешься?
Дуй-ка ты свой стоплинукс.сру к таким же невеждам и идиотам. Не о чем с тобой спорить.
В огороде бузина, в Киеве дядька, а у тебя в башке — каша.
Каким образом ты собрался использовать абстрактный вычислитель для реализации компонентов? Какое отношение математическая абстракция вычислительного процесса имеет к реализации программ на конкретной ОС? Какими грибами ты питаешься?
Дуй-ка ты свой стоплинукс.сру к таким же невеждам и идиотам. Не о чем с тобой спорить.
Если Вы не поняли мою мысль, поясню:
говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.
А вот сравнивать именованные каналы с библиотеками (в частности COM) — вот это воистину «В огороде бузина, в Киеве дядька». Никакой связи нету. Или вы решили учить сишников, что правильно общаться с библиотеками через UDS, а не вызовы экспортированных функций? Не забудьте потом запостить отчёт на хабр.
говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.
А вот сравнивать именованные каналы с библиотеками (в частности COM) — вот это воистину «В огороде бузина, в Киеве дядька». Никакой связи нету. Или вы решили учить сишников, что правильно общаться с библиотеками через UDS, а не вызовы экспортированных функций? Не забудьте потом запостить отчёт на хабр.
> Если Вы не поняли мою мысль, поясню:
Да тебя вообще очень тяжело понять.
> говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.
Какой отношение машина Тьюринга имеет к языкам программирования?
Какое отношение машина Тьюринга и языки программирования имеют к unix domain sockets?
> А вот сравнивать именованные каналы с библиотеками (в частности COM)
Не ври, я такого не говорил, это твои фантазии. Я говорил о том, что грамотно используя юниксовые сокеты можно спокойно обойтись без аналогов COM, и результат получится проще и масштабируемее. Компоненты можно без усилий разнести по разным машинам, можно дописать планировщик и получить load balancing.
Да тебя вообще очень тяжело понять.
> говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.
Какой отношение машина Тьюринга имеет к языкам программирования?
Какое отношение машина Тьюринга и языки программирования имеют к unix domain sockets?
> А вот сравнивать именованные каналы с библиотеками (в частности COM)
Не ври, я такого не говорил, это твои фантазии. Я говорил о том, что грамотно используя юниксовые сокеты можно спокойно обойтись без аналогов COM, и результат получится проще и масштабируемее. Компоненты можно без усилий разнести по разным машинам, можно дописать планировщик и получить load balancing.
По образцу COM написана инфраструктура Firefox (XPCOM), а также инфраструктура OOO. Особого распространения ни то, ни другое не получило.
Да, формат ELF — межплатформенный, причем исходно разрабатывался таким.
Это, разумеется, проблемы индейцев.
А интересно, в Wine то OLE32.dll должено быть. Оно как бы достаточно стандратное. Мож таки єто АПИ существует не тока на одной платформе?
Обычно задача автоматической .doc файлов возникает на платформах, крайней далеких от Windows API и OLE.
Схема-то одна, но есть некоторая разница в нюансировке. Как например, между brainfuck и С, хотя и то, и другое — языки программирования.
Эх, автор. Была бы статья не на Хабре — ты бы стал автором новой пропаганды, мессией, который нашел новый способ удара по виндузятникам.
А так, разбирать старющий формат .doc, сравнивать его с относительно молодыми — толсто.
А так, разбирать старющий формат .doc, сравнивать его с относительно молодыми — толсто.
Ну что же вы так ругаете Микрософт? Вы должны понимать, что львиная часть кода (а это тысячи и тысячи часов разработки) нужна для обеспечения обратной совместимости, к которой MS всегда очень трепетно относится. И выбрасывать последние 20 лет разработки тоже никто не станет только ради того, чтобы кому-то было более удобно пользоваться форматом. Legacy такой legacy.
Вроде как для обратной совместимости нужет просто идентификатор версии файла. Старые версии то новые форматы не поддерживают, а в новых предусмотреть для старых версий отдельные обработчики.
Правда в таком случае сторонним разработчикам совсем бы солоно пришлось, наверное=)
Правда в таком случае сторонним разработчикам совсем бы солоно пришлось, наверное=)
Пример, Lotus 1-2-3, самый популярный табличный процессор своего времени. Формат менялся 4 раза, что никак не повредило его популярности.
Из-за постоянных попыток автора съязвить и неудачно с умничать статью было просто противно читать. Видимо, сам по своей же ссылке на статью от Спольски про причины тех или иных решений MS Office он так и не сходил.
А что мешало просто сервак на винде поставить? Или виртуальную машину?..
А вот вопрос — почему до сих есть проблемы с открытием вордовых документов в опенофисе/гугльдоках? Нет полноценного конвертора или спецификации неполные?
Достаточно сложный формат, при чем что старый, что новый xml. У опенофиса небольшая команда, скорее всего просто не успевают. Под новый мсный формат новелловцы сделали неплохое расширения для ОО, но тоже не без проблем.
Еще один занудский вопрос — так все-таки спецификации неполные, или у разработчиков руки не доходят?
Это я к тому, что у гугля-то должно хватить и бабла и программистов допилить полноценный конвертор. А оно все равно как-то не очень работает…
Это я к тому, что у гугля-то должно хватить и бабла и программистов допилить полноценный конвертор. А оно все равно как-то не очень работает…
Руки не доходят :) На новый формат документация более 6000страниц.
ЗЫЖ думаю у гугли на доксах людей работает меньше, чем у мс на офисе.
ЗЫЖ думаю у гугли на доксах людей работает меньше, чем у мс на офисе.
Это Вы про Open Office форматы? Да, с этим проблема… там, где у OOXML десяток страниц описания формата формул, в спецификации ODF написано «а в этом теге пишем формулу».
Формулы из OpenOffice.org Calc не совместимы с KSpread? Невелика беда. Зато спецификация компактная.
Формулы из OpenOffice.org Calc не совместимы с KSpread? Невелика беда. Зато спецификация компактная.
То-есть существует в природе полноценный конвертер doc?
Причина похожа не ситуацию с браузерами. Как бы они не развивались, все-равно есть ошибки даже на страницах, сверстанных согласно спецификации. Кстати, в офисе по Mac изредка встречаются проблемы с отображением некоторых элементов.
Особенно несовпадения размера шрифтов раздражает
Потому что приходится не только разбирать формат, но и имитировать все глюки Ворда, накопившиеся за 20 лет. Об этом есть у Спольски.
вообще, к работе предков принято относится с уважением
эволюция автомобилей тоже не с порше 911 начиналась
эволюция автомобилей тоже не с порше 911 начиналась
Попробуй теперь распарсить .xls там ещё 2 уровня инкапсуляции. =)
На всякий случай чтобы автор больше не потерял еще неделю жизни на задачу которая решается за 20 минут search.cpan.org/search?query=excel+binary&mode=all
У меня сложилось впечатление, что автор а) мягко говоря не очень компетентен в вопросе и б) статью Спольски, которую сам же и привёл (зачем, интересно?) не читал или не понял, ибо она объясняет абсолютно все вопросы и недоумения автора по поводу этого формата.
Очень радостно, что тут приведено много занятного (но не нового для сталкивающихся) про ole storage, но тем не менее свои цели формат отлично выполнял, кроме того не надо забывать, что он был разработан тогда, когда «клёвых и современных» форматов не было даже в проекте. У него есть свои плюсы (в данный момент многие из них менее актуальны). Есть и минусы, конечно. Основной минус, который и разобран в статье («сложность» формата) вытекает из его бинарности и необязательности на тот момент в какой-либо переносимости и прочего такого. Да, фактически этот формат похож на сериализованные бинарные структуры (а кто более-менее глубоко программировал на расчудесном MFC догадываются даже почему), но… и что из этого, статья то о чём? Технической инфы мало, на сравнение тоже не тянет. Так, посмеяться что ли просто? :)
Очень радостно, что тут приведено много занятного (но не нового для сталкивающихся) про ole storage, но тем не менее свои цели формат отлично выполнял, кроме того не надо забывать, что он был разработан тогда, когда «клёвых и современных» форматов не было даже в проекте. У него есть свои плюсы (в данный момент многие из них менее актуальны). Есть и минусы, конечно. Основной минус, который и разобран в статье («сложность» формата) вытекает из его бинарности и необязательности на тот момент в какой-либо переносимости и прочего такого. Да, фактически этот формат похож на сериализованные бинарные структуры (а кто более-менее глубоко программировал на расчудесном MFC догадываются даже почему), но… и что из этого, статья то о чём? Технической инфы мало, на сравнение тоже не тянет. Так, посмеяться что ли просто? :)
Очень хорошо понимаю автора и поддерживаю отношению к формату. За эту вводную статью, также, большое спасибо.
Тезис критиков о том что формат старый, считаю несостоятельным: раньше как раз тяготели к эффективным бинарным форматам, которые читаются за один проход и, чаще всего, «ложатся» в обычный с-шный struct. С точки зрения быстродействия это наиболее оптимально. Считаю, что имею право рассуждать об этом, так как в течение более 10 лет разрабатываю форматы и протоколы обмена в областях, где важна эффективность и устойчивость к сбоям (соответственно, компьютерные игры, а также промышленная автоматика).
На мой взгляд (я не претендую на Истину), основной задачей при создании формата было внедрение неочевидной схемы, которую очень трудно воспроизвести в сторонних приложениях. Т.е. задача создать сложнейший формат, который бы сохранил эксклюзивную возможность работы с файлами только в «фирменных» приложениях, была выполнена «на отлично».
Тезис критиков о том что формат старый, считаю несостоятельным: раньше как раз тяготели к эффективным бинарным форматам, которые читаются за один проход и, чаще всего, «ложатся» в обычный с-шный struct. С точки зрения быстродействия это наиболее оптимально. Считаю, что имею право рассуждать об этом, так как в течение более 10 лет разрабатываю форматы и протоколы обмена в областях, где важна эффективность и устойчивость к сбоям (соответственно, компьютерные игры, а также промышленная автоматика).
На мой взгляд (я не претендую на Истину), основной задачей при создании формата было внедрение неочевидной схемы, которую очень трудно воспроизвести в сторонних приложениях. Т.е. задача создать сложнейший формат, который бы сохранил эксклюзивную возможность работы с файлами только в «фирменных» приложениях, была выполнена «на отлично».
Кстати, с тезисом об оптимизации для инкрементальных сохранений, также не согласен: всё то же самое можно было сделать, внедряя более простые схемы. Тем более что в реальных ситуациях, в старых версиях программ, где реальная сложность документов была ниже, подобная реализация была избыточной в квадрате. Даже если предположить, что реализация своего ФАТа была необходима, можно было реализовать гораздо проще. В ситуациях, когда приходилось делать свою мини-файловую систему для хранения разнородных данных в ЕЕПРОМ контроллера, моя реализация была на порядки менее монструозной. А этот, извините, Франкенштейн, вызывает единственную мысль: любой ценой необходимо было сохранить уникальность продукта на рынке. Как показала практика, с этой задачей формат справился.
Кстати, я бы не хотел вешать ярлыки «зла» или «добра». Корпорация имела законное право создать тот формат, который пожелает (создание сложных форматов не преследуется по закону). Также, корпорация имеет право исходить из тех оснований, которые считает нужными. Мало того, Микрософт оказалась достаточно сильной, чтобы отстаивать свои позиции в течение десятилетий. Это, конечно, очень достойный результат.
«Зачем делать просто, если можно сложно и запутанно?»
А чтобы в «опенофисах» не открывалось.
А чтобы в «опенофисах» не открывалось.
В смысле, чтобы документы, созданные в RSpread не открывались в OpenOffice.org Calc? Ну да… похоже для этого «опенофисы» и были придуманы…
Именно. Чем сложнее, кривее и запутаннее формат, тем сложнее создать конкурирующее приложение для работы с форматом, являющимся мировым стандартом де-факто.
Да не было никаких опенофисов, когда это разрабатывалось! Не стоит искать злой умысел там, где можно объяснить простым быдлокодом.
Когда мне нужно было работать с офисом, я использовал Apache POI. Радуют названия отдельных пакетов: HSSF (Horrible SpreadSheet Format), HWPF (Horrible Word Processor Format), POIFS (Poor Obfuscation Implementation File System), etc.
Аа, да, увидел.
Но думаю автору полезно будет еще пару раз перечитать
Но думаю автору полезно будет еще пару раз перечитать
Отличный список маразмов.
А вот это в мемориаз:
«То же самое, но хостинг на Linux. Купи сервер на Windows 2003, установи на него лицензионный Word и настрой веб-службу, которая будет делать всё это. Полдня работы на C# и ASP.NET.»
Теперь, когда меня спросят сложно ли настроить хостинг, я буду отвечать: «Легко! Сначала купите сервер на Windows....»
А вот это в мемориаз:
«То же самое, но хостинг на Linux. Купи сервер на Windows 2003, установи на него лицензионный Word и настрой веб-службу, которая будет делать всё это. Полдня работы на C# и ASP.NET.»
Теперь, когда меня спросят сложно ли настроить хостинг, я буду отвечать: «Легко! Сначала купите сервер на Windows....»
Всё верно. А желающие заняться ручным разбором под линухами сами выбрали свой путь
Ну, вот так Спольский жжёт. Снова сунулся в оригинал — ничего сверхъестественного, всё именно так.
То же самое, но хостинг на Linux. Купи сервер на Windows 2003…
Теперь, когда меня спросят сложно ли настроить хостинг, я буду отвечать: «Легко! Сначала купите сервер на Windows....»
вы не поверите, но очень часто «купи» это самый дешевый путь. к сожалению многие вещи не доступны бесплатно и их приходится покупать, к еще большему сожалению, некоторые нужные вещи купить не у кого (в виду малой востребованности никто их не «производит») и приходится делать самому. и довольно часто это обходится дороже чем купить :/
навскидку, необходимый для работы комплект можно уложить в килобакс с небольшим (возможно некоторые особенности лиценизирования которые я не учел и удорожат набор, но не думаю что очень сильно). сколько нужно будет заплатить девелоперу за разработку? сколько он убьет времени на написание? а на отладку? неделю? две!? месяц?! больше?!!? а сколько, сколько он стОит?
У меня в комментарии пропущено одно слово, я думал, что тем кто прочитал Спольского будет понятно и не стал поправляться.
Ещё раз Спольский в вольном пересказе:
— Как это сделать на linux?
— Очень просто! Берём windows и делаем на нём.
Из всей статьи, я согласен только с одним доводом в защиту сложности формата файлов офиса, остальные притянуты за уши.
Ещё раз Спольский в вольном пересказе:
— Как это сделать на linux?
— Очень просто! Берём windows и делаем на нём.
Из всей статьи, я согласен только с одним доводом в защиту сложности формата файлов офиса, остальные притянуты за уши.
Это мой перевод :)
Ирония судьбы: впоследствии мне приходилось читать… нет, не Word, правда, а Excel.
Ирония судьбы: впоследствии мне приходилось читать… нет, не Word, правда, а Excel.
3. Загрузить табличку МиниФАТ, собрав ее по цепочке ТРФ
4. Загрузить хранилище блочков, собрав ее по цепочке ТРФ
5. Загрузить корневой каталог, собрав ее по цепочке ТРФ
Статью на перле генерили?
4. Загрузить хранилище блочков, собрав ее по цепочке ТРФ
5. Загрузить корневой каталог, собрав ее по цепочке ТРФ
Статью на перле генерили?
Я так и не понял: аффтар занимался самообразованием или у него не хватило проницательности найти antiword, который делает в точности что нужно: выдирает текст из doc-файлов?
Заголовок следующай статьи: «Внтуренности TAR файлов: просто ужас», и сравнивать в этой статье TAR будет с JSON. Хз, почему, но так что бы из традиции не выбиваться.
Судя по этому комментарию в коде, PSD по внутреннему устройству тоже «хорош».
В нашем проекте тоже был необходим парсинг (полный, а не только выдерание текста) doc-а. Почитав\подумав решили не браться за этот кошмар. Используем b2xtranslator.sourceforge.net/ (.NET библиотека) вот эту либу. Багов хватает, но в целом ничего лучше не нашли. Может пригодится кому…
Анекдот вспомнили не тот. Вот правильный:
Хочешь увеличить член в 10 тысяч раз? Напиши в блокноте, сохрани в ворде.
Хочешь увеличить член в 10 тысяч раз? Напиши в блокноте, сохрани в ворде.
Мне страшно теперь думать о внутренностях powerpointa или excel…
powerpoint
Предполагаю, что пресловутый OLE Storage — одно из наследий Cairo — объектно-ориентированной ОС на основе OLE, разрабатывавшейся в Microsoft, но выпиленной маркетологами в пользу Windows 2000. Отсюда и таблица файлов, и прочие признаки файловой системы. В Cairo этот OLE Storage наверняка планировался как замена обычным ФС.
Хранение списка файлов не линейным списком, а двоичным деревом похоже скорее на NTFS, нежели на FAT. Некоторые возможности NTFS, думается, тоже вобрали в себя наработки Cairo, но какие конкретно, затрудняюсь сказать.
Хранение списка файлов не линейным списком, а двоичным деревом похоже скорее на NTFS, нежели на FAT. Некоторые возможности NTFS, думается, тоже вобрали в себя наработки Cairo, но какие конкретно, затрудняюсь сказать.
Microsoft похоже самостоятельно делает всё возможное для роста популярности OpenOffice
И утилит типа Antiword.
Аналитики отмечают резкий рост популярности решений OpenOffice (включая StarOffice, IBM Lotus Symphony). Доля этого ПО на рынке составляет 21,5% (данные 2010 года еще)
И утилит типа Antiword.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внутренности вордовских файлов: просто ужас