CRC-4校验码：生成多项式、位运算实现与链路层应用解析

简介：这是一份面向计算机网络学习的CRC-4校验码源码资料包，压缩后仅15KB，包含6个文件。资源以四位循环冗余校验算法为核心，汇编源文件给出底层实现，C语言文件提供查表法加速所需的CRC查找表，同时附带可直接运行的COM与EXE程序及批处理脚本，便于理解从源码到工具的完整链路。通过阅读与调试，可掌握CRC生成和校验的完整过程，理解串行通信、以太网帧校验等场景中的差错检测原理，并借鉴汇编与C语言混合编程、查表优化等实用技巧。从汇编指令到查表优化，资料覆盖了CRC-4实现的多种技术要点，亦可作为课程设计与实验参考。已有230人加入学习，适合通信专业学生、嵌入式开发者以及需要快速实现CRC-4的工程人员。

1. CRC-4 校验码：一个被低估的计算机网络底层校验算法

做链路层协议移植时，我经常遇到这种尴尬：帧头、数据、长度都对，就是最后跟设备联调时 CRC 对不上。CRC-4 校验码虽然只有 4 位，却是很多短帧、协议头和复帧同步字段的“看门狗”。它不像 CRC-32 那样有大把现成硬件指令，也不像普通校验和那样直观，生成多项式、初值、反转、输出异或这几个参数稍不留神就会让联调翻车。这篇文章我按自己做网络底层的习惯，把 CRC-4 从数学原理讲到 C 源码，再落到计算机网络里的实际用法，最后把最容易踩的坑一条条拆开。

2. 先搞懂 CRC-4 的数学原理：模二除法与生成多项式

2.1 CRC 不是校验和：多项式除法的直觉

很多人把 CRC 和校验和混为一谈。校验和是直接累加，哪里有进位就加到后面；CRC 完全不同，它把待发送的数据当作一个二进制多项式，然后用一个固定的生成多项式去模二除，除完得到的余数就是校验码。模二除法里没有进位、没有借位，每一位的加减都等价于异或。所以整个 CRC 计算本质上就是“一堆异或门和移位寄存器在干活”。

对于 CRC-4，余数只有 4 位，也就是最终输出的校验值在 0x0 到 0xF 之间。但这不代表它的生成多项式只有 4 位。一个 4 次多项式最高项是 x^4，对应二进制是 5 位。比如最常见的 CRC-4 生成多项式 x^4 + x + 1，写成二进制就是 10011，习惯上记作 0x13。那个“4”指的是余数宽度，不是多项式位数，这个区分在跟同事对齐参数时特别重要。

2.2 生成多项式怎么选：0x13、0x19 还是自定义？

做 CRC-4 时第一个要定的是生成多项式。我常用的是 0x13，也就是 x^4 + x + 1。它是个本原多项式，对于 4 位 CRC 来说能覆盖的差错模式比较均衡，在短帧场景下漏检率很低。有些私有协议会用 0x19，即 x^4 + x^3 + 1，检错能力也还行。但要注意：别随手用 x^4 + 1 这种多项式，它的因子太简单，对偶数个错误几乎不设防，属于典型的“看着简单、用着坑”。

选多项式要看你的数据特征。如果协议里经常出现连续突发错误，建议选带低次项的本原多项式；如果只是保护一个命令字节，0x13 足够。在计算机网络里，CRC-4 多用于长度不超过几十字节的控制帧，超过这个范围我会直接换 CRC-8 或 CRC-16，而不是用 4 位硬扛，这个取舍后面专门说。

2.3 手推一个字节的 CRC-4：按比特模拟除法过程

为了看清计算过程，我用 Python 写一个逐比特的模拟器，打印每一步的寄存器状态。这样新手能跟着走，熟手也能对照自己写的位运算排查。

def crc4_print(data_byte: int, poly_low: int = 0x03) -> int: # poly_low 是生成多项式去掉最高位后的低4位，0x13 -> 0x03 crc = 0 bits = [(data_byte >> i) & 1 for i in range(7, -1, -1)] print(f"处理字节 0x{data_byte:02X}, 比特序列: {bits}") for idx, bit in enumerate(bits): msb = (crc >> 3) & 1 crc = (crc << 1) & 0xF xor_flag = msb ^ bit if xor_flag: crc ^= poly_low print(f" bit{7-idx} 输入={bit} 寄存器={crc:04b}") return crc print("CRC-4 result =", hex(crc4_print(0x01)))

