我反复阅读了很多文章-由于某些原因,我找不到任何描述必须是一个简单过程的文章:如何将计算出的CRC与原始消息相结合,以便再次计算CRC得到0(=检查为正确)?我确实找到了几个“longhand”计算的例子(只有2或3位crc),但是没有使用库函数的例子,比如[crcmod][1]
(Python库)。你知道吗
下面是我写的一个简单程序:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
import crcmod
def test_cycle():
test_str = b"123456789"
orig_msg = test_str
print("Original message: {:s}".format(orig_msg.hex()))
#~ crc_calc = crcmod.predefined.Crc('xmodem')
crc_calc = crcmod.Crc(
0x11021,
rev = False,
initCrc = 0x0000,
xorOut = 0x0000)
crc_calc.update(orig_msg)
print("CRC: {:04x}".format(crc_calc.crcValue))
lo = crc_calc.crcValue & 0xff
hi = crc_calc.crcValue >> 8
new_msg = test_str + bytes((hi, lo))
print("Crc appended: {:s}".format(new_msg.hex()))
crc_calc.update(new_msg)
print("CRC: {:04x}".format(crc_calc.crcValue))
def main(args):
test_cycle()
return 0
if __name__ == '__main__':
import sys
sys.exit(main(sys.argv))
有一些注释行,来自不同字节顺序的实验。该计划的结果如下:
Original message: 313233343536373839
CRC: 31c3
Crc appended: 31323334353637383931c3
CRC: 00ef
第一个CRC(31C3
)似乎与the expected values for xmodem-CRC对应。我尝试了许多方法,将获得的CRC与原始字符串组合起来,但从未获得“0”。我是不是漏了什么?你知道吗
crc_calc.update(new_msg)
将new_msg
的全部内容添加到CRC中。因为crc_calc
已经保存了313233343536373839
的结果,所以您有效地计算了31323334353637383931323334353637383931c3
的CRC,这确实是00ef
。你知道吗要仅将这两个字节添加到计算中,请使用
或者,使用
crcmod.Crc()
的新实例,或者在执行新计算之前重置现有实例的crcValue
两者都会给你一个0的结果
一些背景,为那些到达这个问题,想知道附加crc。你知道吗
如果一个CRC被适当地附加到它是CRC的消息中,并且在消息或CRC中没有引入错误,那么整个事物的CRC将是一个常数仅依赖于该CRC的定义。你知道吗
要正确地附加CRC,需要注意位顺序。对于
crcmod
提供的一般CRC定义,如果rev
为假,则必须首先附加最重要的位。如果rev
为真,则必须首先将位附加到最低有效位。对于面向字节的消息,这意味着首先CRC的宽度必须是8位的倍数(顺便说一下,这是crcmod
所允许的),并且CRC必须分别以大端顺序或小端顺序追加。你知道吗根据CRC的定义,得到的常数并不总是零。如果CRC的
xorOut
值为零,则它为零。否则,常数是n零位的CRC,其中n是CRC的宽度,并且提供的初始CRC值是零(不是initCrc
)。例如,对于标准CRC-32,以小端顺序附加CRC-32的消息的CRC-32总是0x2144df1c
。你知道吗对于这个特殊的问题,CRC是按大端顺序追加的,所以
31 c3
,结果消息的CRC+CRC是零。你知道吗相关问题 更多 >
编程相关推荐