Кратко

  • В RFC 1952 gzip-файл состоит из последовательных элементов, каждый со своим заголовком, сжатыми блоками и трейлером CRC32/ISIZE.
  • Новый корректный элемент дополняет распакованный результат без перезаписи старых байтов, но не создаёт индекс, произвольный доступ или оптимальное межэлементное сжатие.
  • Необязательные имена и даты не доказывают происхождение; CRC32 обнаруживает повреждение, а ISIZE задаёт локальную длину по модулю 2^32.

Неизменный префикс не означает неизменный результат

Вчера система закрыла сжатый журнал. Сегодня она добавила в конец ещё один gzip-поток. Хэш старого участка совпадает побайтно, но чтение с начала выдаёт уже два дня данных.

Так устроен RFC 1952: gzip-файл — серия элементов без дополнительной общей оболочки между ними. У каждого собственный узнаваемый заголовок, блоки и трейлер. Конец закрывает элемент, а не запрещает следующую допустимую единицу.

Карточка RFC Editor датирует Informational-документ P. Deutsch маем 1996 года. Это не стандарт Standards Track и не свидетельство одинакового поведения всех программ. Целями были переносимость, потоковая обработка с ограниченной памятью, свободная реализация и совместимость с gzip; произвольный доступ не обещался.

Обязательные границы и необязательные рассказы

Два фиксированных байта распознают gzip, CM=8 обозначает DEFLATE. FLG объявляет необязательные поля, резервные биты должны быть нулевыми. Здесь независимым реализациям необходимо согласие.

MTIME, FNAME, FCOMMENT, FEXTRA и FTEXT могут сообщать время, исходное имя, комментарий, расширение или предполагаемый текстовый тип. Читатель обязан уметь пропустить их, даже если не использует. Нулевое время означает отсутствие значения, OS разрешено игнорировать.

Встроенное имя — не удостоверение происхождения. Комментарий не подписывает цепочку хранения. Время не доказывает момент добавления в нынешний объект. Это полезные утверждения только при внешнем доверии.

FHCRC, если есть, хранит младшие 16 бит CRC32 предыдущего заголовка. CRC32 трейлера относится к распакованным данным элемента. ISIZE содержит их исходную длину по модулю 2^32. Их области различны.

Совпавшая контрольная сумма не называет автора

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

ISIZE циклически повторяется через 2^32 и описывает один элемент. Общий размер многокомпонентного файла появляется только после чтения и суммирования всех выходов.

Алгоритм сжатия отделён от оболочки. RFC 1951 задаёт DEFLATE. RFC 1950 помещает его в другую оболочку zlib с собственным заголовком и Adler-32. RFC 6713 позднее зарегистрировал application/gzip и application/zlib, различив файловые поля gzip и потоковый формат zlib.

Реализация показывает разную глубину обзора

Руководство GNU gzip описывает конкатенацию: gunzip распакует все элементы. Оно же предупреждает, что совместное сжатие обычно эффективнее, а --list для нескольких элементов показывает размер и CRC только последнего.

Значит, распаковка и список могут честно видеть разный объём. Аудит ошибётся, если назовёт локальную сводку последнего элемента свойством всего файла.

RFC 9110 определяет HTTP-кодирование gzip ссылкой на RFC 1952. Это сохраняет термин, но не доказывает одинаковую обработку нескольких элементов всеми клиентами, посредниками и сканерами.

Минимальное соглашение повторяется на каждом шве

Running-Code Primacy разделяет публикацию, реализацию и эксплуатацию. RFC доказывает синтаксис, руководство — поведение одного поддерживаемого продукта. Универсальной статистики из них не получается.

Minimum Initial Specification показывает, почему малый контракт строг: распознавание, метод, длины, резервные биты и трейлер общие; показ комментария и применение времени могут быть локальными.

Reality Layers отделяет символ «один файл» от исполняемой реальности с несколькими началами, концами и проверками. Имя одно, структура последовательна.