Although the generated code is very useful...
This is wrong. It treats the ZIP format as if (à la PNG) it's a concatenated series of records/chunks marked by ZIP's characteristic, "PK" off-set, 4-byte magic numbers. It isn't. The only way to read a ZIP bytestream is to start from the end, look for the signature that denotes the possibility of the presence at the current byte offset the record containing the central directory metadata, proceeding to validate* the file based on that, and then operating on it appropriately. (* If validation fails, you can continue scanning backwards from the offset that was thought to be the signature.)
The first passed validation attempt carried out in this manner (from back to front) "wins"—there may be more than one validation passes beginning at various offsets that succeed, but only the one that appears nearest to the end of the bytestream is authoritative. If one or more validation attempts fail resulting in no successes, the file may be corrupt, and the implementation may attempt to "repair" it (not necessarily by making on-disk modifications, but merely by being generous with its interpretation of the bytestream—perhaps presenting several different options to the user), or, alternatively, it may be the case that the file is simply not a ZIP archive.
This is because a ZIP file is permitted to have its records be little embedded "data islands" (in a sea of unrelated bytes). This is what allows spanned/multi-disk archives and for the ZIP to be modified by updating the bytestream in an append-only way (or selectively rubbing out parts of the existing central directory and updating the pointers/offsets in-place). It's also what allows self-extracting archives to be self-extracting: foremost, they conform to the binary executable format and include code for being able to open the very same executable, process the records embedded within it, and write them to disk.