☰

为什么 crc32 说我的某些文件是“BAD”？

tag-icon • tag-icon filenames checksum
为什么 crc32 说我的某些文件是“BAD”？

我曾经crc32将一些文件与它们的备份进行比较。在 3556 个文件中，有 11 个被报告为“BAD”，如下例所示：

9be46354        ./9836Feeding_the_dog_.mpeg   BAD 9be46354 != 9836Feed

但是，这些文件是不是不好，但由于某种原因crc32将其计算的校验和与文件名的一部分进行了比较。

然后我尝试了一个实验：

$ echo 12345 > 9836Feeding_the_dog_.mpeg
$ crc32 9836Feeding_the_dog_.mpeg
261dafe6

所以这次crc32似乎没有将校验和与文件名进行比较，并且该文件不是“BAD”。

这里发生了什么？其他校验和也会发生这种情况吗？

答案1

crc32您使用的可执行文件是与 Perl 模块一起分发的 Perl脚本Archive::Zip。

Perlcrc32脚本非常短，其中包含以下小内容：

if ( $file =~ /[^[:xdigit:]]([[:xdigit:]]{8})[^[:xdigit:]]/ ) {
    my $filenameCrc = $1;
    if ( lc($filenameCrc) eq lc($fileCrc) ) {
        print("\tOK")
    } else {
        print("\tBAD $fileCrc != $filenameCrc");
    }
}

那是，如果文件的路径名包含八个连续的十六进制数字，前后至少有一个非十六进制数字，这个十六进制数与文件的 CRC32 校验和进行比较。

就您而言，您正在crc32运行./9836Feeding_the_dog_.mpeg。该路径名包含一些非十六进制数字 ( ./)，后跟正好八个十六进制数字 ( 9836Feed)，然后又是一些非十六进制数字。 9836Feed不是文件的 CRC32 校验和，因此它会抱怨。

触发此“不错”行为的示例：

$ cat 261dafe6_file
12345
$ crc32 ./261dafe6_file
261dafe6        OK

重新创建测试，并通过./在文件路径名前面添加来引发“BAD”响应：

$ echo 12345 >9836Feeding_the_dog_.mpeg
$ crc32 9836Feeding_the_dog_.mpeg
261dafe6

$ crc32 ./9836Feeding_the_dog_.mpeg
261dafe6        BAD 261dafe6 != 9836Feed

由于crc32可执行文件没有文档记录，显然有点古怪，并且没有广泛使用（我不知道它并且不得不追踪它，但这可能没什么意义）我建议使用其他一些工具来计算文件的校验和。 GNU coreutils 的工具md5sum被广泛使用，在 BSD 系统上您可以使用md5.还有一些实用程序用于计算更强的哈希值（SHA1、SHA256 和 SHA512 以及其他可用实用程序支持）。

（“非十六进制数字”是指“不是十六进制数字的东西”）

相关内容