ZIP (формат файла)

ZIP - это формат файла архива, который поддерживает сжатие данных без потерь . ZIP-файл может содержать один или несколько файлов или каталогов, которые могли быть сжаты. Формат файла ZIP позволяет использовать несколько алгоритмов сжатия , хотя DEFLATE является наиболее распространенным. Этот формат первоначально был создан в 1989 году и впервые был реализован в PKWARE, Inc. «s PKZIP полезности, ^[2] в качестве замены предыдущего АРК формата сжатия по Thom Хендерсон. Формат ZIP затем быстро стал поддерживаться многими программными утилитами, кроме PKZIP. Microsoft включила встроенную поддержку ZIP (под названием «сжатые папки») в версииMicrosoft Windows с 1998 года. Apple включила встроенную поддержку ZIP в Mac OS X 10.3 (через BOMArchiveHelper, теперь Archive Utility ) и позже. Большинство бесплатных операционных систем имеют встроенную поддержку ZIP, аналогично Windows и Mac OS X.

Файлы ZIP обычно используют расширения файлов .zip или .ZIP и тип мультимедиа MIME . ^[1] ZIP используется в качестве базового формата файла во многих программах, обычно под другим именем. При навигации по файловой системе через пользовательский интерфейс графические значки, представляющие файлы ZIP, часто отображаются в виде документа или другого объекта с заметной застежкой-молнией .application/zip

История [ править ]

Формат файла .ZIP был разработан Филом Кацем из PKWARE и Гэри Конвеем из Infinity Design Concepts. Формат был создан после того, как Systems Enhancement Associates (SEA) подала иск против PKWARE, утверждая, что архивные продукты последней, названные PKARC, являются производными от системы архивирования ARC SEA . ^[3] Название «застежка-молния» (что означает «двигаться с высокой скоростью») было предложено другом Каца, Робертом Махони. ^[4] Они хотели дать понять, что их продукт будет быстрее, чем ARC и другие форматы сжатия того времени. ^[4] Самая ранняя известная версия спецификации формата файла .ZIP. был впервые опубликован как часть пакета PKZIP 0.9 под файлом APPNOTE.TXT в 1989 году. ^{[ необходима цитата ]} Благодаря распространению формата zip-файла в APPNOTE.TXT совместимость с форматом zip-файла широко распространилась в общедоступном Интернете в течение 1990-х годов. ^[5]

14 февраля 1989 года PKWARE и Infinity Design Concepts выпустили совместный пресс-релиз, выпустив формат файла .ZIP в общественное достояние . ^{[6] [7] [8] [9] [10]}

История версий [ править ]

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

Спецификация формата файла .ZIP официально называется «APPNOTE - .ZIP File Format Specification» и публикуется на веб-сайте PKWARE.com с конца 1990-х годов. ^[11] Несколько версий спецификации не были опубликованы. Спецификации некоторых функций, таких как сжатие BZIP2 , спецификация надежного шифрования и другие, были опубликованы PKWARE через несколько лет после их создания. URL-адрес онлайн-спецификации менялся несколько раз на веб-сайте PKWARE.

Краткое изложение основных достижений в различных версиях спецификации PKWARE:

