Как устроен ZIP-архив: структура формата простыми словами

ZIP-архив — это не «сжатый файл», а контейнер: внутри него лежат один или несколько файлов вместе со служебной информацией о них. Понимание того, как этот контейнер устроен изнутри, объясняет сразу несколько практических вещей: почему архив можно открыть частично даже при повреждении, зачем архиватору секунды на открытие огромного архива, почему один и тот же файл в разных архиваторах сжимается по-разному и что именно теряется, если архив обрезан.

Главный принцип, который стоит запомнить сразу: данные файлов хранятся последовательно, а их описание — в отдельном центральном каталоге в конце архива. Именно эта двухуровневая структура делает формат одновременно быстрым, отказоустойчивым и гибким.

Общая структура: три слоя

Любой корректный ZIP-файл состоит из трёх частей, идущих друг за другом:

• Локальные записи файлов — сами данные каждого файла, перед которыми стоит небольшой служебный заголовок с именем, размерами и контрольной суммой.
• Центральный каталог — список всех файлов архива с полными сведениями о каждом: имя, размеры, метод сжатия, дата, атрибуты и точное смещение, где лежат данные файла.
• Конечная запись каталога (End of Central Directory, EOCD) — короткая завершающая структура, с которой любая программа начинает чтение архива.

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

Локальный заголовок файла

Перед данными каждого файла в архиве стоит локальный заголовок. Он начинается с фиксированной сигнатуры PK\x03\x04 — тех самых байт, по которым программы распознают ZIP-файл даже без расширения. В заголовке записаны:

• версия формата, необходимая для распаковки;
• используемые флаги, например шифрование или кодировка имени;
• метод сжатия (stored, deflate и другие);
• время и дата модификации файла;
• контрольная сумма CRC-32 несжатых данных;
• сжатый и несжатый размер;
• длина имени файла и длина дополнительного поля.

Сразу после заголовка идут имя файла и сами данные. В классическом варианте заголовок содержит реальные размеры, но современные архиваторы часто пишут там нули, а истинные значения переносят в так называемый data descriptor после данных — это позволяет узнать сжатый размер ещё до окончания сжатия, например при потоковой записи архива прямо в сеть.

Центральный каталог

После всех файлов следует центральный каталог — массив записей, по одной на каждый файл. Каждая запись начинается с сигнатуры PK\x01\x02 и повторяет сведения локального заголовка, но добавляет критически важное поле: смещение локального заголовка от начала файла. Именно по этому смещению программа переходит от строки в списке к самим данным.

Каталог хранит больше информации, чем локальные заголовки:

• полные атрибуты файловой системы — права доступа Unix, атрибуты Windows;
• комментарий к каждому файлу;
• внутренние и внешние атрибуты, тип записи (файл или каталог);
• номер диска, если архив разбит на части.

Завершает всё EOCD-запись с сигнатурой PK\x05\x06: в ней указано количество записей, размер каталога и его смещение, а также комментарий архива. Если EOCD отсутствует или повреждён, большинство программ сочтёт весь архив битым — даже когда данные файлов физически целы.

Методы сжатия внутри ZIP

Формат не привязан жёстко к одному алгоритму: в заголовке каждого файла указан номер метода, и программа должна уметь его распаковать. На практике встречаются следующие варианты.

Метод	Что происходит	Когда применяется
Stored (0)	Данные копируются без сжатия	Уже сжатые файлы: JPEG, MP4, PDF, архивы второго уровня
Deflate (8)	Классический алгоритм LZ77 плюс кодирование Хаффмана	Стандартный выбор большинства архиваторов
Deflate64 (9)	Расширенная версия Deflate с большим окном	Редко; нужна поддержка в распаковщике
BZip2 (12)	Блочная сортировка, лучше сжимает текст	Медленнее, но плотнее для текстовых данных
LZMA (14)	Сильное сжатие с большим словарём	Когда важен минимальный размер и есть время
AES-шифрованные записи	Дополнительно к сжатию применяется шифрование WinZip AES	Защищённые архивы; требует поддержки у получателя

Нюанс совместимости: старые распаковщики и некоторые встроенные средства операционных систем понимают только Stored и Deflate. Архив с LZMA может просто не открыться стандартным проводником, хотя сторонний архиватор справится. Если вы отправляете архив незнакомому получателю, безопаснее использовать обычный Deflate.

Почему повторное сжатие почти бесполезно

Алгоритмы вроде Deflate устраняют избыточность: повторяющиеся последовательности заменяются ссылками, частые символы получают короткие коды. Если данные уже сжаты — JPEG-изображение, видеофайл, другой архив — избыточности в них практически нет, и Deflate не найдёт, что сокращать. Более того, из-за накладных расходов на заголовки итоговый ZIP может оказаться чуть больше исходного файла.

Отсюда практическое правило: сжимайте то, что сжимается, — тексты, таблицы CSV, исходный код, базы данных в выгрузках, логи. Медиафайлы кладите методом stored ради удобства упаковки нескольких файлов в один, а не ради экономии места.

Метаданные и их ограничения

Внутри ZIP сохраняются имя файла, дата модификации и базовые атрибуты. Но у формата есть известные слабые места, о которых полезно знать заранее:

