|
Страница 8 из 8
Заключение | | В этой статье для меня все ясно, за исключением упоминаний о сепульках, трансме и хмепе. Увы, последний вышедший в свет том энциклопедии кончался статьей "Соус грибной", значит, ни о трансме, ни о хмепе ничего нет. С. Лем. Звездные дневники Ийона Тихого. Путешествие четырандцатое. | Конечно, в статье рассмотрено далеко не все, что хотелось бы. И не всему вышенаписанному стоит беспрекословно доверять: например, весьма вероятно, что в случае огромных DOC-файлов структурированное хранилище может быть образовано из "секторов" с размерами большими, чем 512 байтов. Но теперь любознательный читатель может не только проверить информацию, но и продолжить собственные иследования двоичного формата документов WinWord. Кому-то может показаться излишним приведенное выше подробное описание формата структурированных хранилищ. Но мне, например, оно сильно пригодилась, когда необходимо было вытаскивать текст из DOC-файлов, записанных на поцарапанную дискету. Функции OLE2 API в этой ситуации просто отказывались работать. Кроме того, знание подробностей организации этого формата позволяет существенно ускорить работу с составным файлом: можно, например, напрямую искать в файле заголовочные сигнатуры отдельных компонентов (главного потока, вирусных макросов и т.п.) по смещениям, кратным 512. Возможны и иные применения для информации, приведенной в этой статье. Желаю успехов! Дополнение от зимы 2004 года После обнародования предыдущей версии этой статьи мне пришлось выслушать немало критики за ее неполноту, наличие многочисленых неточностей, и даже за то, что я дерзнул написать ее поперед тех "батьков", кто знает на эту тему гораздо больше, но шибко дорожит своей монополией на информацию. J К счастью, большинство читателей восприняли ту статью благожелательно. А правильней всех поступил С. Новодворский, который очень удачно углубил рассмотренную тему в своей собственной статье "Доступ к MD-файлам при помощи VBA", попутно исправив самые крупные мои неточности и дописав иллюстрирующий софт. Спасибо, Сергей, и так держать! Итак, самая крупная неточность в моей статье касалась формата заголовка структурированного хранилища. Часть полей я тогда намеренно не описал (посчитав не важными), одно поле описал ошибочно, а о назначении некоторых полей в то время лишь смутно догадывался. Теперь я имею возможность привести новый, уточненный формат заголовка структурированного хранилища: struct DOC_FILE_HEADER
{
DWORD Сигнатура; // +00h - "магическое" число E011CFD0h
DWORD КодВерсииOLE; // +04h - "магическое" число E11AB1A2h
DWORD НеИспользуется; // +08h
WORD НеИспользуется; // +0Ch
WORD РазмерСектора; // +0Eh - Log2(512)=9 (new!)
DWORD НеИспользуется; // +10h
DWORD НеИспользуется; // +14h
WORD НомерРевизии; // +18h - ? (new!)
WORD НомерВерсии; // +1Ah - ? (new!)
DWORD НеИспользуется; // +1Ch
DWORD НеИспользуется; // +20h
DWORD НеИспользуется; // +24h
DWORD НеИспользуется; // +28h
DWORD РазмерBBD; // +2Сh - количество секторов в BBD
DWORD НачалоКаталога; // +30h - стартовый сектор каталога
DWORD НеИспользуется; // +34h
DWORD НеИспользуется; // +38h
DWORD НачалоSBD; // +3Сh - стартовый сектор SBD
DWORD ПродолжениеSBD; // +40h - ? (new!)
DWORD ОкончаниеBBD; // +44h - стартовый сектор окончания BBD (new!)
DWORD НеИспользуется; // +48h
DWORD НачалоBBD; // +4Сh - стартовый сектор BBD
DWORD ПродолжениеBBD[108];// +50h - адреса секторов продолжения BBD (new!)
};
| Комментарии. - Знаком "?" помечены поля, в назначении которых я не уверен.
- С адреса 50h начинается массив DWORD-ов, каждый из которых непосредственно адресует очередной сектор FAT больших блоков. Поля по смещениям 40h и 50h дают возможность иметь длинные FAT.
- Говорят, что MS Word, начиная с версии 2000 умеет ЧИТАТЬ документы с секторами длиной >512 (например, 4096), но все равно не умеет их СОЗДАВАТЬ.
- Убедитесь, насколько все у Microsoft запущено! J
Не исключено, что и это еще не конец... |