Python解析ZIP文件：识别十六进制数据及对应字段的技术问询

Hey there! I get it—digging through the PKWARE spec can feel like decoding a secret message at first, especially when you’re trying to map every hex byte to its actual purpose. Let’s break this down step by step for the ZIP local file header, since that’s where you started.

Here’s a byte-by-byte breakdown of each field in the local file header, so you can match those hex values to their real-world meaning:

• Local file header signature (4 bytes): Starts with 0x504B0304 (hex for "PK\x03\x04")—this is your clear marker for the start of a local file entry.
• Version needed to extract (2 bytes): Tells you the minimum ZIP version required to unpack this file. For example, 0x0A00 translates to version 10 (decimal), which supports ZIP64 for handling files larger than 4GB.
• General purpose bit flag (2 bytes): A set of binary flags that signal specific features. For instance, if bit 11 is set (value 0x0800), the filename uses UTF-8 encoding instead of ASCII; bit 0 being set means the file is encrypted.
• Compression method (2 bytes): Defines how the file was compressed. 0x0000 means no compression at all, while 0x0800 is the widely used DEFLATE method.
• Last modification time (2 bytes): Stored in a DOS timestamp format: split into 5 bits for hours, 6 for minutes, and 5 for seconds (note: seconds are multiplied by 2, so you’ll need to divide by 2 to get the actual value).
• Last modification date (2 bytes): DOS date format: 7 bits for year (offset by 1980, so add 1980 to the decimal value), 4 bits for month, and 5 bits for day.
• CRC-32 (4 bytes): A checksum of the uncompressed file data—you can use this to verify the file hasn’t been corrupted after extraction.
• Compressed size (4 bytes): The size of the file after compression. If this value is 0xFFFFFFFF, it means the actual size is stored in the ZIP64 extra field (for files exceeding the 4GB limit of 4-byte integers).
• Uncompressed size (4 bytes): The size of the file when fully uncompressed. Again, 0xFFFFFFFF points to the ZIP64 extension for large files.
• Filename length (2 bytes): The number of bytes in the filename that immediately follows the header.
• Extra field length (2 bytes): The number of bytes in the optional extra field, which holds extended data like ZIP64 sizes, Unix timestamps, or custom metadata.
• Filename (variable length): The actual name of the file—its encoding depends on the general purpose bit flag (either ASCII or UTF-8).
• Extra field (variable length): Contains optional, structured data. For ZIP64 support, look for the tag 0x0001 followed by 8-byte values for compressed and uncompressed sizes.

A quick practical tip: Grab a hex editor (like HxD or 010 Editor) and load a sample ZIP file. Once you spot the 0x504B0304 signature, count out the bytes one segment at a time—this hands-on approach makes the dense spec click way faster than just reading it.

I totally get why the PKWARE doc feels overwhelming at first; it’s written for low-level implementers, not casual learners. Tackling one section (like the local file header) before moving to central directories or the end-of-file record will make it much more manageable.

内容的提问来源于stack exchange，提问作者Aamir Shaikh