Python CRC-32灾难

我正在编写一个Python程序，从6gbbz2文件的中间提取数据。bzip2文件由可独立解密的数据块组成，因此我只需要找到一个块（它们由魔术位分隔），然后从内存中创建一个临时的单块bzip2文件，最后将其传递给bz2.decompress函数。简单，不是吗

bzip2在文件末尾有一个crc32校验和。没问题，binascii.crc32去救援。但是等等。要校验和的数据不一定以字节边界结束，crc32函数以整数字节运行

我的计划是：在除最后一个字节外的所有字节上使用binascii.crc32函数，然后使用我自己的函数用最后1–7位更新计算出的crc。但是数小时的编码和测试让我感到困惑，我的困惑可以归结为这样一个问题：为什么crc32（“\x00”）不是0x00000000？根据维基百科的文章，难道不是吗

从0b00000000开始，用32个0填充，然后用0x04C11DB7进行多项式除法，直到前8位没有剩余的值，这将立即生效。最后32位是校验和，怎么可能不全是零呢

---

我在谷歌上搜索了答案，并查看了几个CRC-32实现的代码，但没有找到任何线索说明原因。

除了一次性的

解压

功能外，bz2模块还包含一个类

BZ2Decompressor

，该类在数据输入解压方法时解压数据。因此，它不关心文件末尾的校验和，而是在到达块末尾时提供所需的数据

为了举例说明，假设我已经找到了我希望从文件中提取的块，并将其存储在一个实例中（其他位旋转模块可能也可以工作）。然后此函数将对其进行解码：

def bunzip2_block(block):
    from bz2 import BZ2Decompressor
    from bitarray import bitarray

    dummy_file = bitarray(endian="big")
    dummy_file.frombytes("BZh9")
    dummy_file += block

    decompressor = BZ2Decompressor()
    return decompressor.decompress(dummy_file.tobytes())

请注意，bitarray的

frombytes

和

tobytes

方法以前被称为

fromstring

和

tostring

为什么crc32（“\x00”）不是0x00000000

基本的CRC算法是将输入消息视为GF（2）中的多项式，除以固定的CRC多项式，并使用多项式余数作为结果哈希

CRC-32对基本算法进行了许多修改：

消息的每个字节中的位是反向的。例如，字节0x01被视为多项式x^7，而不是多项式x^0

消息右侧用32个零填充

此反向填充消息的前4个字节与0xFFFFFFFF异或

余数多项式是反向的

余数多项式与0xFFFFFF进行异或运算

回想一下，非反转形式的CRC-32多项式是0x104C11DB7

让我们计算出单字节字符串0x00的CRC-32：

消息：0x00

反向：0x00

填充：0x00

异或：0xFF 00

除以0x104C11DB7时的余数：0x4E 08 BF B4

异或：0xB1 F7 40 4B

反向：0xD2 02 EF 8D

这就是：0x00的CRC-32是0xD202EF8D。

---

（您应该对此进行验证。）

这是否有帮助：不是直接的，不是，因为这涉及块校验和，而不是文件结束校验和。但是问题和更新以及答案都很有趣，很有启发性，所以谢谢你！你能更好地解释第五步的结果吗？0xFFFFFF00%0x104C11DB7不会导致0x4E08BFB4。我也不知道如何使用任何字节反转来获取它。它是。每一位代表一个单项式的系数。