[Перевод] Zip – как не нужно создавать формат файлов

Zip появился 32 года назад. Можно подумать, что настолько зрелый формат должен быть отлично задокументирован. К сожалению, нет. Что же конкретно в нем не так, и каким образом его можно было бы оптимизировать? Подробно рассмотрим эти вопросы, опираясь на исходную документацию.

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

Соответствующая документация находится в APPNOTE.TXT, который доступен здесь.

Если коротко, то zip-файл состоит из записей, каждая запись начинается с некоторого 4-байтового маркера, который обычно имеет следующую структуру:

0x50, 0x4B, ??, ??

Здесь 0x50 и 0x4B представляют буквы PK, означающие “Phil Katz”, собственно, имя создателя этого формата. Два байта ?? определяют тип записи. Вот примеры:

0x50 0x4b 0x03 0x04   // local file record
0x50 0x4b 0x01 0x02   // central directory file record
0x50 0x4b 0x06 0x06   // end of central directory record

Записи не следуют какому бы то ни было стандартному шаблону. Чтобы считать или даже пропустить запись, необходимо знать ее формат. Я имею ввиду, что есть несколько других форматов файлов, которые следуют определенному соглашению, например, когда каждый id записи сопровождается ее длиной. Поэтому, если вы видите id и не понимаете его, то просто считываете длину, пропускаете такое же количество байтов* и оказываетесь у следующего id. К примерам подобной схемы относится большинство форматов видео-контейнеров, jpg, tiff, файлы Photoshop, wav, да и многие другие.

* некоторые форматы требуют округления длины до ближайшего числа, кратного 4 или 16. Zip же этого не делает. Если вы видите id и не знаете, как этот тип содержимого записи структурирован, то понять, сколько байтов нужно пропустить, вам не удастся.

APPNOTE.TXT сообщает нам следующее:

4.1.9 ZIP-архивы МОГУТ быть потоковыми, разделенными на сегменты (на стационарных или съемных носителях) либо «самораспаковывающимися» (SFX). SFX-архивы ДОЛЖНЫ нести в себе код извлечения для целевой платформы.

4.3.1 ZIP-архив ДОЛЖЕН содержать end of central directory record. ZIP-архив, содержащий только end of central directory record, рассматривается как пустой. Файлы внутри ZIP-архива можно заменять, добавлять и удалять. ZIP-архив ДОЛЖЕН содержать только одну end of central directory record. Другие записи, определенные в этой спецификации, МОЖНО использовать при необходимости для поддержания требований хранилища к отдельным ZIP-архивам.

4.3.2 Каждому помещенному в ZIP-архив файлу ДОЛЖНА предшествовать запись local file header. Каждая запись local file header ДОЛЖНА сопровождаться соответствующей central directory record, расположенной внутри раздела центрального каталога ZIP-архива.

4.3.3 Файлы внутри ZIP-архива можно сохранять в произвольном порядке. ZIP-архив МОЖЕТ включать несколько томов или быть разделен на сегменты определенного пользователем размера. Все значения ДОЛЖНЫ храниться в порядке байтов от младшего к старшему, если для конкретного элемента данных этой документацией не установлено иное.

4.3.6 Общая структура формата .ZIP:

[local file header 1]
[encryption header 1]
[file data 1]
[data descriptor 1]
. 
.
.
[local file header n]
[encryption header n]
[file data n]
[data descriptor n]
[archive decryption header] 
[archive extra data record] 
[central directory header 1]
.
.
.
[central directory header n]
[zip64 end of central directory record]
[zip64 end of central directory locator] 
[end of central directory record]

4.3.7 Local file header:

local file header signature     4 bytes  (0x04034b50)
version needed to extract       2 bytes
general purpose bit flag        2 bytes
compression method              2 bytes
last mod file time              2 bytes
last mod file date              2 bytes
crc-32                          4 bytes
compressed size                 4 bytes
uncompressed size               4 bytes
file name length                2 bytes
extra field length              2 bytes
 
file name (variable size)
extra field (variable size)

4.3.8 File data
Сразу после local header файла ДОЛЖНЫ идти сжатые или сохраненные данные этого файла. Если файл зашифрован, заголовок шифрования ДОЛЖЕН идти между local file header и file data. Последовательность [local file header][encryption header] [file data][data descriptor] повторяется для каждого файла в ZIP-архиве.

Файлы нулевого байта и другие типы файлов без содержимого НЕ ДОЛЖНЫ включать file data.

4.3.12 Структура центрального каталога:

[central directory header 1]
.
.
. 
[central directory header n]
[digital signature] 

File header:

