A writer that cannot seek back in its output does not know a member’s CRC-32 and sizes when it writes the local header. It sets flag bit 3, writes zeros in those three fields, and writes the real values in a data descriptor straight after the data.
When it is used
A data descriptor must follow the data when bit 3 of the general purpose bit flag is set, and appears nowhere else. APPNOTE says it should be used only when the output cannot seek, as with standard output or a non-seekable device. PKZIP 2.04g recognised bit 3 for Deflate only; later versions recognise it for any method. The central directory always has the correct values.
When the central directory is encrypted, a data descriptor is optional, and if one is present with bit 3 set its values must be zeros.
Layout
The descriptor follows the last byte of the data, with no alignment. The signature is
not an official part of the format: APPNOTE says the value
0x08074B50 was never assigned, but it is in common use, so writers should
include it and readers must cope with or without it.
| Offset | Size | Name | Description |
|---|---|---|---|
0 | 4 | Signature | 50 4B 07 08. Optional. |
4 | 4 | CRC-32 | The CRC-32 of the uncompressed data. |
8 | 4 or 8 | Compressed size | The size of the data as stored. |
12 or 16 | 4 or 8 | Uncompressed size | The size after decompression. |
Without the signature, every offset is 4 less. Each size is 8 bytes when the member
uses ZIP64: APPNOTE says to use 8-byte sizes when a file’s size exceeds
0xFFFFFFFF, allows them at any size, and tells readers to expect them when
the member has a ZIP64 extra field. So a
descriptor is one of four lengths:
| Form | Size in bytes |
|---|---|
| No signature, 32-bit sizes | 12 |
| Signature, 32-bit sizes | 16 |
| No signature, 64-bit sizes | 20 |
| Signature, 64-bit sizes | 24 |
How a reader copes
A reader using the central directory has no problem. It takes the CRC-32 and sizes from the central header, and can skip the descriptor by treating the next member as starting wherever the next local header is.
A reader walking the file from the start has two problems: where the data ends, and which form the descriptor takes.
- Where the data ends. A self-terminating method such as Deflate stops by itself at the end of its last block, so the descriptor follows. With method 0 and bit 3 there is no end marker, and the reader can only search for a plausible descriptor, whose size must match the distance searched. That search is fooled by data that happens to contain the same bytes. Writers should not use bit 3 with method 0. The pitfalls page explains how this splits readers.
- Which form. After decompressing, the reader knows the true CRC-32 and sizes. It tries each form and takes the one whose values match. If the first four bytes are the signature, the CRC-32 starts after them, but a member’s real CRC-32 could equal the signature, so the match has to be made on all the values. The presence of a ZIP64 extra field is a guide to the size width, not a proof.
The explorer reads the descriptor when bit 3 is set in either header. It compares each form with the central directory’s values and uses whichever matches. If bit 3 is clear but a descriptor with exactly those values follows the data, it reports it as a descriptor all the same, and notes the missing flag.
The same value, 50 4B 07 08, also marks the
start of a split archive. APPNOTE
says position in the file decides which it is.