Zip (file format)


ZIP is an archive file format that supports lossless data compression. A ZIP file may contain one or more files or directories that may have been compressed. The ZIP file format permits a number of compression algorithms, though DEFLATE is the most common. This format was originally created in 1989 and was first implemented in PKWARE, Inc.'s PKZIP utility, as a replacement for the previous ARC compression format by Thom Henderson. The ZIP format was then quickly supported by many software utilities other than PKZIP. Microsoft has included built-in ZIP support in versions of Microsoft Windows since 1998. Apple has included built-in ZIP support in Mac OS X 10.3 and later. Most :Category:Free software operating systems|free operating systems have built in support for ZIP in similar manners to Windows and Mac OS X.
ZIP files generally use the file extensions or and the MIME media type application/zip. ZIP is used as a base file format by many programs, usually under a different name. When navigating a file system via a user interface, graphical icons representing ZIP files often appear as a document or other object prominently featuring a zipper.

History

The file format was designed by Phil Katz of PKWARE and Gary Conway of Infinity Design Concepts. The format was created after Systems Enhancement Associates filed a lawsuit against PKWARE claiming that the latter's archiving products, named PKARC, were derivatives of SEA's ARC archiving system. The name "zip" By distributing the zip file format within APPNOTE.TXT, compatibility with the zip file format proliferated widely on the public Internet during the 1990s.
PKWARE and Infinity Design Concepts made a joint press release on February 14, 1989 releasing the file format into the public domain.

Version history

The.ZIP File Format Specification has its own version number, which does not necessarily correspond to the version numbers for the PKZIP tool, especially with PKZIP 6 or later. At various times, PKWARE has added preliminary features that allow PKZIP products to extract archives using advanced features, but PKZIP products that create such archives are not made available until the next major release. Other companies or organizations support the PKWARE specifications at their own pace.
The.ZIP file format specification is formally named "APPNOTE -.ZIP File Format Specification" and it is published on the PKWARE.com website since the late 1990s. Several versions of the specification were not published. Specifications of some features such as BZIP2 compression, strong encryption specification and others were published by PKWARE a few years after their creation. The URL of the online specification was changed several times on the PKWARE website.
A summary of key advances in various versions of the PKWARE specification:
WinZip, starting with version 12.1, uses the extension for ZIP files that use compression methods newer than DEFLATE; specifically, methods BZip, LZMA, PPMd, Jpeg and Wavpack. The last 2 are applied to appropriate file types when "Best method" compression is selected.

Standardization

In April 2010, ISO/IEC JTC 1 initiated a ballot to determine whether a project should be initiated to create an ISO/IEC International Standard format compatible with ZIP. The proposed project, entitled Document Packaging, envisaged a ZIP-compatible 'minimal compressed archive format' suitable for use with a number of existing standards including OpenDocument, Office Open XML and EPUB.
In 2015, ISO/IEC 21320-1 "Document Container File — Part 1: Core" was published which states that "Document container files are conforming Zip files". It requires the following main restrictions of the ZIP file format:
files are archives that store multiple files. ZIP allows contained files to be compressed using many different methods, as well as simply storing a file without compressing it. Each file is stored separately, allowing different files in the same archive to be compressed using different methods. Because the files in a ZIP archive are compressed individually it is possible to extract them, or add new ones, without applying compression or decompression to the entire archive. This contrasts with the format of compressed tar files, for which such random-access processing is not easily possible.
A directory is placed at the end of a ZIP file. This identifies what files are in the ZIP and identifies where in the ZIP that file is located. This allows ZIP readers to load the list of files without reading the entire ZIP archive. ZIP archives can also include extra data that is not related to the ZIP archive. This allows for a ZIP archive to be made into a self-extracting archive, by prepending the program code to a ZIP archive and marking the file as executable. Storing the catalog at the end also makes possible hiding a zipped file by appending it to an innocuous file, such as a GIF image file.
The format uses a 32-bit CRC algorithm and includes two copies of the directory structure of the archive to provide greater protection against data loss.

Structure

