如何验证 Zip 文件的 CRC-32 计算答案

【问题标题】：How to validate CRC-32 calculation of Zip file如何验证 Zip 文件的 CRC-32 计算
【发布时间】：2020-12-18 04:54:20
【问题描述】：

我想验证我的 ZIP 文件是否具有正确的 CRC-32 校验和。
我读到在 ZIP 文件中，CRC-32 数据在字节 14 到 17 中：

Offset  Bytes   Description[30]
0        4  Local file header signature = 0x04034b50 (read as a little-endian number)
4        2  Version needed to extract (minimum)
6        2  General purpose bit flag
8        2  Compression method
10       2  File last modification time
12       2  File last modification date
14       4  CRC-32 of uncompressed data
18       4  Compressed size
22       4  Uncompressed size
26       2  File name length (n)
28       2  Extra field length (m)
30       n  File name
30+n     m  Extra field

我想验证我创建的一个简单 ZIP 文件的 CRC-32 校验和：

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
50 4B 03 04 14 00 00 00 00 00 38 81 1C 51 4C 18  | PK........8..QL.
C7 8C 02 00 00 00 02 00 00 00 07 00 00 00 31 32  | ÇŒ............12
33 2E 64 61 74 73 73 50 4B 01 02 14 00 14 00 00  | 3.datssPK.......
00 00 00 38 81 1C 51 4C 18 C7 8C 02 00 00 00 02  | ...8..QL.ÇŒ.....
00 00 00 07 00 00 00 00 00 00 00 01 00 20 00 00  | ............. ..
00 00 00 00 00 31 32 33 2E 64 61 74 50 4B 05 06  | .....123.datPK..
00 00 00 00 01 00 01 00 35 00 00 00 27 00 00 00  | ........5...'...
00 00                                            | ..

CRC-32 是：0x4C18C78C
我去了thisCRC-32在线计算器并从文件中添加了以下未压缩的行：

50 4B 03 04 14 00 00 00 00 00 38 81 1C 51

这是结果：

Algorithm           Result      Check       Poly            Init        RefIn   RefOut  XorOut     
CRC-32              0x6A858174  0xCBF43926  0x04C11DB7  0xFFFFFFFF      true    true    0xFFFFFFFF
CRC-32/BZIP2        0xE3FA1205  0xFC891918  0x04C11DB7  0xFFFFFFFF      false   false   0xFFFFFFFF
CRC-32C             0xB578110E  0xE3069283  0x1EDC6F41  0xFFFFFFFF      true    true    0xFFFFFFFF
CRC-32D             0xAFE2EEA4  0x87315576  0xA833982B  0xFFFFFFFF      true    true    0xFFFFFFFF
CRC-32/MPEG-2       0x1C05EDFA  0x0376E6E7  0x04C11DB7  0xFFFFFFFF      false   false   0x00000000
CRC-32/POSIX        0xFF9B3071  0x765E7680  0x04C11DB7  0x00000000      false   false   0xFFFFFFFF
CRC-32Q             0x79334F11  0x3010BF7F  0x814141AB  0x00000000      false   false   0x00000000
CRC-32/JAMCRC       0x957A7E8B  0x340BC6D9  0x04C11DB7  0xFFFFFFFF      true    true    0x00000000
CRC-32/XFER         0xA7F36A3F  0xBD0BE338  0x000000AF  0x00000000      false   false   0x00000000

但它们都不等于：0x4C18C78C。

我做错了什么？ ZIP的CRC-32是之前所有字节（0-13）的计算，不是吗？

【问题讨论】：

您可以只使用unzip -t whatever.zip，它会检查文件中每个 zip 条目的 CRC。

标签： zip checksum zipfile crc crc32

【解决方案1】：

我能够创建一个与问题中的文件匹配的 zip 文件。头显示压缩类型== 0，表示不压缩，未压缩大小== 2，数据== {73 73}。 CRC32采用反射输入输出，CRC以little endian格式存储，所以CRC == 0x8CC7184C。

我使用这个在线 CRC 计算器使用 CRC32 对 {73 73} 的数据进行匹配：

http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

【讨论】：

【解决方案2】：

您针对在线 CRC 计算器运行的字节序列不是未压缩的字节。

50 4B 03 04 14 00 00 00 00 00 38 81 1C 51

这些字节是 zip 文件的前几个字节。 zip 中的 CRC32 值是通过针对完整的未压缩负载运行 CRC32 算法来计算的。在您的情况下，有效负载是两个字节序列“ss”。

为了解决这个问题，我将您的十六进制转储转换回压缩文件 tmp.zip。它包含一个成员123.dat

$ unzip -lv tmp.zip 
Archive:  tmp.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       2  Stored        2   0% 2020-08-28 16:09 8cc7184c  123.dat
--------          -------  ---                            -------
       2                2   0%                            1 file

当我通过 hexdump 将该成员提取到标准输出和管道时，我们发现它包含两个字节字符串“ss”（十六进制 73 73）

$ unzip -p tmp.zip | hexdump -C
00000000  73 73                                             |ss|

最后，正如另一条评论中已经提到的，您可以通过运行unzip -t 来检查 CRC 值是否正确

$ unzip -t tmp.zip 
Archive:  tmp.zip
    testing: 123.dat                  OK
No errors detected in compressed data of tmp.zip.

【讨论】：

你怎么知道“ss”是未压缩的数据？
您提供了 zip 文件（十六进制）。如果您提取第一个也是唯一一个条目，您会得到“ss”。