问题描述
我过去与CRC-16校验和有过联系，习惯于通过对要验证的文件以及CRC-16本身的2个字节重新计算CRC-16校验和来进行验证.如果结果为零，则文件完整性有效，否则无效.
I had some contact with the CRC-16 checksum in the past and was accustomed to verifying it by recalculating the CRC-16 checksum over the file I want to verify, plus the 2 bytes of the CRC-16 itself.If the result was zero, then the file integrity was valid, otherwise not.
这可以像下面的伪C一样非常有效地编码:
This can be coded very efficiently like with the following pseudo-C:
如果(recalculated_crc16_checksum！= 0)//错误:文件完整性已损坏别的//成功:文件完整性有效
我最近想使用CRC-32校验和进行文件完整性检查，并尝试以相同的方式进行验证，但是在这里似乎无法使用"Compare-Against-Zero-Trick"吗?！
I recently wanted to use the CRC-32 checksum for a file integrity check and tried to verify it the same way, but it seems like this "Compare-Against-Zero-Trick" is not possible here?!
例如，如果我在CRC在线计算器上使用32位值0xDEADBEEF:
For example if I use the 32-Bit value 0xDEADBEEF on the CRC online calculator:
CRC-16-Modbus(0xDEADBEEF)= 0xC19B(相同的输入值，但以相反的字节顺序附加了校验和0xC19B)CRC-16-Modbus(0xDEADBEEF9BC1)= 0x0000
但是:
CRC-32(0xDEADBEEF)= 0x7C9CA35A(我尝试过:附加校验和的大小字节序)CRC-32(0xDEADBEEF7C9CA35A)= 0x01F92292！= 0x00000000CRC-32(0xDEADBEEF5AA39C7C)= 0x2144DF1C！= 0x00000000
有人可以向我解释一下，为什么这个比较-零-特技"不适用于CRC-32吗?
Can someone please explain me, why this "Compare-Against-Zero-Trick" does not work for CRC-32?
推荐答案
问题不是CRC是32位，而是CRC是后补码的xorout = 0xffffffff.如果将CRC(小尾数)附加到消息中，然后再次计算CRC，如果没有错误，则CRC始终为0x2144DF1C.因此，在这种情况下，您需要针对0x2144DF1C验证CRC.
The issue is not that the CRC is 32 bit, but that the CRC is post-complemented, xorout = 0xffffffff. If you append the CRC (little endian), to the message and then compute the CRC again, if there are no errors, the CRC will always be 0x2144DF1C. So in this case you verify the CRC against 0x2144DF1C.
这个在线CRC计算器可能会提供更多信息，因为它显示了以下参数:多项式，xorin，xorout.
You might find this online CRC calculator a bit more informative, since it shows the parameters: polynomial, xorin, xorout.
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
要说明情况，通常，如果您计算并在消息中附加非互补的CRC，然后计算消息的CRC + CRC，则得到的CRC为零(如果没有错误).设CRC32X =初始值= 0且xorout = 0的自定义CRC32.您可以使用我发布的链接的在线CRC计算器复制和粘贴以下数据.
To explain what is going on, normally if you calculate and append a non-complemented CRC to a message, then calculate the CRC of the message + CRC, the resulting CRC is zero (if there are no errors). Let CRC32X = a custom CRC32 with initial value = 0 and xorout = 0. You can copy and paste the data below with the online CRC calculator I posted a link to.
CRC32X{0x31 0x32 0x33 0x34} = 0xBAA73FBF
附加CRC并再次计算:
appending the CRC and calculating again:
CRC32X{0x31 0x32 0x33 0x34 0xBF 0x3F 0xA7 0xBA} = 0x00000000
现在考虑一个更简单的情况:
Now consider a simpler case:
CRC32X{0x00 0x00 0x00 0x00} = 0x00000000
CRC32X{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} = 0x00000000
然后看一下补充CRC并将其附加的效果:
Then to see the effect of complementing the CRC and appending it:
CRC32X{0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF} = 0xDEBB20E3
并取补码(不使用〜):
and taking the complement (using ~ for not):
~CRC32X{0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF} = ~0xDEBB20E3 = 0x2144DF1C
初始值与消息的前4个字节进行XOR运算.因此，对于初始值为0xFFFFFFFF且后补CRC的CRC32():
The initial value is XOR'ed with the first 4 bytes of the message. So for CRC32() with initial value of 0xFFFFFFFF, and post complemented CRC:
CRC32(0x00 0x00 0x00 0x00) = 0x2144DF1C
~CRC32X(0xFF 0xFF 0xFF 0xFF) = ~0xDEBB20E3 = 0x2144DF1C
这篇关于验证CRC校验和是否为零的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！