• 2.0: (1993) ^[1] Записи файлов можно сжимать с помощью DEFLATE и использовать традиционное шифрование PKWARE (ZipCrypto).
• 2.1: (1996) Сжатие Deflate64
• 4.5: (2001) ^[12] Документированный 64-битный zip-формат.
• 4.6: (2001) сжатие BZIP2 (не опубликовано в Интернете до публикации APPNOTE 5.2)
• 5.0: (2002) SES: DES , Triple DES , RC2 , RC4 поддерживается для шифрования (не опубликовано в Интернете до публикации APPNOTE 5.2)
• 5.2: (2003) ^{[13] [14]} Поддержка шифрования AES для SES (определено в APPNOTE 5.1, которое не было опубликовано в сети) и AES из WinZip («AE-x»); исправленная версия RC2-64, поддерживающая шифрование SES.
• 6.1: (2004) ^[15] Документированное хранилище сертификатов.
• 6.2.0: (2004) ^[16] Документированное шифрование центрального каталога.
• 6.3.0: (2006) ^[17] Хранение файлов с документированным Unicode ( UTF-8 ). Расширен список поддерживаемых алгоритмов хеширования, сжатия ( LZMA , PPMd + ), шифрования.
• 6.3.1: (2007) ^[18] Исправленные стандартные хеш-значения для SHA-256/384/512.
• 6.3.2: (2007) ^[19] Документированный метод сжатия 97 ( WavPack ).
• 6.3.3: (2012) ^[20] Изменения в форматировании документа для облегчения ссылок на указания по применению PKWARE из других стандартов с использованием таких методов, как JTC 1 Referencing Explanatory Report (RER), как указано в JTC 1 / SC 34 N 1621.
• 6.3.4: (2014) ^[21] Обновляет адрес офиса PKWARE, Inc.
• 6.3.5: (2018) ^[22] Задокументированы методы сжатия 16, 96 и 99, эпоха и точность временных меток DOS, добавлены дополнительные поля для ключей и дешифрования, а также опечатки и пояснения.
• 6.3.6: (2019) ^[23] Исправлена ​​опечатка.
• 6.3.7: (2020) ^[24] Добавлен метод сжатия Zstandard с идентификатором 20.
• 6.3.8: (2020) ^[25] Идентификатор метода сжатия Zstandard перемещен с 20 на 93, исключая предыдущий. Документированные идентификаторы метода 94 и 95 ( MP3 и XZ соответственно).
• 6.3.9: (2020) ^[26] Исправлена ​​опечатка в описании выравнивания потока данных.

WinZip , начиная с версии 12.1, использует расширение .zipx для файлов ZIP, которые используют более новые методы сжатия, чем DEFLATE; в частности, методы BZip, LZMA, PPMd, Jpeg и Wavpack. Последние 2 применяются к соответствующим типам файлов, когда выбрано сжатие «Лучший метод». ^{[27] [28]}

Стандартизация [ править ]

В апреле 2010 года ISO / IEC JTC 1 инициировал голосование, чтобы определить, следует ли инициировать проект по созданию международного стандартного формата ISO / IEC, совместимого с ZIP. ^[29] Предлагаемый проект под названием Document Packaging предусматривал ZIP-совместимый «минимальный сжатый архивный формат», подходящий для использования с рядом существующих стандартов, включая OpenDocument , Office Open XML и EPUB .

В 2015 году был опубликован ISO / IEC 21320-1 «Файл-контейнер документа - Часть 1: Ядро», в котором говорится, что «Файлы-контейнеры документов соответствуют файлам Zip». Это требует следующих основных ограничений формата файла ZIP: ^[30]

• Файлы в ZIP-архивах могут храниться только в несжатом виде или с использованием сжатия «deflate» (т. Е. Метод сжатия может содержать значение «0» - сохранено или «8» - спущено).
• Функции шифрования запрещены.
• Использование цифровой подписи (от SES) запрещено.
• Функции "исправленных данных" (от PKPatchMaker) запрещены.
• Архивы не могут охватывать несколько томов или быть сегментированными.

Дизайн [ править ]

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

Каталог помещается в конец ZIP-файла. Это определяет, какие файлы находятся в ZIP-архиве, и определяет, где в ZIP-архиве находится этот файл. Это позволяет читателям ZIP загружать список файлов без чтения всего ZIP-архива. ZIP-архивы также могут включать в себя дополнительные данные, не относящиеся к ZIP-архиву. Это позволяет преобразовать ZIP-архив в самораспаковывающийся архив (приложение, которое распаковывает содержащиеся в нем данные), добавляя программный код к ZIP-архиву и отмечая файл как исполняемый. Сохранение каталога в конце также позволяет скрыть заархивированный файл, добавив его к безобидному файлу, например к файлу изображения GIF.

Формат .ZIP использует 32-битный алгоритм CRC и включает две копии структуры каталогов архива для обеспечения большей защиты от потери данных.

Структура [ править ]

