在尝试分析 zip 文件时,我有点困惑的一个部分是Zip64 Extra Information Field
.当特定字段无法放入文件头(中央目录或本地)时,预计会生成该文件,因此我们在文件头中插入 0xffffffff 并将实际值放在额外信息字段中。
根据文档这里,这可以作为结构后面的额外字段之一找到:
Value Size Description
----- ---- -----------
(ZIP64) 0x0001 2 bytes Tag for this "extra" block type
Size 2 bytes Size of this "extra" block
Original
Size 8 bytes Original uncompressed file size
Compressed
Size 8 bytes Size of compressed data
Relative Header
Offset 8 bytes Offset of local header record
Disk Start
Number 4 bytes Number of the disk on which
this file starts
这意味着我应该期望扩展信息条目大小始终为 28 字节。
然而,在分析实际的 Zip64 存档时,我发现一个中央目录条目的文件偏移量为 0xffffffff。下一步是在额外数据字段中查找 0x0001 header-id(预计数据大小为 28 字节)。
然而,我发现00 01 00 08 00 36 d4 6b ab 02 00 00 00
(转换为 0x0001 header-id、8 个字节大小和 1 个值为 0x02ab6bd436 的字段)正确地表示了本地文件头偏移量。为什么文档中没有提到其他字段Zip64 Extra Information Field
?我正在使用Linux 机器上可用的
标准实用程序。zip
答案1
我确信您不再需要答案,而是为了未来的读者。根据规范,64 个额外的块字段仅应在需要时出现:
4.5.3 -Zip64 Extended Information Extra Field (0x0001):
The following is the layout of the zip64 extended
information "extra" block. If one of the size or
offset fields in the Local or Central directory
record is too small to hold the required data,
a Zip64 extended information record is created.
The order of the fields in the zip64 extended
information record is fixed, but the fields MUST
only appear if the corresponding Local or Central
directory record field is set to 0xFFFF or 0xFFFFFFFF.
Note: all fields stored in Intel low-byte/high-byte order.
Value Size Description
----- ---- -----------
(ZIP64) 0x0001 2 bytes Tag for this "extra" block type
Size 2 bytes Size of this "extra" block
Original
Size 8 bytes Original uncompressed file size
Compressed
Size 8 bytes Size of compressed data
Relative Header
Offset 8 bytes Offset of local header record
Disk Start
Number 4 bytes Number of the disk on which
this file starts
因此,只有那些在本地/中央目录记录中标记为 0xFFFF 或 0xFFFFFFFF 的内容才应该出现在 64 额外块中。
在您提到的情况下,必须正确通知其余字段(未压缩、压缩和磁盘)并从本地/中央读取。