一、CRC的形象理解
本文面向对CRC校验有一定基础的读者,如果你不懂,请戳这里。维基百科还有图解版的。
在CRC的具体实现中,如果要计算CRC的数据很长,一般都会用到寄存器,用来保存当前的计算到的CRC,循环计算到数据流结束,以下给出了计算16位CRC的流程:(流程来源)
假如数据流为4字节:BYTE[3]、BYTE[2]、BYTE[1]、BYTE[0];
1)数据流左移16位,低位补0,将扩大后的数据流(6字节)高16位(BYTE[3]、BYTE[2])放入一个长度为16的寄存器;
2)如果寄存器的首位为1,将寄存器左移1位(寄存器的最低位从下一个字节获得),再与生成多项式的简记式异或;
否则仅将寄存器左移1位(寄存器的最低位从下一个字节获得);
3)重复第2步,直到数据流(6字节)全部移入寄存器;
4)寄存器中的值则为CRC校验码CRC[1]、CRC[0]。
但是这种方式有个缺点,就是如果在被计算CRC的数据前即使出现了任意个0,会得到相同的CRC,也就是被除数前面加好多个0,除以多项式之后得到的余数还是不变。那么CRC校验就无法检测出这种类型的数据修改了。。
于是真正实现CRC还引进了寄存器的预设值(Preset),寄存器一开始的值一般不为0。
网上有人自己手算了A的16-bit CRC-CCITT,它就是相当于将预设值设为了0xFFFF,注意这里是将预置值直接放到数据的前面,然后进行手算,和下面讲的预处理有出入(来源)
Calculation of the 16-bit CRC-CCITT for a one-byte message consisting of the letter “A”: Quotient= 111100001110111101011001 |
Conversion of the binary value above to hexadecimal by segmenting the bits to nibbles: binary nibbles 1001 0100 0111 1001 hexadecimal 9 4 7 9 |
二、CRC的现成算法和工具
当我认为把CRC弄清楚之后,我在网上找它们的现成的实现,发现了不少好东西:
这两用的是同一套算法,我用这套算法计算“A”的16bit-CRC时,发现等于0xB915,而不是上面手算的0x9479!对这些算法进行分析后,发现算法和手算的算法不一样,该算法先将8位数据左移8位,再和预置值异或,然后把得到的值当作一个16位数据用最基本的计算方法计算其CRC。这种算法用C语言表述就是(代码出处):
姑且将这套算法表述为CRC(data,preset),它是跟手算方法有区别的一种CRC计算方法,但是还是能实现CRC的功能。所以我们把它当成正确的算法来使用。
三、算法的多样化
维基百科上对CRC的解释的最后列出了好多种CRC,有CRC16-CCITT,CRC32,CRC16-IBM,等等,这些算法的区别主要是以下几点:
1.预设值的不同,有的是0xFFFF,有的是0x1D0F(这个值下面还会碰到)。
2.一次性处理数据的位宽不同,CRC32,CRC16分别是32位和16位。
3.有的算法将算出来的CRC取反后再附在数据的末尾。比如crc=CRC(data,preset),那么发送的数据是{data,!crc}。
4.校验的判断条件不同,比如CRC("A",0xFFFF)=0xB915,如果发送{"A",0xB915},那么CRC({"A",0xB915},0xFFFF)=0,是符合我们对CRC的原理的理解的,即判断数据是否完整就是看最后的校验值是否为0。如果将CRC取反再发送,则发送{"A",0x46EA},那么CRC({"A",0x46EA},0xFFFF)=0x1D0F,注意这时候判断数据是完整就是看最后的校验值是否等于0x1D0F。
我至今仍然有着疑问,到底0x1D0F是什么数字,哪里都能碰到它,我出于好奇还计算了CRC("A",0x1D0F),结果是0x9479,这就是我们之前看到的手算的结果,好奇怪。。