ZIP-файл правильно идентифицируется по наличию конца записи центрального каталога, который находится в конце структуры архива, чтобы можно было легко добавлять новые файлы. Если конец записи центрального каталога указывает на непустой архив, имя каждого файла или каталога в архиве должно быть указано в записи центрального каталога вместе с другими метаданными о записи и смещением в ZIP-файле, указывающим к фактическим входным данным. Это позволяет относительно быстро составлять список файлов архива, поскольку не нужно читать весь архив, чтобы увидеть список файлов. Записи в ZIP-файле также включают эту информацию для избыточности в локальный заголовок файла.. Поскольку файлы ZIP могут быть добавлены, допустимы только файлы, указанные в центральном каталоге в конце файла. Сканирование ZIP-файла на предмет локальных заголовков файлов недопустимо (за исключением случаев поврежденных архивов), поскольку центральный каталог может объявлять, что некоторые файлы были удалены, а другие обновлены.

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

Порядок записей файлов в центральном каталоге не обязательно должен совпадать с порядком записей файлов в архиве.

Каждая запись, хранящаяся в архиве ZIP, представлена локальным заголовком файла с информацией о файле, такой как комментарий, размер файла и имя файла, за которыми следуют необязательные «дополнительные» поля данных, а затем возможно сжатые, возможно зашифрованные данные файла. «Дополнительные» поля данных являются ключом к расширяемости формата ZIP. «Дополнительные» поля используются для поддержки формата ZIP64, WinZip-совместимого шифрования AES, атрибутов файлов и временных меток файлов NTFS или Unix с более высоким разрешением. Другие расширения возможны через поле «Дополнительно». По спецификации инструменты ZIP должны игнорировать лишние поля, которые они не распознают.

Формат ZIP использует определенные 4-байтовые «подписи» для обозначения различных структур в файле. Каждая запись файла помечена определенной подписью. Конец записи центрального каталога обозначается ее конкретной подписью, и каждая запись в центральном каталоге начинается с 4-байтовой подписи заголовка центрального файла .

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

Инструменты, которые правильно читают ZIP-архивы, должны сканировать конец подписи записи центрального каталога, а затем, при необходимости, другие указанные записи центрального каталога. Они не должны сканировать записи из верхней части ZIP-файла, потому что (как упоминалось ранее в этом разделе) только центральный каталог указывает, где начинается фрагмент файла и что он не был удален. Сканирование может привести к ложным срабатываниям, поскольку формат не запрещает другим данным находиться между фрагментами, а также потокам данных файлов не содержать такие подписи. Однако инструменты, которые пытаются восстановить данные из поврежденных ZIP-архивов, скорее всего, будут сканировать архив на наличие подписей локальных заголовков файлов; это усложняется тем фактом, что сжатый размер фрагмента файла может быть сохранен после фрагмента файла, что затрудняет последовательную обработку.

Большинство подписей оканчиваются коротким целым числом 0x4b50, которое хранится в порядке от младшего к старшему . Рассматриваемый как строка ASCII, он читается как «PK», инициалы изобретателя Фила Каца. Таким образом, когда ZIP-файл просматривается в текстовом редакторе, первые два байта файла обычно являются «PK». (Самораспаковывающиеся ZIP-файлы для DOS, OS / 2 и Windows имеют EXE перед ZIP -файлом, поэтому начинайте с «MZ»; самораспаковывающимся ZIP-файлам для других операционных систем может также предшествовать исполняемый код для извлечения содержимого архива на этой платформе.)

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

Файловая система FAT из DOS имеет разрешение временных меток составляют всего две секунды; Записи в формате ZIP имитируют это. В результате встроенное разрешение временных меток файлов в ZIP-архиве составляет всего две секунды, хотя дополнительные поля могут использоваться для хранения более точных временных меток. Формат ZIP не имеет понятия о часовом поясе , поэтому временные метки имеют смысл только в том случае, если известно, в каком часовом поясе они были созданы.

In September 2007, PKWARE released a revision of the ZIP specification providing for the storage of file names using UTF-8, finally adding Unicode compatibility to ZIP.^[31]

