Я выдернул свои волосы с некоторыми несоответствующими значениями CRC-32. Первоначально считал, что это моя собственная реализация C # по вине, но прослеживается через общие проблемы (двоичные файлы против текстовых файлов и т. Д.) И рассматривает реализации Python и zlib. Теперь я думаю, что это что-то тонкое в аппаратной / файловой системе. Следующие результаты оба со следующим Python ...
import binascii
buf = open("my_sample_file.zip","rb").read()
print(len(buf))
print( binascii.crc32(buf) & 0xffffffff )
Первая машина: Ubuntu 18.04.2 LTS. Intel 64 бит. Запуск Python 3.7.3, 64 бита (размер бита подтвержден sys.maxsize).
Это дает длину 6239603497 и CRC 720283681.
Попытка того же скрипта на Windows 10 ПК 64 бит, Intel. Python 3.7.2 64 бит, я получаю длину 6239603497 (хорошо) и CRC 2907064737!
Файл zip распаковывается нормально, а содержимое хорошее.
Так в чем же разница? Насколько я могу судить, оба используют одну и ту же базовую библиотеку zlib. Единственная подсказка в том, что это очень большой файл (около 6 ГБ). Меньшие тесты "hello world", напечатанные вручную, дают тот же результат.
В настоящее время мы думаем о том, чтобы отбросить проверку CRC и заменить ее на более простую контрольную сумму или xor, которую я могу кодировать самостоятельно, и у нее есть другие преимущества (например, загрузка фрагментов может быть предварительно рассчитана и объединена в конце для скорости).