central file header signature   4 bytes  (0x02014b50)
version made by                 2 bytes
version needed to extract       2 bytes
general purpose bit flag        2 bytes
compression method              2 bytes
last mod file time              2 bytes
last mod file date              2 bytes
crc-32                          4 bytes
compressed size                 4 bytes
uncompressed size               4 bytes
file name length                2 bytes
extra field length              2 bytes
file comment length             2 bytes
disk number start               2 bytes
internal file attributes        2 bytes
external file attributes        4 bytes
relative offset of local header 4 bytes

file name (variable size)
extra field (variable size)
file comment (variable size)

4.3.16 End of central directory record:

end of central dir signature    4 bytes  (0x06054b50)
number of this disk             2 bytes
number of the disk with the
start of the central directory  2 bytes
total number of entries in the
central directory on this disk  2 bytes
total number of entries in
the central directory           2 bytes
size of the central directory   4 bytes
offset of start of central
directory with respect to
the starting disk number        4 bytes
.ZIP file comment length        2 bytes
.ZIP file comment       (variable size)

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

Для этого можно вернуться к ZIP2EXE.exe, который сопровождал PKZIP в 1989 году, и посмотреть, что он делает. Однако проще будет заглянуть в Info-ZIP:

Как создать DOS (или другой не-нативный) SFX-архив под Unix?
Суть этой процедуры объяснена на странице мануала UnZipSFX. Сперва понадобится подходящий бинарный дистрибутив UnZip для целевой платформы (DOS, Windows, OS/2 и т.д.). В следующем примере мы предположим, что работаем с DOS. Затем нужно извлечь из дистрибутива модуль UnZipSFX и добавить его, как если бы он был нативным модулем Unix:

> unzip unz552x3.exe unzipsfx.exe                // извлечение SFX-модуля для DOS
> cat unzipsfx.exe yourzip.zip > yourDOSzip.exe  // создание SFX-архива
> zip -A yourDOSzip.exe                          // корректировка внутренних смещений
> 

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

Ну а теперь с учетом всего этого мы пройдемся по ряду проблем.

Как считывать zip-файл?

В спецификации по этому поводу ничего не сказано.

Есть два очевидных пути:

1. Просканировать его с начала и при встрече id записи выполнять нужные действия.
2. Просканировать его с конца. Найти end of central directory record и использовать ее для считывания всего центрального каталога, рассматривая только те элементы, на которые он ссылается.

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

Однако пункт 4.1.9 утверждает, что zip-архивы можно передавать потоком. Как такое возможно? Что, если есть некая local file record, на которую центральный каталог не ссылается? Валидна ли она? Неизвестно.

В 4.3.1 сказано:

Файлы внутри ZIP-архива МОЖНО заменять, добавлять и удалять.

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

Если у меня есть file1.zip, содержащий файлы A, B, C, и я генерирую file2.zip, который содержит только A и B, то получается два независимых zip-файла. Нет никакого смысла писать в спецификации о возможности добавления, замены и удаления файлов, если только эта информация каким-то образом не влияет на структуру zip-файла.

Другими словами, если перед нами такая структура:

[local file A]
[local file B]
[local file C]
[central directory file A]
[central directory file C]
[end of central directory]

Тогда очевидно, что B удален, поскольку центральный каталог на него не ссылается. С другой стороны, если [local file B] отсутствует, тогда мы имеем просто независимый zip-архив, т.е. независимый от другого zip-архива, в котором B содержится. Нет необходимости даже упоминать об этой ситуации в спецификации.

Аналогичным образом, если перед нами:

[local file A (old)]
[local file B]
[local file C]
[local file A (new)]
[central directory file A(new)]
[central directory file B]
[central directory file C]
[end of central directory]

Тогда, согласно центральному каталогу, A (old) был заменен на A (new). С другой стороны, если [local file A (old)] отсутствует, то мы имеем просто еще один независимый zip-архив.

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

Это было особенно актуально в случаях, когда zip-архив занимал несколько дискет. В 1989 году подобная ситуация была не редкостью. Оказывалось гораздо удобнее обновлять README.TXT в zip-архиве без необходимости перезаписывать несколько дискет.

Представители PKWARE в обсуждении сказали следующее:

Изначально этот формат подразумевал прямую запись от начала к концу, поэтому central directory и end of central directory record могли записываться после того, как будут узнаны и записаны все включаемые в ZIP-архив файлы. При добавлении файлов изменения можно применять без перезаписывания всего файла. Именно так была реализована запись файлов .ZIP в оригинальной программе PKZIP. При считывании она сначала читает end of central directory record для обнаружения central directory, а затем ищет все файлы, к которым нужно обратиться.

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

Файлы внутри ZIP-архива МОЖНО заменять, добавлять и удалять.

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

Но это противоречит пункту 4.1.9, в котором говорится, что zip-архивы могут передаваться в потоковом режиме. Если архивы допускают потоковую передачу, тогда оба вышеприведенных примера провалятся, потому что сначала в первом случае мы увидим файл B, а во втором файл A (old), и лишь потом то, что центральный каталог на них не ссылается. Если же нам придется дожидаться чтения центрального каталога прежде, чем верно использовать любые из его записей, тогда функционально мы просто не сможем передавать zip-файл потоком.