A ZIP file is correctly identified by the presence of an end of central directory record which is located at the end of the archive structure in order to allow the easy appending of new files. If the end of central directory record indicates a non-empty archive, the name of each file or directory within the archive should be specified in a central directory entry, along with other metadata about the entry, and an offset into the ZIP file, pointing to the actual entry data. This allows a file listing of the archive to be performed relatively quickly, as the entire archive does not have to be read to see the list of files. The entries within the ZIP file also include this information, for redundancy, in a local file header. Because ZIP files may be appended to, only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid, as the central directory may declare that some files have been deleted and other files have been updated.
For example, we may start with a ZIP file that contains files A, B and C. File B is then deleted and C updated. This may be achieved by just appending a new file C to the end of the original ZIP file and adding a new central directory that only lists file A and the new file C. When ZIP was first designed, transferring files by floppy disk was common, yet writing to disks was very time consuming. If you had a large zip file, possibly spanning multiple disks, and only needed to update a few files, rather than reading and re-writing all the files, it would be substantially faster to just read the old central directory, append the new files then append an updated central directory.
The order of the file entries in the central directory need not coincide with the order of file entries in the archive.
Each entry stored in a ZIP archive is introduced by a local file header with information about the file such as the comment, file size and file name, followed by optional "extra" data fields, and then the possibly compressed, possibly encrypted file data. The "Extra" data fields are the key to the extensibility of the ZIP format. "Extra" fields are exploited to support the ZIP64 format, WinZip-compatible AES encryption, file attributes, and higher-resolution NTFS or Unix file timestamps. Other extensions are possible via the "Extra" field. ZIP tools are required by the specification to ignore Extra fields they do not recognize.
The ZIP format uses specific 4-byte "signatures" to denote the various structures in the file. Each file entry is marked by a specific signature. The end of central directory record is indicated with its specific signature, and each entry in the central directory starts with the 4-byte central file header signature.
There is no BOF or EOF marker in the ZIP specification. Conventionally the first thing in a ZIP file is a ZIP entry, which can be identified easily by its local file header signature. However, this is not necessarily the case, as this not required by the ZIP specification - most notably, a self-extracting archive will begin with an executable file header.
Tools that correctly read ZIP archives must scan for the end of central directory record signature, and then, as appropriate, the other, indicated, central directory records. They must not scan for entries from the top of the ZIP file, because only the central directory specifies where a file chunk starts and that it has not been deleted. Scanning could lead to false positives, as the format does not forbid other data to be between chunks, nor file data streams from containing such signatures. However, tools that attempt to recover data from damaged ZIP archives will most likely scan the archive for local file header signatures; this is made more difficult by the fact that the compressed size of a file chunk may be stored after the file chunk, making sequential processing difficult.
Most of the signatures end with the short integer 0x4b50, which is stored in little-endian ordering. Viewed as an ASCII string this reads "PK", the initials of the inventor Phil Katz. Thus, when a ZIP file is viewed in a text editor the first two bytes of the file are usually "PK".
The specification also supports spreading archives across multiple file-system files. Originally intended for storage of large ZIP files across multiple floppy disks, this feature is now used for sending ZIP archives in parts over email, or over other transports or removable media.
The FAT filesystem of DOS has a timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.
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.

File headers

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

OffsetBytesDescription
04Local file header signature = 0x04034b50
42Version needed to extract
62General purpose bit flag
82Compression method
102File last modification time
122File last modification date
144CRC-32 of uncompressed data
184Compressed size
224Uncompressed size
262File name length
282Extra field length
30nFile name
30+nmExtra field

The extra field contains a variety of optional data such as OS-specific attributes. It is divided into chunks, each with a 16-bit ID code and a 16-bit length.
This is immediately followed by the compressed data.

Data descriptor

If the bit at offset 3 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 immediately after the compressed data:
OffsetBytesDescription
00/4Optional data descriptor signature = 0x08074b50
0/44CRC-32 of uncompressed data
4/84Compressed size
8/124Uncompressed size

Central directory file header