逻辑说明：4 位寄存器初始为 0。对每个输入比特，先看寄存器最高位，把它和输入位异或；然后寄存器左移并保留低 4 位；如果异或结果是 1，就和多项式的低 4 位 0x03 异或。整个过程就是在做逐位的模二除法。

参数说明：这里的poly_low对应生成多项式 0x13 的低 4 位。注意生成多项式的最高位 x^4 不用显式参与异或，因为它会被左移自然“溢出去”。如果你把poly_low改成 0x07，那对应的就是另一个多项式了，拿同一份数据算出的 CRC 会完全不同，所以多项式是第一个要对齐的参数。

3. 把 CRC-4 写成 source code：位运算实现、查表法与参数变体

3.1 最直观的位运算实现：按比特驱动，逻辑清晰

真正放到协议栈里，CRC-4 通常用 C 写。先给出最原始的位运算实现，容易验证，调试时也方便打印中间状态。

#include <stdint.h> #include <stddef.h> #define CRC4_POLY_LOW 0x03 // 生成多项式 0x13 的低4位 #define CRC4_INIT 0x00 // 初值 uint8_t crc4_update_bit(uint8_t crc, uint8_t bit) { uint8_t msb = (crc >> 3) & 0x01; crc = (uint8_t)((crc << 1) & 0x0F); if (msb ^ bit) { crc ^= CRC4_POLY_LOW; } return crc; } uint8_t crc4_compute(const uint8_t *data, size_t len) { uint8_t crc = CRC4_INIT; for (size_t i = 0; i < len; i++) { uint8_t byte = data[i]; for (int j = 7; j >= 0; j--) { uint8_t bit = (byte >> j) & 0x01; crc = crc4_update_bit(crc, bit); } } return crc; }

逻辑说明：crc4_update_bit完成一次模二除法。先取出寄存器最高位msb，左移一位后与输入位异或，决定要不要异或多项式。外层循环先按字节遍历数据，再按 MSB-first 顺序处理每个比特。这个顺序必须和接收端约定一致，否则两边永远对不上。

参数说明：CRC4_INIT是寄存器初值。很多协议要求初值不为 0，比如初值 0x0F，那么计算前就把 crc 置成 0x0F。还有输出是否要再异或一个值，以及输入是否逐比特反转，这些是按位实现中最容易忽略的三个参数。你把这个函数跑通后，再改参数就非常快了。

3.2 查表法提速：4 位 CRC 也能查表

位运算实现简单，但每个比特在循环里判断一次，吞吐量不够。计算机网络这条路上，如果帧速率高，我一般会把 CRC-4 升级成半字节查表。因为 CRC-4 寄存器只有 4 位，一次处理半个字节刚好能查 16 项的表。

#include <stdint.h> static uint8_t crc4_table[16]; void crc4_init_table(void) { for (int i = 0; i < 16; i++) { uint8_t crc = 0; // 用位运算生成“单个半字节”从初值0开始的CRC for (int j = 3; j >= 0; j--) { uint8_t bit = (i >> j) & 0x01; uint8_t msb = (crc >> 3) & 0x01; crc = (uint8_t)((crc << 1) & 0x0F); if (msb ^ bit) { crc ^= 0x03; } } crc4_table[i] = crc; } } uint8_t crc4_update_nibble(uint8_t crc, uint8_t nibble) { return crc4_table[crc ^ (nibble & 0x0F)]; } uint8_t crc4_compute_fast(const uint8_t *data, size_t len, uint8_t init) { uint8_t crc = init; for (size_t i = 0; i < len; i++) { uint8_t byte = data[i]; crc = crc4_update_nibble(crc, byte >> 4); // 先处理高半字节 crc = crc4_update_nibble(crc, byte & 0x0F); // 再处理低半字节 } return crc; }