Может ли SFX-компонент содержать какие-либо ID?

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

Предположим, что у SFX-компонента следующий код:

switch (id) {
case 0x06054b50:
read_end_of_central_directory();
break;
case 0x04034b50:
read_local_file_record();
break;
case 0x02014b50:
read_center_file_record();
break;
...
}

Судя по этому коду, в SFX-компоненте, представляющем начало zip-файла, в двоичном виде появятся значения 0x06054b50, 0x04034b50, 0x02014b50. Если считывать zip-архив прямым сканированием, то сканер может увидеть эти id и ошибочно принять их за записи zip.

Вот как можно представить SFX-компонент с находящимся в нем zip-файлом:

// данные для zip-файла, содержащие:
//  LICENSE.txt
//  README.txt
//  player.exe
const unsigned char[] runtimeAndLicenseData = {
0x50, 0x4b, 0x03, 0x04, ??, ??, ...
};
 
int main() {
extractZipFromFile(getPathToSelf());
extractZipFromMemory(runtimeAndLicenseData, sizeof(runtimeAndLicenseData));
}

Теперь внутри SFX-компонента находится zip-файл. Любой ридер, который считывает с начала, увидит этот внутренний zip-файл и даст сбой. Валиден ли данный zip-файл? Спецификация об этом молчит.

Я проверил. Оригинальный PKUNZIP.exe в DOS, Windows Explorer, MacOS Finder, Info-ZIP (UNZIP, включенный в MacOS и Linux), все четко считывают с конца и видят эти файлы уже после SFX-компонента. А вот Keka и 7z видят zip, вложенный в него.

Считать ли это сбоем или плохим zip-файлом?

APPNOTE.TXT ответа не дает. Я считаю, что здесь должна быть ясность, и что это является одним из незаявленных допущений. PKUNZIP сканирует с конца, поэтому такая схема работает, но как именно она работает, в документации не сказано. Проблема того, что данные в SFX-компоненте могут оказаться похожи на zip-файл, не освещается. Аналогичным образом, потоковая передача скорее всего провалится, если еще не провалилась из-за недочетов, описанных ранее.

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

Может ли zip-комментарий содержать идентификаторы zip?

Если еще раз взглянуть на пункт 4.3.16, то мы увидим, что в конце zip-архива идет комментарий переменной длины. Поэтому при обратном сканировании мы, по сути, выполняем чтение с конца файла в поиске 0x50 0x4B 0x05 0x06. Но что, если эта последовательность байтов находится в комментарии?

Уверен, что Фил Кац никогда об этом не задумывался. Он просто предположил, что люди будут помещать туда эквивалент README.txt. В таком случае там будут находиться только значения от 0x20 до 0x7F, возможно, с 0x0D (возврат каретки), 0x0A (перевод строки), 0x09 (табуляция) и 0x06 (звонок).

К сожалению, все эти значения в ID являются действительными кодами ASCII, даже utf-8. В начале статьи мы уже прошлись по 0x50 = P и 0x4B = K. Что же касается 0x06 и 0x05, то первый в ASCII означает «звонок» (издает звук или вызывает мигание экрана), а второй «Запрос».

APPNOTE.TXT наверняка должен явно сообщать, если это невалидно. Пункт 4.3.1 косвенно указывает:

ZIP-архив ДОЛЖЕН содержать только одну end of central directory record.

Но что именно это значит? Значит ли это, что байты 0x50 0x4B 0x05 0x06 не могут появиться в комментарии или коде SFX? Значит ли это, что когда вы в первый раз видите их при обратном сканировании, то второе совпадение уже не ищете?

Если вы сканируете с начала и не сталкиваетесь ни с одной из перечисленных ранее проблем, то прямой сканер успешно это считает. С другой стороны, сам PKUNZIP бы не справился.

Что, если смещение до центрального каталога равно 1,347,093,766?

Это смещение 0x504b0506, значит оно окажется заголовком end of central directory. Я думаю, что во времена создания формата zip файлы размером 1.3 Гб даже не предполагались, и, действительно, расширения требовались для обработки файлов больше 4 Гб. Но это лишь еще раз указывает на недостаточную продуманность структуры формата.

А что значит продуманная структура?

Этот вопрос определенно требует обсуждения, но, если рассмотреть возможность повторить разработку, то кое-что можно определить без сомнений.

1. Лучше, если записи будут иметь фиксированный формат, например id, сопровождаемый размером, чтобы можно было пропускать запись в случае непонимания.

2. Лучше, если последняя запись в конце файла будет просто записью offset-to-end-of-central-directory, как здесь:

0x504b0609 (id: some id is not in use)
0x04000000 (size of data of record)
0x???????? (relative offset to end-of-central-directory)

Это исключит двусмысленность при обратном считывании.

2.a. Считать последние 12 байтов.

2.b. Проверить, являются ли первые 8 байтов следующими: 0x50 0x4b 0x06 0x09 0x04 0x00 0x00 0x00. Если нет, сбой.

2.c. Считать смещение и перейти к end-of-central-directory.

Или, напротив, поместить комментарий в собственную запись и расположить перед central directory, указав смещение до него в end-of-central-directory-record.

Тогда, по крайней мере, исчезнет проблема сканирования комментария.

3. Внести ясность в том, какие данные могут появиться в компоненте SFX.
Если вам нужна поддержка прямого считывания, то будет логичным утвердить, что SFX-компонент не может содержать какие-либо записи.

Но обеспечить это сложно, разве что специально написать валидатор. Если вы будете просто проверять, исходя из того, может ли ваше приложение считывать zip-файл, то на сегодня для PKZIP, PKUNZIP, info-ZIP, Windows Explorer и MacOS содержимое SFX-компонента безразлично, поэтому для валидации они не годятся. Нужно явно указать в спецификации на необходимость применения именно обратного сканирования, либо же написать валидатор, который отвергает zip-файлы, не допускающие прямого сканирования, и также в спецификации указать причину.

4. Внести ясность в том, может ли central directory расходиться с записями локальных файлов.

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

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

Необходима ясность в том, нормально это или нет. Не нужно полагаться на скрытые схемы.

Что же делать? Как все исправить?

На мой взгляд все эти проблемы относятся к деталям реализации, которые не попали в APPNOTE.TXT. При этом на самом деле APPNOTE.TXT хочет сказать, что «валидный zip-файл – это тот, с которым может работать PKZIP, и который может правильно распаковать UNZIP”. Но вместо этого он определяет все таким образом, что в результате некоторые реализации могут создавать файлы, которые не могут прочесть другие реализации.

Конечно же, спустя всю 32-летнюю историю zip-файлов, мы уже этот формат не исправим. Но все же в PKWARE могли бы внести ясность по поводу рассмотренных пограничных случаев. Лично я бы добавил соответствующие разделы в APPNOTE.TXT.

4.3.1 ZIP-файл ДОЛЖЕН содержать end of central directory record. ZIP-файл, содержащий только end of central directory record считается пустым. Файлы в ZIP-архиве МОЖНО обновлять, добавлять и удалять. ZIP-файл ДОЛЖЕН содержать только одну end of central directory record. Другие записи, определенные в этой спецификации, МОЖНО использовать по необходимости для поддержания требований хранилища к отдельным ZIP-файлам.

End of central directory record должна находиться в конце файла, и последовательность байтов 0x50 0x4B 0x05 0x06 не должна встречаться в комментарии.

Сentral directory руководит содержимым zip-файла, и считать из него можно только те данные, на которые он указывает. Во-первых, причина в том, что содержимое SFX-компонента файла не определено и может содержать zip-записи, которые фактически к zip-файлу не относятся. Во-вторых, возможность добавлять, обновлять или удалять содержимое zip-файла опирается на доступную лишь central directory информацию о том, какие локальные файлы валидны.

Это один способ. Я верю, что в таком случае удалось бы считать сотни миллионов существующих zip-файлов.

С другой стороны, если в PKWARE заявляют, что файлов, имеющих подобные проблемы, не существует, тогда также сработает следующий вариант:

4.3.1 ZIP-архив ДОЛЖЕН содержать end of central directory record. ZIP-архив, содержащий только end of central directory record, считается пустым. Файлы в ZIP-архиве МОЖНО заменять, добавлять и удалять. Другие записи, определенные в этой спецификации, МОЖНО использовать по необходимости для поддержания требований хранилища к отдельным ZIP-архивам.

End of central directory record должна находиться в конце файла, и последовательность байтов 0x50 0x4B 0x05 0x06 не должна встречаться в комментарии.

Не может быть таких [local file records], которые бы не содержались в central directory. Эта гарантия необходима, чтобы считывание файла в прямом и обратном направлении давало одинаковые результаты. Любой файл, не следующий этому правилу, является недействительным zip-архивом.

SFX-архив не должен содержать любую из последовательностей id записей, перечисленных в этом документе, так как они могут быть неверно поняты zip-сканерами прямого чтения. Любой файл, не следующий этому правилу, является недействительным zip-архивом.

Надеюсь, что файл APPNOTE.TXT все же обновят, чтобы различные zip-ридеры и zip-генераторы трактовали валидность файлов одинаково.

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

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

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

P.S.

Вам может быть весьма интересна эта история ZIP (англ.):

Adblock test (Why?)