See more on Chunks in general.
This is a “Table Of Contents”, used to make skimming a zip2 file faster. Consider a program that skims the entire zip2 file, noting the position and header information of each chunk. This is easy to do, but causes a lot of seeks, going through the entire file. Seeking is slow on some media such as CD”s, and that is also a prime potential usage of zip2 files. Similarly, a remote file can generate many round trips over the network to seek and read a little bit at a time.
To prevent the need for skimming the entire file, the TOCN chunk may be used. This contains the header information (type and instance) plus the offset of each chunk. When skimming, the program can stop skimming when it sees the TOCN, and simply use the information contained within it instead. Furthermore, the offset of the TOCN chunk can be mentioned in the non-chunk header of the file, providing immedate access to it without searching.
The d (redundant) Flag must be set. All other flags must be cleared. So, there can be no payload specification, no continuation, etc.
The Instance Number must be 0. There is only one instance per archive file (in a multi-part archive, each portion file can have its own).
The Payload contains a record for each chunk in the file (the TOCN chunk itself may be omitted, but all other chunks other than XXXX shall be listed), in ascending order of their apparance in the archive file.
Each record contains:
This is the 2-byte Type tag of the chunk, the Subtype (if present), the Instance Number, the Instance Rage (if present), and the Part Number (if present) copied from the chunk header.
A uintV that holds the delta of the noted chunk’s offset. This value is added to the offset noted in the previous record to form the offset for this record.
Delta encoding is used rather than recording the offsets directly because the numbers will tend to be smaller and thus encode in shorter forms.
Page content copyright 2003 by John M. Dlugosz. Home:http://www.dlugosz.com, email:mailto:email@example.com