• Кодировка имён. Исторически имена писались в кодировке CP437/CP866, а флаг UTF-8 появился позже. Архив, созданный в Windows с русскими именами, при распаковке в Linux может превратить имена в «кракозябры» — и наоборот.
• Точность времени. Базовое поле хранит дату с точностью до двух секунд, а год ограничен диапазоном с 1980-го. Расширенные поля добавляют точные метки, но читают их не все программы.
• Права доступа. Полноценные права Unix хранятся в дополнительных полях и восстанавливаются только при распаковке соответствующими инструментами; при переносе между системами они часто теряются.
• Владелец и ACL. Стандартный ZIP не переносит владельца файла и расширенные списки доступа — для резервного копирования системы это существенное ограничение.

Поэтому для резервного копирования Linux-серверов обычно выбирают tar.gz или tar.zst, а ZIP оставляют для обмена файлами между разными платформами, где его универсальность важнее полноты метаданных.

Шифрование и защита паролем

Формат поддерживает два механизма защиты. Устаревший ZipCrypto встроен в спецификацию с самого начала, но криптографически слаб: существуют инструменты, восстанавливающие пароль по известному фрагменту содержимого. Современный вариант — AES-128/192/256, применяемый поверх сжатых данных; он значительно надёжнее, но поддерживается не всеми распаковщиками.

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

Многотомные и потоковые архивы

Большой архив можно разбить на части равного объёма. При этом каждая часть получает свой порядковый номер, а EOCD-запись всегда находится в последнем томе. Распаковка требует полного набора: отсутствие любого среднего тома делает недоступными файлы, чьи данные попали в него, хотя остальные файлы теоретически можно извлечь вручную.

Благодаря data descriptor ZIP умеет создаваться потоково: архиватор пишет данные, не зная заранее их сжатого размера. Именно так работают архивы, генерируемые «на лету» веб-сервером при выгрузке множества файлов — пользователь начинает скачивание до того, как сервер закончил упаковку.

Что происходит при повреждении архива

Структура формата даёт неожиданный запас прочности. Типичные сценарии:

• Повреждён EOCD или центральный каталог. Программа сообщает «архив повреждён» и отказывается работать, но данные файлов целы. Специалист может пересобрать каталог по локальным заголовкам — их сигнатура PK\x03\x04 легко ищется в потоке байт.
• Обрезан конец файла. Часть файлов в начале архива извлекается без проблем, недоступны только последние. Некоторые архиваторы предлагают «восстановить» архив именно так, игнорируя каталог.
• Испорчены данные одного файла. Контрольная сумма CRC-32 не совпадёт, и распаковщик честно предупредит, что конкретный файл не прошёл проверку. Остальные файлы при этом распакуются корректно.

CRC-32 здесь работает как детектор ошибок, но не как средство исправления: он говорит, что данные изменились, но не позволяет их починить. Для критичных данных нужны отдельные механизмы восстановления — например, многотомные архивы с томами восстановления в других форматах.

Как проверить архив самостоятельно

Перед отправкой или удалением исходников архив стоит проверить. Порядок действий простой:

1. Откройте список файлов и убедитесь, что количество и имена совпадают с ожидаемыми.
2. Запустите полную проверку целостности командой архиватора (например, опция тестирования) — она распакует данные в память и сверит CRC-32 каждого файла.
3. Для ответственных данных извлеките архив во временную папку и выборочно откройте несколько крупнейших файлов: совпадение размеров и успешное открытие — хороший признак.
4. Если архив защищён паролем, проверьте его на копии до передачи получателю.

Типичные ошибки при работе с ZIP

• Переименование расширения вместо конвертации. Смена .rar на .zip ничего не меняет: внутри остаётся другой формат, и файл не откроется. Нужна перепаковка через архиватор.
• Двойное сжатие. Упаковка уже сжатого файла тратит время и место без выигрыша. Проверьте, что реально сжимается, а что лучше хранить как есть.
• Игнорирование кодировки имён. При обмене архивами между Windows и Linux используйте UTF-8-совместимые настройки архиватора либо латинские имена файлов.
• Хранение единственной копии в архиве. Повреждение одного файла контейнера может затронуть несколько записей. Архив — средство переноса, а не замена резервному копированию.
• Слабый пароль или ZipCrypto. Для чувствительных данных выбирайте AES-шифрование и длинный пароль, а сам пароль передавайте по отдельному каналу.

ZIP и другие форматы: краткое сравнение

Критерий	ZIP	TAR.GZ / TAR.ZST	7Z
Поддержка «из коробки»	Почти везде	Unix-системы; в Windows нужен софт	Через архиватор
Метаданные Unix	Ограниченно	Полностью	Частично
Произвольный доступ к файлам	Да, через каталог	Нет, последовательное чтение	Да
Выбор алгоритма сжатия	Да, на уровне файла	Определяется фильтром	Да
Типичное применение	Обмен файлами между платформами	Резервное копирование в Unix	Максимальное сжатие

Из сравнения видно главное преимущество ZIP: сочетание универсальности и произвольного доступа. Он уступает специализированным форматам в степени сжатия и полноте метаданных, но открывается практически где угодно без установки дополнительного ПО.

Практические выводы

Устройство ZIP определяет правила его разумного использования. Три принципа, которые покрывают большинство ситуаций:

• Архивируйте сжимаемые данные, медиафайлы упаковывайте без сжатия — экономии всё равно не будет.
• Для совместимости держитесь Deflate и UTF-8 в именах; экзотические методы включайте, только когда уверены в инструментах получателя.
• Помните, что «архив повреждён» часто означает проблему каталога, а не данных: до паники попробуйте функцию восстановления или распаковку частично.

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