在测试 CRC 实现时，我注意到 0x01 的 CRC 通常(？)似乎是多项式本身。然而，当尝试手动进行二进制长除法时，我总是以丢失多项式的前导“1”而告终，例如有了“0x01”的消息和多项式“0x1021”，我会得到
1 0000 0000 0000 (zero padded value)
(XOR) 1 0000 0010 0001
-----------------
0 0000 0010 0001 = 0x0021
但是对于给定的输入，任何示例实现(我在这里处理 XMODEM-CRC)都会产生 0x1021。
查看https://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks ，我可以看到高位与生成多项式离开移位寄存器的异或步骤将如何导致这个结果。我不明白为什么要以这种方式执行此步骤，因为它明显改变了真正的多项式除法的结果？
最佳答案
我刚刚读了http://www.ross.net/crc/download/crc_v3.txt并注意到在第 9 节中，提到了一个隐含的前缀 1 来强制执行所需的多项式宽度。
在我的例子中，这意味着用作除数的实际多项式不是 0x1021，而是 0x11021。这导致前导“1”被丢弃，余数是“预期的”16 位多项式:
1 0000 0000 0000 0000 (zero padded value)
(XOR) 1 0001 0000 0010 0001
-----------------
0 0001 0000 0010 0001 = 0x1021
关于algorithm - 为什么 "1"的 CRC 会产生生成多项式本身？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52689764/