File headers[edit]

All multi-byte values in the header are stored in little-endian byte order. All length fields count the length in bytes.

Local file header[edit]

The extra field contains a variety of optional data such as OS-specific attributes. It is divided into records, each with at minimum a 16-bit signature and a 16-bit length. A ZIP64 local file extra field record, for example, has the signature 0x0001 and a length of 16 bytes (or more) so that two 64-bit values (the compressed and uncompressed sizes) may follow. Another common local file extension is 0x5455 (or "UT") which contains 32-bit UTC UNIX timestamps.

This is immediately followed by the compressed data.

Data descriptor[edit]

If the bit at offset 3 (0x08) of the general-purpose flags field is set, then the CRC-32 and file sizes are not known when the header is written. The fields in the local header are filled with zero, and the CRC-32 and size are appended in a 12-byte structure (optionally preceded by a 4-byte signature) immediately after the compressed data:

Central directory file header[edit]

The central directory entry is an expanded form of the local header:

End of central directory record (EOCD)[edit]

After all the central directory entries comes the end of central directory (EOCD) record, which marks the end of the ZIP file:

This ordering allows a ZIP file to be created in one pass, but the central directory is also placed at the end of the file in order to facilitate easy removal of files from multiple-part (e.g. "multiple floppy-disk") archives, as previously discussed.

Compression methods[edit]

The .ZIP File Format Specification documents the following compression methods: Store (no compression), Shrink (LZW), Reduce (levels 1-4; LZ77 + probabilistic), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, and a LZ77 variant provided by IBM z/OS CMPSC instruction.^[32][22] The most commonly used compression method is DEFLATE, which is described in IETF RFC 1951.

Other methods mentioned, but not documented in detail in the specification include: PKWARE DCL Implode (old IBM TERSE), new IBM TERSE, IBM LZ77 z Architecture (PFS), and a JPEG variant. A "Tokenize" method was reserved for a third party, but support was never added.^[22]

The word Implode is overused by PKWARE: the DCL/TERSE Implode is distinct from the old PKZIP Implode, a predecessor to Deflate. The DCL Implode is undocumented partially due to its proprietrary nature held by IBM, but Mark Adler has nevertheless provided a decompressor called "blast" alongside zlib.^[33]

Encryption[edit]

ZIP supports a simple password-based symmetric encryption system generally known as ZipCrypto. It is documented in the ZIP specification, and known to be seriously flawed. In particular, it is vulnerable to known-plaintext attacks, which are in some cases made worse by poor implementations of random-number generators.^[5]

New features including new compression and encryption (e.g. AES) methods have been documented in the ZIP File Format Specification since version 5.2. A WinZip-developed AES-based open standard ("AE-x" in APPNOTE) is used also by 7-Zip and Xceed, but some vendors use other formats.^[34] PKWARE SecureZIP (SES, proprietary) also supports RC2, RC4, DES, Triple DES encryption methods, Digital Certificate-based encryption and authentication (X.509), and archive header encryption. It is, however, patented (see § Strong encryption controversy).^[35]

File name encryption is introduced in .ZIP File Format Specification 6.2, which encrypts metadata stored in Central Directory portion of an archive, but Local Header sections remain unencrypted. A compliant archiver can falsify the Local Header data when using Central Directory Encryption. As of version 6.2 of the specification, the Compression Method and Compressed Size fields within Local Header are not yet masked.

ZIP64[edit]

The original .ZIP format had a 4 GiB (2³² bytes) limit on various things (uncompressed size of a file, compressed size of a file, and total size of the archive), as well as a limit of 65,535 (2¹⁶) entries in a ZIP archive. In version 4.5 of the specification (which is not the same as v4.5 of any particular tool), PKWARE introduced the "ZIP64" format extensions to get around these limitations, increasing the limits to 16 EiB (2⁶⁴ bytes). In essence, it uses a "normal" central directory entry for a file, followed by an optional "zip64" directory entry, which has the larger fields.^[36]

