Disclaimer February 10, 1989 ---------- ----------------- Although PKWARE will attempt to supply current and accurate information relating to its file formats, algorithms, and the subject programs, the possibility of error can not be eliminated. PKWARE therefore expressly disclaims any warranty that the information contained in the associated materials relating to the subject programs and/or the format of the files created or accessed by the subject programs and/or the algorithms used by the subject programs, or any other matter, is current, correct or accurate as delivered. Any risk of damage due to any possible inac- curate information is assumed by the user of the information. Further- more, the information relating to the subject programs and/or the file formats created or accessed by the subject programs and/or the algo- rithms used by the subject programs is subject to change without notice. General Format of a ZIP file ---------------------------- Files stored in arbitrary order. Large zipfiles can span multiple diskette media. Overall zipfile format: [local file header+file data] . . . [central directory] end of central directory record A. Local file header: local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes filename length 2 bytes extra field length 2 bytes filename (variable size) extra field (variable size) B. Central directory structure: [file header] . . . end of central dir record File header: central file header signature 4 bytes (0x02014b50) version made by 2 bytes version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes filename length 2 bytes extra field length 2 bytes file comment length 2 bytes disk number start 2 bytes internal file attributes 2 bytes external file attributes 4 bytes relative offset of local header 4 bytes filename (variable size) extra field (variable size) file comment (variable size) End of central dir record: end of central dir signature 4 bytes (0x06054b50) number of this disk 2 bytes number of the disk with the start of the central directory 2 bytes total number of entries in the central dir on this disk 2 bytes total number of entries in the central dir 2 bytes size of the central directory 4 bytes offset of start of central directory with respect to the starting disk number 4 bytes zipfile comment length 2 bytes zipfile comment (variable size) C. Explanation of fields: version made by The upper byte indicates the host system (OS) for the file. Software can use this information to determine the line record format for text files etc. The cur- rent mappings are: 0 - IBM (MS-DOS) 1 - Amiga 2 - VMS 3 - *nix 4 thru 255 - unused The lower byte indicates the version number of the software used to encode the file. The value/10 indicates the major version number, and the value mod 10 is the minor version number. version needed to extract The minimum software version needed to extract the file, mapped as above. general purpose bit flag: The lowest bit, if set, indicates that the file is encrypted. The upper three bits are reserved and used internally by the software when processing the zipfile. The remaining bits are unused in version 1.0. compression method: (see accompanying documentation for algorithm descriptions) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 date and time fields: The date and time are encoded in standard MS-DOS format. CRC-32: The CRC-32 algorithm was generously contributed by David Schwaderer and can be found in his excellent book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc. The 'magic number' for the CRC is 0xdebb20e3. The proper CRC pre and post conditioning is used, meaning that the CRC register is pre-conditioned with all ones (a starting value of 0xffffffff) and the value is post-conditioned by taking the one's complement of the CRC residual. compressed size: uncompressed size: The size of the file compressed and uncompressed, respectively. filename length: extra field length: file comment length: The length of the filename, extra field, and comment fields respectively. The combined length of any directory record and these three fields should not generally exceed 65,535 bytes. disk number start: The number of the disk on which this file begins. internal file attributes: The lowest bit of this field indicates, if set, that the file is apparently an ASCII or text file. If not set, that the file apparently contains binary data. The remaining bits are unused in version 1.0. external file attributes: The mapping of the external attributes is host- system dependent (see 'version made by'). For MS-DOS, the low order byte is the MS-DOS directory attribute byte. relative offset of local header: This is the offset from the start of the first disk on which this file appears, to where the local header should be found. filename: The name of the file, with optional relative path. The path stored should not contain a drive or device letter, or a leading slash. All slashes should be forward slashes '/' as opposed to back- wards slashes '\' for compatibility with Amiga and Unix file systems etc. extra field: This is for future expansion. If additional in- formation needs to be stored in the future, it should be stored here. Earlier versions of the software can then safely skip this file, and find the next file or header. This field will be 0 length in version 1.0. file comment: The comment for this file. number of this disk: The number of this disk, which contains central directory end record. number of the disk with the start of the central directory: The number of the disk on which the central directory starts. total number of entries in the central dir on this disk: The number of central directory entries on this disk. total number of entries in the central dir: The total number of files in the zipfile. size of the central directory: The size (in bytes) of the entire central directory. offset of start of central directory with respect to the starting disk number: Offset of the start of the central direcory on the disk on which the central directory starts. zipfile comment length: The length of the comment for this zipfile. zipfile comment: The comment for this zipfile. D. General notes: 1) All fields unless otherwise noted are unsigned and stored in Intel low-byte:high-byte, low-word:high-word order. 2) String fields are not null terminated, since the length is given explicitly. 3) Local headers should not span disk boundries. Also, even though the central directory can span disk boundries, no single record in the central directory should be split across disks. 4) The entries in the central directory may not necessarily be in the same order that files appear in the zipfile. UnShrinking ----------- Shrinking is a Dynamic Ziv-Lempel-Welch compression algorithm with par- tial clearing. The initial code size is 9 bits, and the maximum code size is 13 bits. Shrinking differs from conventional Dynamic Ziv-Lempel- Welch implementations in several respects: 1) The code size is controlled by the compressor, and is not auto- matically increased when codes larger than the current code size are created (but not necessarily used). When the decompressor encounters the code sequence 256 (decimal) followed by 1, it should increase the code size read from the input stream to the next bit size. No blocking of the codes is performed, so the next code at the increased size should be read from the input stream immediately after where the previous code at the smaller bit size was read. Again, the decompressor should not increase the code size used until the sequence 256,1 is encountered. 2) When the table becomes full, total clearing is not performed. Rather, when the compresser emits the code sequence 256,2 (deci- mal), the decompressor should clear all leaf nodes from the Ziv-Lempel tree, and continue to use the current code size. The nodes that are cleared from the Ziv-Lempel tree are then re-used with the lowest code value re-used first, and the highest code value re-used last. The compressor can emit the sequence 256,2 at any time. Expanding --------- The Reducing algorithm is actually a combination of two distinct algo- rithms. The first algorithm compresses repeated byte sequences, and the second algorithm takes the compressed stream from the first algorithm and applies a probabilistic compression method. The probabilistic compression stores an array of 'follower sets' S(j), for j=0 to 255, corresponding to each possible ASCII character. Each set contains between 0 and 32 characters, to be denoted as S(j)[0],..., S(j)[m], where m<32. The sets are stored at the beginning of the data area for a Reduced file, in reverse order, with S(255) first, and S(0) last. The sets are encoded as { N(j), S(j)[0],...,S(j)[N(j)-1] }, where N(j) is the size of set S(j). N(j) can be 0, in which case the follower set for S(j) is empty. Each N(j) value is encoded in 6 bits, followed by N(j) eight bit character values corresponding to S(j)[0] to S(j)[N(j)-1] respectively. If N(j) is 0, then no values for S(j) are stored, and the value for N(j-1) immediately follows. Immediately after the follower sets, is the compressed data stream. The compressed data stream can be interpreted for the probabilistic decom- pression as follows: let Last-Character <- 0. loop until done if the follower set S(Last-Character) is empty then read 8 bits from the input stream, and copy this value to the output stream. otherwise if the follower set S(Last-Character) is non-empty then read 1 bit from the input stream. if this bit is not zero then read 8 bits from the input stream, and copy this value to the output stream. otherwise if this bit is zero then read B(N(Last-Character)) bits from the input stream, and assign this value to I. Copy the value of S(Last-Character)[I] to the output stream. assign the last value placed on the output stream to Last-Character. end loop B(N(j)) is defined as the minimal number of bits required to encode the value N(j)-1. The decompressed stream from above can then be expanded to re-create the original file as follows: let State <- 0. loop until done read 8 bits from the input stream into C. case State of 0: if C is not equal to DLE (144 decimal) then copy C to the output stream. otherwise if C is equal to DLE then let State <- 1. 1: if C is non-zero then let V <- C. let Len <- L(V) let State <- F(Len). otherwise if C is zero then copy the value 144 (decimal) to the output stream. let State <- 0 2: let Len <- Len + C let State <- 3. 3: move backwards D(V,C) bytes in the output stream (if this position is before the start of the output stream, then assume that all the data before the start of the output stream is filled with zeros). copy Len+3 bytes from this position to the output stream. let State <- 0. end case end loop The functions F,L, and D are dependent on the 'compression factor' (see FORMAT.DOC), 1 through 4, and are defined as follows: For compression factor 1: L(X) equals the lower 7 bits of X. F(X) equals 2 if X equals 127 otherwise F(X) equals 3. D(X,Y) equals the (upper 1 bit of X) * 256 + Y + 1. For compression factor 2: L(X) equals the lower 6 bits of X. F(X) equals 2 if X equals 63 otherwise F(X) equals 3. D(X,Y) equals the (upper 2 bits of X) * 256 + Y + 1. For compression factor 3: L(X) equals the lower 5 bits of X. F(X) equals 2 if X equals 31 otherwise F(X) equals 3. D(X,Y) equals the (upper 3 bits of X) * 256 + Y + 1. For compression factor 4: L(X) equals the lower 4 bits of X. F(X) equals 2 if X equals 15 otherwise F(X) equals 3. D(X,Y) equals the (upper 4 bits of X) * 256 + Y + 1. -