什么是大文件的 python "cksum" 等价物?它是如何工作的?
What is a python "cksum" equivalent for very large files and how does it work?
我有一个问题,我需要在下载后验证巨大的压缩文件(通常每个文件超过 10-20gb),并对照显然是使用 cksum
生成的参考校验和
(更准确地说:我的 python 脚本需要从 ncbi ftp-服务器下载大型压缩文件,该服务器本应提供 md5 校验和来验证下载,但实际上只提供了一些不同的未指定 filehash/checksum 值。经过反复试验,我发现这些校验和与 unix 工具 cksum
的输出相同,后者显然会生成 CRC 校验和。因此 compare/validate 这些我需要为下载的文件生成 cksum
等价的校验和。)
看来 unix 工具 cksum
产生的校验和值与假定的等效 unix 工具 crc32
(或 python zlib.crc32()
函数,就此而言).在谷歌搜索问题时,我无法理解为什么会发生这种情况的解释,特别是因为它们在某些系统上看起来是相同的?所以也许这是因为我在 64 位系统上工作(但是现在:谁不这样做)?
使用内置的 python 模块,我可以轻松生成 md5 和 CRC32 校验和,但其中 none 等同于校验和输出,既不是十进制也不是十六进制表示形式。
我发现 a previous post here on Whosebug pointing to a snippet 似乎可以解决这个问题。但是虽然它适用于小文件,A.) 我一个字都听不懂,所以我很难适应它 B.) 它似乎不适用于大文件。
为了完整起见:这里是片段(python3 版本):
#!/usr/bin/env python
import sys
crctab = [ 0x00000000, 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc,
0x17c56b6b, 0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f,
0x2f8ad6d6, 0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a,
0x384fbdbd, 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9,
0x5f15adac, 0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8,
0x6ed82b7f, 0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3,
0x709f7b7a, 0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e,
0x95609039, 0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5,
0xbe2b5b58, 0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84,
0xa9ee3033, 0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027,
0xddb056fe, 0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022,
0xca753d95, 0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1,
0xe13ef6f4, 0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077,
0x30476dc0, 0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c,
0x2e003dc5, 0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1,
0x1fcdbb16, 0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca,
0x7897ab07, 0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb,
0x6f52c06c, 0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08,
0x571d7dd1, 0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d,
0x40d816ba, 0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e,
0xbfa1b04b, 0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f,
0x8e6c3698, 0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044,
0x902b669d, 0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689,
0xedf73b3e, 0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2,
0xc6bcf05f, 0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683,
0xd1799b34, 0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59,
0x608edb80, 0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c,
0x774bb0eb, 0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f,
0x5c007b8a, 0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e,
0x21dc2629, 0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5,
0x3f9b762c, 0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48,
0x0e56f0ff, 0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623,
0xf12f560e, 0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2,
0xe6ea3d65, 0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601,
0xdea580d8, 0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604,
0xc960ebb3, 0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7,
0xae3afba2, 0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6,
0x9ff77d71, 0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad,
0x81b02d74, 0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7,
0x50c9b640, 0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c,
0x7b827d21, 0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd,
0x6c47164a, 0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e,
0x18197087, 0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b,
0x0fdc1bec, 0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088,
0x2497d08d, 0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679,
0xc1683bce, 0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12,
0xdf2f6bcb, 0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af,
0xeee2ed18, 0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4,
0x89b8fd09, 0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5,
0x9e7d9662, 0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06,
0xa6322bdf, 0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03,
0xb1f740b4 ]
UNSIGNED = lambda n: n & 0xffffffff
def memcrc(b):
n = len(b)
i = c = s = 0
for c in b:
tabidx = (s>>24)^c
s = UNSIGNED((s << 8)) ^ crctab[tabidx]
while n:
c = n & 0o0377
n = n >> 8
s = UNSIGNED(s << 8) ^ crctab[(s >> 24) ^ c]
return UNSIGNED(~s)
if __name__ == '__main__':
fname = sys.argv[-1]
buffer = open(fname, 'rb').read()
print("%d\t%d\t%s" % (memcrc(buffer), len(buffer), fname))
有人能帮我理解一下吗?
cksum
和crc32
的区别究竟是什么问题?
- 仅仅是一个基于 32 位而另一个基于 64 位的事实吗?
- 我可以简单地在两者产生的值之间进行转换吗?如果可以,如何转换?
- 上面代码段中 crctab 的用途是什么?转换是如何进行的?
我已经尝试将您的代码重构为 class,遵循与标准 Python Python hashlib
:
类似的 api
class crc32:
def __init__(self):
self.nchars = 0
self.crc = 0
def update(self, buf):
crc = self.crc
for c in buf:
crc = crctab[(crc >> 24) ^ c] ^ ((crc << 8) & 0xffffffff)
self.crc = crc
self.nchars += len(buf)
def digest(self):
crc = self.crc
n = self.nchars
while n:
c = n & 0xff
crc = crctab[(crc >> 24) ^ c] ^ ((crc << 8) & 0xffffffff)
n >>= 8
return UNSIGNED(~crc)
我扩展了 UNSIGNED
以尝试使其更快,并对一些语句进行了重新排序,使其更类似于标准 zlib library(由 Python 使用),同时我试图了解其中的差异。似乎他们使用不同的多项式来生成 table,但其他方面是相同的。
以上代码可以用作:
with open('largefile', 'rb') as fd:
digest = crc32()
while buf := fd.read(4096):
digest.update(buf)
print(digest.digest())
它为以下创建的文件打印出预期的 1135714720:
echo -n hello world > test.txt
以上代码应该适用于大文件,但考虑到 Python 的性能,这将花费太长时间而无法使用。我有一个 75MB 的文件需要大约 11 秒,而 cksum
只需要大约 0.2 秒。您应该能够使用 Cython 来加快速度,但这有点麻烦,如果您正在努力使用现有代码,那将是一个相当大的学习曲线!
我用 Cython 进行了另一场比赛并获得了与 cksum
相似的性能,代码如下所示:
cdef unsigned int *crctab_c = [
// copy/paste crctab from above
]
cdef class crc32_c:
cdef unsigned int crc, nchars
def __init__(self):
self.nchars = 0
self.crc = 0
cdef _update(self, bytes buf):
cdef unsigned int crc, i, j
cdef unsigned char c
crc = self.crc
for c in buf:
i = (crc >> 24) ^ c
j = crc << 8
crc = crctab_c[i] ^ j
self.crc = crc
self.nchars += len(buf)
def update(self, buf):
return self._update(buf)
def digest(self):
crc = self.crc
n = self.nchars
while n:
c = n & 0xff
crc = crctab_c[(crc >> 24) ^ c] ^ ((crc << 8) & 0xffffffff)
n >>= 8
return (~crc) & 0xffffffff
这段代码用Cython编译后,可以像前面的class一样使用。性能非常好:Python 现在处理一个 75MiB 的文件需要大约 200 毫秒,与 cksum
基本相同,但比只需要大约 80 毫秒的 zlib 慢得多。
我不知道你问题的原因部分。我只能说,标准的伟大之处在于你有很多选择。
cksum 由 POSIX 指定使用与您在 zlib 中找到的更常见的 CRC-32 不同的 CRC,Python,用于 zip 和 gzip 文件等。CRC-32/CKSUM 有这个规范(来自 Greg Cook's CRC catalog):
width=32 poly=0x04c11db7 init=0x00000000 refin=false refout=false xorout=0xffffffff check=0x765e7680 residue=0xc704dd7b name="CRC-32/CKSUM"
比较常见的CRC-32有这样的规范:
width=32 poly=0x04c11db7 init=0xffffffff refin=true refout=true xorout=0xffffffff check=0xcbf43926 residue=0xdebb20e3 name="CRC-32/ISO-HDLC"
我的系统 (macOS) 上的 cksum 实用程序计算 CRC-32/CKSUM,但它 也 有计算 CRC-32/ISO_HDLC 的选项,以及两个其他实际校验和,第一个来自 BSD Unix sum 命令,第二个来自 AT&T System V Unix sum 命令。
cksum 可能产生的结果显然不缺。
不,这与 32 位系统和 64 位系统无关。
不,您不能在值之间进行转换。
table的目的是通过预先计算每个字节值的 CRC 来加速 CRC 计算。
我有一个问题,我需要在下载后验证巨大的压缩文件(通常每个文件超过 10-20gb),并对照显然是使用 cksum
生成的参考校验和(更准确地说:我的 python 脚本需要从 ncbi ftp-服务器下载大型压缩文件,该服务器本应提供 md5 校验和来验证下载,但实际上只提供了一些不同的未指定 filehash/checksum 值。经过反复试验,我发现这些校验和与 unix 工具 cksum
的输出相同,后者显然会生成 CRC 校验和。因此 compare/validate 这些我需要为下载的文件生成 cksum
等价的校验和。)
看来 unix 工具 cksum
产生的校验和值与假定的等效 unix 工具 crc32
(或 python zlib.crc32()
函数,就此而言).在谷歌搜索问题时,我无法理解为什么会发生这种情况的解释,特别是因为它们在某些系统上看起来是相同的?所以也许这是因为我在 64 位系统上工作(但是现在:谁不这样做)?
使用内置的 python 模块,我可以轻松生成 md5 和 CRC32 校验和,但其中 none 等同于校验和输出,既不是十进制也不是十六进制表示形式。
我发现 a previous post here on Whosebug pointing to a snippet 似乎可以解决这个问题。但是虽然它适用于小文件,A.) 我一个字都听不懂,所以我很难适应它 B.) 它似乎不适用于大文件。
为了完整起见:这里是片段(python3 版本):
#!/usr/bin/env python
import sys
crctab = [ 0x00000000, 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc,
0x17c56b6b, 0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f,
0x2f8ad6d6, 0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a,
0x384fbdbd, 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9,
0x5f15adac, 0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8,
0x6ed82b7f, 0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3,
0x709f7b7a, 0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e,
0x95609039, 0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5,
0xbe2b5b58, 0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84,
0xa9ee3033, 0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027,
0xddb056fe, 0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022,
0xca753d95, 0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1,
0xe13ef6f4, 0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077,
0x30476dc0, 0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c,
0x2e003dc5, 0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1,
0x1fcdbb16, 0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca,
0x7897ab07, 0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb,
0x6f52c06c, 0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08,
0x571d7dd1, 0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d,
0x40d816ba, 0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e,
0xbfa1b04b, 0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f,
0x8e6c3698, 0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044,
0x902b669d, 0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689,
0xedf73b3e, 0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2,
0xc6bcf05f, 0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683,
0xd1799b34, 0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59,
0x608edb80, 0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c,
0x774bb0eb, 0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f,
0x5c007b8a, 0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e,
0x21dc2629, 0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5,
0x3f9b762c, 0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48,
0x0e56f0ff, 0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623,
0xf12f560e, 0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2,
0xe6ea3d65, 0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601,
0xdea580d8, 0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604,
0xc960ebb3, 0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7,
0xae3afba2, 0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6,
0x9ff77d71, 0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad,
0x81b02d74, 0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7,
0x50c9b640, 0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c,
0x7b827d21, 0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd,
0x6c47164a, 0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e,
0x18197087, 0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b,
0x0fdc1bec, 0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088,
0x2497d08d, 0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679,
0xc1683bce, 0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12,
0xdf2f6bcb, 0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af,
0xeee2ed18, 0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4,
0x89b8fd09, 0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5,
0x9e7d9662, 0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06,
0xa6322bdf, 0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03,
0xb1f740b4 ]
UNSIGNED = lambda n: n & 0xffffffff
def memcrc(b):
n = len(b)
i = c = s = 0
for c in b:
tabidx = (s>>24)^c
s = UNSIGNED((s << 8)) ^ crctab[tabidx]
while n:
c = n & 0o0377
n = n >> 8
s = UNSIGNED(s << 8) ^ crctab[(s >> 24) ^ c]
return UNSIGNED(~s)
if __name__ == '__main__':
fname = sys.argv[-1]
buffer = open(fname, 'rb').read()
print("%d\t%d\t%s" % (memcrc(buffer), len(buffer), fname))
有人能帮我理解一下吗?
cksum
和crc32
的区别究竟是什么问题?- 仅仅是一个基于 32 位而另一个基于 64 位的事实吗?
- 我可以简单地在两者产生的值之间进行转换吗?如果可以,如何转换?
- 上面代码段中 crctab 的用途是什么?转换是如何进行的?
我已经尝试将您的代码重构为 class,遵循与标准 Python Python hashlib
:
class crc32:
def __init__(self):
self.nchars = 0
self.crc = 0
def update(self, buf):
crc = self.crc
for c in buf:
crc = crctab[(crc >> 24) ^ c] ^ ((crc << 8) & 0xffffffff)
self.crc = crc
self.nchars += len(buf)
def digest(self):
crc = self.crc
n = self.nchars
while n:
c = n & 0xff
crc = crctab[(crc >> 24) ^ c] ^ ((crc << 8) & 0xffffffff)
n >>= 8
return UNSIGNED(~crc)
我扩展了 UNSIGNED
以尝试使其更快,并对一些语句进行了重新排序,使其更类似于标准 zlib library(由 Python 使用),同时我试图了解其中的差异。似乎他们使用不同的多项式来生成 table,但其他方面是相同的。
以上代码可以用作:
with open('largefile', 'rb') as fd:
digest = crc32()
while buf := fd.read(4096):
digest.update(buf)
print(digest.digest())
它为以下创建的文件打印出预期的 1135714720:
echo -n hello world > test.txt
以上代码应该适用于大文件,但考虑到 Python 的性能,这将花费太长时间而无法使用。我有一个 75MB 的文件需要大约 11 秒,而 cksum
只需要大约 0.2 秒。您应该能够使用 Cython 来加快速度,但这有点麻烦,如果您正在努力使用现有代码,那将是一个相当大的学习曲线!
我用 Cython 进行了另一场比赛并获得了与 cksum
相似的性能,代码如下所示:
cdef unsigned int *crctab_c = [
// copy/paste crctab from above
]
cdef class crc32_c:
cdef unsigned int crc, nchars
def __init__(self):
self.nchars = 0
self.crc = 0
cdef _update(self, bytes buf):
cdef unsigned int crc, i, j
cdef unsigned char c
crc = self.crc
for c in buf:
i = (crc >> 24) ^ c
j = crc << 8
crc = crctab_c[i] ^ j
self.crc = crc
self.nchars += len(buf)
def update(self, buf):
return self._update(buf)
def digest(self):
crc = self.crc
n = self.nchars
while n:
c = n & 0xff
crc = crctab_c[(crc >> 24) ^ c] ^ ((crc << 8) & 0xffffffff)
n >>= 8
return (~crc) & 0xffffffff
这段代码用Cython编译后,可以像前面的class一样使用。性能非常好:Python 现在处理一个 75MiB 的文件需要大约 200 毫秒,与 cksum
基本相同,但比只需要大约 80 毫秒的 zlib 慢得多。
我不知道你问题的原因部分。我只能说,标准的伟大之处在于你有很多选择。
cksum 由 POSIX 指定使用与您在 zlib 中找到的更常见的 CRC-32 不同的 CRC,Python,用于 zip 和 gzip 文件等。CRC-32/CKSUM 有这个规范(来自 Greg Cook's CRC catalog):
width=32 poly=0x04c11db7 init=0x00000000 refin=false refout=false xorout=0xffffffff check=0x765e7680 residue=0xc704dd7b name="CRC-32/CKSUM"
比较常见的CRC-32有这样的规范:
width=32 poly=0x04c11db7 init=0xffffffff refin=true refout=true xorout=0xffffffff check=0xcbf43926 residue=0xdebb20e3 name="CRC-32/ISO-HDLC"
我的系统 (macOS) 上的 cksum 实用程序计算 CRC-32/CKSUM,但它 也 有计算 CRC-32/ISO_HDLC 的选项,以及两个其他实际校验和,第一个来自 BSD Unix sum 命令,第二个来自 AT&T System V Unix sum 命令。
cksum 可能产生的结果显然不缺。
不,这与 32 位系统和 64 位系统无关。
不,您不能在值之间进行转换。
table的目的是通过预先计算每个字节值的 CRC 来加速 CRC 计算。