The format of the Local file header (LOC) and Central directory entry (CEN) are the same in ZIP and ZIP64. However, ZIP64 specifies an extra field that may be added to those records at the discretion of the compressor, whose purpose is to store values that do not fit in the classic LOC or CEN records. To signal that the actual values are stored in ZIP64 extra fields, they are set to 0xFFFF or 0xFFFFFFFF in the corresponding LOC or CEN record.

On the other hand, the format of EOCD for ZIP64 is slightly different than the normal ZIP version.^[31]

It is also not necessarily the last record in the file. A End of Central Directory Locator follows (an additional 20 bytes at the end).

The File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista and later do.^{[citation needed]} Likewise, some extension libraries support ZIP64, such as DotNetZip, QuaZIP^[37] and IO::Compress::Zip in Perl. Python's built-in zipfile supports it since 2.5 and defaults to it since 3.4.^[38] OpenJDK's built-in java.util.zip supports ZIP64 from version Java 7.^[39] Android Java API support ZIP64 since Android 6.0.^[40] Mac OS Sierra's Archive Utility notably does not support ZIP64, and can create corrupt archives when ZIP64 would be required.^[41] However, the ditto command shipped with Mac OS will unzip ZIP64 files.^[42] More recent^[when?] versions of Mac OS ship with info-zip's zip and unzip command line tools which do support Zip64: to verify run zip -v and look for "ZIP64_SUPPORT".

Combination with other file formats[edit]

The .ZIP file format allows for a comment containing up to 65,535 (2¹⁶−1) bytes of data to occur at the end of the file after the central directory.^[31] Also, because the central directory specifies the offset of each file in the archive with respect to the start, it is possible for the first file entry to start at an offset other than zero, although some tools, for example gzip, will not process archive files that do not start with a file entry at offset zero.

This allows arbitrary data to occur in the file both before and after the ZIP archive data, and for the archive to still be read by a ZIP application. A side-effect of this is that it is possible to author a file that is both a working ZIP archive and another format, provided that the other format tolerates arbitrary data at its end, beginning, or middle. Self-extracting archives (SFX), of the form supported by WinZip, take advantage of this, in that they are executable (.exe) files that conform to the PKZIP AppNote.txt specification, and can be read by compliant zip tools or libraries.

This property of the .ZIP format, and of the JAR format which is a variant of ZIP, can be exploited to hide rogue content (such as harmful Java classes) inside a seemingly harmless file, such as a GIF image uploaded to the web. This so-called GIFAR exploit has been demonstrated as an effective attack against web applications such as Facebook.^[43]

Limits[edit]

