我正在编写一个Python程序,用于从6 GB bz2文件的中间提取数据.bzip2文件由独立可解密的数据块组成,所以我只需要找到一个块(它们由魔术位分隔),然后在内存中创建一个临时的一块bzip2文件,最后将其传递给bz2.decompress函数.容易,不是吗？
bzip2 格式最后有一个文件的crc32校验和.没问题,binascii.crc32来救援.可是等等.要校验和的数据不一定以字节边界结束,而crc32函数在整数个字节上运行.
我的计划:在除最后一个字节之外的所有字节上使用binascii.crc32函数,然后使用我自己的函数来更新最后1-7位的计算crc.但是数小时的编码和测试让我感到困惑,我的困惑可以归结为这个问题:为什么crc32("\ x00")不是0x00000000？根据维基百科的文章,它应该不是吗？
你从0b00000000开始,用32 0填充,然后用0x04C11DB7进行多项式除法,直到前8位没有剩下的,这是立即的.你的最后32位是校验和,怎么能不是全零？
我搜索了Google的答案并查看了几个CRC-32实现的代码,却没有找到任何关于为什么会这样做的线索.
我正在尝试在 Python 中使用zlib中的crc32_combine函数。尽管可以使用各种其他 zlib 函数，但该函数不是“包含电池”标准库的一部分。我尝试了两种方法：从 C 代码到 Python 的端口和从 Python 调用 zlib 与 ctypes。两者都给了我不同的结果，尽管不是我期望的结果。我正在展示 ctypes 代码，因为我认为它执行得更快，并且出现其他程序员错误的可能性更小。
当提供第二个散列的数据长度时，该算法可以组合两个CRC32散列。crc32_combine定义如下：
crc32(crc32(0, seq1, len1), seq2, len2) == crc32_combine(
crc32(0, seq1, len1), crc32(0, seq2, len2), len2)
这是输出：
Expected CRC: 45E57586
Combined CRC: 567EE4E4
在 win32 上使用 Python 3.5.1 运行时，第二行总是不同的。不是 Python 2，但结果也不是我所期望的。将zlib1.dll放在与脚本相同的目录中进行尝试。
import zlib
def crc32_combine_ctypes(crc1, crc2, len2):
import ctypes
from ctypes import util
lib = util.find_library('zlib1')
_zlib = ctypes.CDLL(lib)
assert _zlib._name, "Can't find zlib"
_zlib.crc32_combine.argtypes …