逻辑说明：crc4_init_table用位运算模拟对单个 nibble 从初值 0 开始的完整处理，把 0 到 15 的结果存成表。crc4_update_nibble用crc ^ nibble作为查表索引，是因为当前寄存器的状态已经“折叠”进了新的输入里，这个式子看起来有点玄学，但数学上等价于连续做四次按位更新。

参数说明：init从函数参数传入，方便不同协议复用。如果你用的是输出异或或输入反转，需要在查表前对字节做反转处理。比如输入反转就把byte的位序反过来再拆半字节。这里最容易错的就是高半字节和低半字节的顺序：先高后低，对应 MSB-first；如果你的帧约定是 LSB-first，就得先处理低半字节。

3.3 参数表：初值、反转和输出异或决定兼容性

我做过一个对接设备，两边多项式、初值、输入输出都写对了，结果还是差一个值。最后发现是输出异或差 0x0F。下面这张表是我做协议对接时必用的参数核对清单，几乎覆盖了所有翻车点。

参数说明：在线 CRC 校验码计算工具五花八门，有的默认 CRC-16，有的默认初值 0xFFFF，拿这些工具直接套 CRC-4 很容易被带到沟里。我一般自己写一个参考函数，然后固定一组“已知向量”来验证，不轻信在线工具。那类叫“Modbus 校验码在线计算”的工具更偏向 CRC-16，算法思想一样，但参数跟 CRC-4 不是一回事，别混用。

4. 在计算机网络里落地：短帧校验、协议头保护与硬件友好性

4.1 链路层典型用法：给一个控制帧加 CRC-4 尾巴

假设我有一个简单的链路层帧：1 字节命令 + 1 字节数据，然后跟 1 个字节的 CRC 字段，但 CRC 只在低 4 位有效，高 4 位填 0。下面这段代码展示发送端怎么计算并封装。

#include <stdio.h> #include <stdint.h> uint8_t crc4_compute(const uint8_t *data, size_t len); // 用前面位运算实现 void build_frame(uint8_t cmd, uint8_t payload, uint8_t *frame_out) { frame_out[0] = cmd; frame_out[1] = payload; uint8_t crc = crc4_compute(frame_out, 2); frame_out[2] = crc & 0x0F; // CRC-4只占低4位 } int main(void) { uint8_t frame[3]; build_frame(0x5A, 0x3C, frame); printf("frame: %02X %02X CRC=%01X\n", frame[0], frame[1], frame[2]); return 0; }

逻辑说明：CRC 计算覆盖的是命令和数据两个字节，把算出的 4 位 CRC 放进第三个字节的低半字节。接收端收到后对前两个字节重新算一次 CRC，如果结果和帧尾一致，就认为这一帧没被改过。

参数说明：这里我故意把 CRC 放在低 4 位，是为了演示半字节对齐。有些协议会把 CRC 放在高 4 位，那就要用crc << 4存进去，接收端对第 3 个字节取高半字节再比较。这个存法在协议文档里一般写得很清楚，但实际对接时常有人两边存反，最后只能靠示波器抓波形才查出来。

4.2 与 CRC-8 / CRC-16 / CRC-32 的取舍：位数多不等于好

做计算机网络时，经常有同事说“CRC-4 只有 4 位，会不会不够安全”。安全确实有限制，但位数多不等于就好。CRC 的检错能力跟生成多项式和数据长度有关，只要数据够短、多项式选得合适，4 位足够完成它的任务。

| 指标 | CRC-4 | CRC-8 | CRC-16 | CRC-32 | | --- | --- | --- | --- | --- | --- | | 余数宽度 | 4 位 | 8 位 | 16 位 | 32 位 | | 校验字段开销 | 0.5 字节 | 1 字节 | 2 字节 | 4 字节 | | 适合帧长 | <= 几十字节 | <= 几百字节 | 几百到几千 | 不限 | | 硬件成本 | 4 个触发器 | 8 个触发器 | 16 个触发器 | 32 个触发器 | | 常见用途 | 控制字段、复帧同步 | 内存保护、小帧 | Modbus、PPP | 以太网 FCS |

选择依据：如果你的协议帧很短，比如一个 2 字节命令，用 CRC-16 纯粹是浪费带宽和硬件。反过来，如果数据有几十上百字节，CRC-4 的漏检率会明显上升，那时候该换 CRC-8 或 CRC-16，而不是硬调参数。