The central directory entry is an expanded form of the local header:
OffsetBytesDescription
04Central directory file header signature = 0x02014b50
42Version made by
62Version needed to extract
82General purpose bit flag
102Compression method
122File last modification time
142File last modification date
164CRC-32 of uncompressed data
204Compressed size
244Uncompressed size
282File name length
302Extra field length
322File comment length
342Disk number where file starts
362Internal file attributes
384External file attributes
424Relative offset of local file header. This is the number of bytes between the start of the first disk on which the file occurs, and the start of the local file header. This allows software reading the central directory to locate the position of the file inside the ZIP file.
46nFile name
46+nmExtra field
46+n+mkFile comment

End of central directory record (EOCD)

After all the central directory entries comes the end of central directory record, which marks the end of the ZIP file:
OffsetBytesDescription
04End of central directory signature = 0x06054b50
42Number of this disk
62Disk where central directory starts
82Number of central directory records on this disk
102Total number of central directory records
124Size of central directory
164Offset of start of central directory, relative to start of archive
202Comment length
22nComment

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 archives, as previously discussed.

Compression methods

The.ZIP File Format Specification documents the following compression methods: Store, Shrink, Reduce, Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, and a LZ77 variant provided by IBM z/OS CMPSC instruction. 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, new IBM TERSE, IBM LZ77 z Architecture, and a JPEG variant. A "Tokenize" method was reserved for a third party, but support was never added.
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.

Encryption

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.
New features including new compression and encryption methods have been documented in the ZIP File Format Specification since version 5.2. A WinZip-developed AES-based open standard is used also by 7-Zip and Xceed, but some vendors use other formats. PKWARE SecureZIP also supports RC2, RC4, DES, Triple DES encryption methods, Digital Certificate-based encryption and authentication, and archive header encryption. It is, however, patented.
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

The original format had a 4 GiB limit on various things, as well as a limit of 65,535 entries in a ZIP archive. In version 4.5 of the specification, PKWARE introduced the "ZIP64" format extensions to get around these limitations, increasing the limits to 16 EiB. In essence, it uses a "normal" central directory entry for a file, followed by an optional "zip64" directory entry, which has the larger fields.
The File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista and later do. Likewise, some extension libraries support ZIP64, such as DotNetZip, QuaZIP and IO::Compress::Zip in Perl. Python's built-in zipfile supports it since 2.5 and defaults to it since 3.4. OpenJDK's built-in java.util.zip supports ZIP64 from version Java 7. Android Java API support ZIP64 since Android 6.0. Mac OS Sierra's Archive Utility notably does not support ZIP64, and can create corrupt archives when ZIP64 would be required. However, the ditto command shipped with Mac OS will unzip ZIP64 files. More recent 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

The file format allows for a comment containing up to 65,535 bytes of data to occur at the end of the file after the central directory. 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, of the form supported by WinZip, take advantage of this, in that they are executable files that conform to the PKZIP AppNote.txt specification, and can be read by compliant zip tools or libraries.
This property of the format, and of the JAR format which is a variant of ZIP, can be exploited to hide rogue content 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.

Limits

The minimum size of a file is 22 bytes. Such an empty zip file contains only an End of Central Directory Record :

The maximum size for both the archive file and the individual files inside it is 4,294,967,295 bytes for standard ZIP. For ZIP64, the maximum size is 18,446,744,073,709,551,615 bytes.

Proprietary extensions

Extra field

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

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. The encryption standards themselves were not proprietary, but PKWARE had not updated APPNOTE.TXT to include Strong Encryption Specification 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 describing a method for combining ZIP and strong encryption to create a secure file.
In the end, PKWARE and WinZip agreed to support each other's products. On, PKWARE announced the support of WinZip-based AES compression format. In a later version of WinZip beta, it was able to support SES-based ZIP files. 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.
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. 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

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 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, 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.
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

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 an IETF RFC. Both zip and gzip primarily use the DEFLATE algorithm for compression. Likewise, the ZLIB format 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

The theoretical maximum compression factor for a raw DEFLATE stream is about 1032 to one, 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.