The minimum size of a .ZIP file is 22 bytes. Such an empty zip file contains only an End of Central Directory Record (EOCD):
[0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

The maximum size for both the archive file and the individual files inside it is 4,294,967,295 bytes (2³²−1 bytes, or 4 GiB minus 1 byte) for standard ZIP. For ZIP64, the maximum size is 18,446,744,073,709,551,615 bytes (2⁶⁴−1 bytes, or 16 EiB minus 1 byte).^[44]

Proprietary extensions[edit]

Extra field[edit]

.ZIP file format includes an extra field facility within file headers, which can be used to store extra data not defined by existing ZIP specifications, and which allow compliant archivers that do not recognize the fields to safely skip them. Header IDs 0–31 are reserved for use by PKWARE. The remaining IDs can be used by third-party vendors for proprietary usage.

Strong encryption controversy[edit]

When WinZip 9.0 public beta was released in 2003, WinZip introduced its own AES-256 encryption, using a different file format, along with the documentation for the new specification.^[45] The encryption standards themselves were not proprietary, but PKWARE had not updated APPNOTE.TXT to include Strong Encryption Specification (SES) since 2001, which had been used by PKZIP versions 5.0 and 6.0. WinZip technical consultant Kevin Kearney and StuffIt product manager Mathew Covington accused PKWARE of withholding SES, but PKZIP chief technology officer Jim Peterson claimed that certificate-based encryption was still incomplete.

In another controversial move, PKWare applied for a patent on 16 July 2003 describing a method for combining ZIP and strong encryption to create a secure file.^[46]

In the end, PKWARE and WinZip agreed to support each other's products. On 21 January 2004, PKWARE announced the support of WinZip-based AES compression format.^[47] In a later version of WinZip beta, it was able to support SES-based ZIP files.^[48] PKWARE eventually released version 5.2 of the .ZIP File Format Specification to the public, which documented SES. The Free Software project 7-Zip also supports AES, but not SES in ZIP files (as does its POSIX port p7zip).

When using AES encryption under WinZip, the compression method is always set to 99, with the actual compression method stored in an AES extra data field.^[49] In contrast, Strong Encryption Specification stores the compression method in the basic file header segment of Local Header and Central Directory, unless Central Directory Encryption is used to mask/encrypt metadata.

Implementation[edit]

There are numerous .ZIP tools available, and numerous .ZIP libraries for various programming environments; licenses used include proprietary and free software. WinZip, WinRAR, Info-ZIP, 7-Zip, PeaZip and B1 Free Archiver are well-known .ZIP tools, available on various platforms. Some of those tools have library or programmatic interfaces.

Some development libraries licensed under open source agreement are libzip, libarchive, and Info-ZIP. For Java: Java Platform, Standard Edition contains the package "java.util.zip" to handle standard .ZIP files; the Zip64File library specifically supports large files (larger than 4 GB) and treats .ZIP files using random access; and the Apache Ant tool contains a more complete implementation released under the Apache Software License.

The Info-ZIP implementations of the .ZIP format adds support for Unix filesystem features, such as user and group IDs, file permissions, and support for symbolic links. The Apache Ant implementation is aware of these to the extent that it can create files with predefined Unix permissions. The Info-ZIP implementations also know how to use the error correction capabilities built into the .ZIP compression format. Some programs do not, and will fail on a file that has errors.

The Info-ZIP Windows tools also support NTFS filesystem permissions, and will make an attempt to translate from NTFS permissions to Unix permissions or vice versa when extracting files. This can result in potentially unintended combinations, e.g. .exe files being created on NTFS volumes with executable permission denied.

Versions of Microsoft Windows have included support for .ZIP compression in Explorer since the Microsoft Plus! pack was released for Windows 98. Microsoft calls this feature "Compressed Folders". Not all .ZIP features are supported by the Windows Compressed Folders capability. For example, encryption is not supported in Windows 10 Home edition,^[50] although it can decrypt. Unicode entry encoding is not supported until Windows 7, while split and spanned archives are not readable or writable by the Compressed Folders feature, nor is AES Encryption supported.^[51]

Microsoft Office started using the zip archive format in 2006 for their Office Open XML .docx, .xlsx, .pptx, etc. files, which became the default file format with Microsoft Office 2007.

Legacy[edit]

There are numerous other standards and formats using "zip" as part of their name. For example, zip is distinct from gzip, and the latter is defined in IETF RFC 1952. Both zip and gzip primarily use the DEFLATE algorithm for compression. Likewise, the ZLIB format (IETF RFC 1950) also uses the DEFLATE compression algorithm, but specifies different headers for error and consistency checking. Other common, similarly named formats and programs with different native formats include 7-Zip, bzip2, and rzip.

Concerns[edit]

The theoretical maximum compression factor for a raw DEFLATE stream is about 1032 to one,^[52] but by exploiting the ZIP format in unintended ways, ZIP archives with compression ratios of billions to one can be constructed. These zip bombs unzip to extremely large sizes, overwhelming the capacity of the computer they are decompressed on.^[53]

See also[edit]

• Comparison of file archivers
• Comparison of archive formats
• List of archive formats
• LZW

References[edit]

External links[edit]

• .ZIP Application Note—landing page for PKWARE's current and historical .ZIP file
• ISO/IEC 21320-1:2015 — Document Container File — Part 1: Core
• Zip Files: History, Explanation and Implementation
• Shrink, Reduce, and Implode: The Legacy Zip Compression Methods
• APPNOTE.TXT mirror

Format Specifications:

• Structure of PKZip file—graphical tables