4.3 保护协议头：用 4 个触发器实现硬件校验

CRC-4 在计算机网络里还有一个优势：硬件实现极其便宜。在 FPGA 或 ASIC 里，只需要 4 个 D 触发器和几个异或门。下面用 C 语言模拟硬件移位寄存器的行为，方便你在写 RTL 前验证逻辑。

#include <stdint.h> // 模拟硬件：每个时钟沿输入1比特 uint8_t crc4_hw_update(uint8_t crc, uint8_t data_bit) { uint8_t msb = (crc >> 3) & 0x01; crc = (uint8_t)((crc << 1) & 0x0F); if (msb ^ data_bit) { crc ^= 0x03; // 硬件里这步就是三个异或门 } return crc; }

逻辑说明：这个函数和前面 3.1 的crc4_update_bit一模一样，因为硬件就是这么做的。每个时钟周期处理一个比特，数据比特从移位寄存器最高位方向移入，反馈异或门接在多项式的对应位。在硬件里，crc << 1就是触发器之间的连线，crc ^= 0x03就是三个反馈异或门。

参数说明：这个模拟函数不需要查表，适合在仿真里逐周期比对。如果你在用 FPGA，注意综合工具可能已经内置了 CRC 硬核，但硬核一般只支持 CRC-8/16/32。CRC-4 这种小规格，自己写 4 个触发器比调用硬核还省资源。

5. 避坑/常见问题排查：5 个让 CRC-4 校验码翻车的实操记录

5.1 现象：两台设备算出的 CRC 总是不一致

接到过好几次这种联调问题：A 设备发出的帧，B 设备校验失败，抓包看 RAW 数据完全一致。再一看代码，A 用的生成多项式是 0x03（低 4 位），B 用的却是 0x09（低 4 位）。原因就是两边协议文档里写的是同一个名字，但底层实现一个按 0x13 展开，另一个按 0x19 展开，结果自然不同。解决办法是先对齐生成多项式完整二进制，比如 0x13 = 10011，然后在代码注释里写死“多项式低 4 位 0x03”，不要只写“CRC-4”。

5.2 现象：查表法和位运算法结果对不上

有个同事自己写了查表法，位运算算法测出来是对的，查表法测前两个字节正确，第三个字节开始就错。原因是他查表时直接用crc ^ byte，但 CRC-4 是 4 位寄存器，一次只能吃半个字节。他把整个字节塞进索引，等于一次处理了 8 位，而寄存器只有 4 位，后面的位全被丢弃了。解决方法是把字节拆成两个半字节，按高、低顺序分别查表，就像 3.2 里的crc4_compute_fast。记住：查表表的尺寸是 16，不是 256。

5.3 现象：误码漏检率比理论高

理论上 CRC-4 能检测所有单比特错误和大多数双比特错误，但实际测试发现，连续突发错误漏检很多。后来计算了一下，问题出在数据长度上。CRC-4 的检错能力随数据长度增加而下降，我那个帧有 64 字节，已经超出了 4 位 CRC 的舒适区。解决办法是缩短帧长，或者把生成多项式更换为更高级的 CRC-8。这里的原则是：CRC 宽度至少要和预期突发错误长度相当，CRC-4 只适合短控制帧。

5.4 现象：在线计算器与本地代码结果不同

很多人喜欢拿在线校验码计算器做验证，结果发现算出来的值和本地 C 代码不一样。原因是在线计算器默认参数通常是初值 0x00、输出不异或，但本地代码可能设置了初值 0x0F、输出异或 0x0F。还有一种情况是，有些在线工具只支持 CRC-8/16/32，你输入 CRC-4 时它内部其实在用 CRC-8 的算法，只截取低 4 位。解决方法是自己维护一组已知向量，不要依赖在线工具做最终比对。如果非要用在线计算器，先弄清楚它的参数页，把初值和输出异或改成和自己的协议一致。

5.5 现象：硬件 CRC 模块输出的字节序反了

硬件调试时，CRC 模块算出来的值和软件模拟的值总是差一个固定偏移。查了半天发现是输入位序的问题。我的协议是 MSB-first，但硬件 IP 核配置成了 LSB-first，也就是从最低位开始移入寄存器。解决方法是把配置位改回来，或者在软件模拟时把每个字节的比特顺序反转。注意输入反转和输出反转是两个独立参数，只反转输入并不会让输出也跟着反，两边要分开处理。

6. 往深处走：用随机错误注入验证你的 CRC-4 实现

6.1 用已知向量做回归：构造自己的 golden test

没有标准向量，就自己造一套可信的回归用例。我用 Python 写了一个参考实现，然后把一组“输入-输出”对固定下来，任何语言重写后都必须对齐。这套向量的好处是无论你以后换 C、Rust 还是 Verilog，都能复用。

def crc4_ref(data: bytes, init: int = 0x0, poly_low: int = 0x03) -> int: crc = init & 0x0F for byte in data: for i in range(7, -1, -1): bit = (byte >> i) & 1 msb = (crc >> 3) & 1 crc = ((crc << 1) & 0x0F) if msb ^ bit: crc ^= poly_low return crc # 固定用例：初值0，多项式0x13，无反转，无输出异或 test_cases = [ (b'', 0x0), (b'\x00', 0x0), (b'\x01', 0x3), (b'\x02', 0x6), (b'\x01\x02', ?), ] for data, expected in test_cases: assert crc4_ref(data) == expected

逻辑说明：test_cases里我留了一个不确定值，你不应该照抄它。正确做法是先运行crc4_ref，把输出打印出来，然后手动检查前一条b'\x01'是否为 0x3，确认参考实现没问题后，再把打印结果固化进测试代码。这样生成的就是你自己的 golden vector。

参数说明：init和poly_low是固定参数，一旦改动，整套向量作废。所以在测试文件顶部一定要写清楚“此测试对应的参数为多项式 0x13、初值 0x00、MSB-first、无输出异或”。以后任何一个人改参数，都必须更新测试文件，否则就是对着一份失效的用例瞎调。

6.2 随机报文加错误注入：量化漏检率

光靠向量验证只能证明“没写错”，不能证明“够用”。我之前踩过坑，知道还要做错误注入测试。思路是生成大量随机短报文，算 CRC 后随机翻转若干比特，再看接收端能不能发现。

import random def bit_flip(data: bytes, n: int) -> bytes: data = bytearray(data) total_bits = len(data) * 8 positions = random.sample(range(total_bits), n) for p in positions: byte_idx = p // 8 bit_idx = 7 - (p % 8) data[byte_idx] ^= (1 << bit_idx) return bytes(data) def test_miss_rate(num_trials=10000, data_len=8, flips=1): miss = 0 for _ in range(num_trials): original = bytes(random.getrandbits(8) for _ in range(data_len)) crc = crc4_ref(original) corrupted = bit_flip(original, flips) crc2 = crc4_ref(corrupted) if crc == crc2: miss += 1 print(f"{flips} bit flip miss rate: {miss/num_trials:.4%}")

逻辑说明：bit_flip在随机位置翻转指定数量的比特，test_miss_rate通过比较原始 CRC 和翻身后的 CRC 是否相同，统计漏检率。单比特错误理论上漏检率为 0，多比特错误会有一定概率漏检。实测下来，8 字节数据翻转 2 比特时，CRC-4 的漏检率大概在几个百分点，翻转 3 比特时更高。这个数字能直接帮你判断 CRC-4 是否适合你的帧长和误码环境。

参数说明：flips=1是必须通过的单比特测试；flips=2的结果和多项式有关，如果发现 2 比特漏检率异常高，说明多项式选得不好，建议换成 0x19 再测一轮。记住：测试曲线只对“你当前的参数”有效，换多项式就得重测。

我做协议对接这么多年，吃过的最大亏就是拿到一份 CRC-4 代码后没确认参数就往上叠业务，结果联调时对着逻辑分析仪怀疑人生。现在我的习惯是：新接一个协议，先把多项式、初值、反转、输出异或这四件事写进代码注释，再跑一遍 golden test，最后做一次错误注入测试，三关过了才敢合入。这套流程救了我很多次，也希望帮到你。

本文还有配套的精品资源，点击获取