CodeKitHub工具介绍
CRC 全称为 Cyclic Redundancy Check（循环冗余校验），是一种纠错检测码，最早在 W. Wesley Peterson 和 D.T. Brown 于 1975 年发表的论文中被描述，后来在 Ross Williams 的《A Painless Guide to CRC Error Detection Algorithms》 以及 ITU-T / ISO 3309 标准等参考资料中被正式规范化。CRC 将一条消息视为一个大的二进制数，并用一个固定的生成多项式去除它；这次除法的余数就是校验值。由于多项式除法在硬件和软件中计算成本都很低，CRC 已成为存储和传输系统中默认的错误校验方式。
CRC-32——具体来说是多项式为 0xEDB88320、初始值为 0xFFFFFFFF、最终异或值为 0xFFFFFFFF 的这一变体——已在 IEEE 802.3（以太网）中标准化，并被用作 ZIP 和 gzip 压缩包、PNG 图像文件以及众多网络和存储协议内部的校验值。它是被请求最多的 CRC 变体，这也是本工具将其设为默认算法的原因。CRC-16/CCITT-FALSE（多项式 0x1021）和 CRC-16/MODBUS（多项式 0x8005，反转形式）是两种广泛使用的 16 位变体，常见于 Modbus RTU、XMODEM 等串行协议以及各种嵌入式/工业通信标准中。
理解 CRC 不是什么同样重要：它不是密码学哈希函数。CRC 是快速的线性函数，对蓄意操纵没有任何抵抗力——构造出另一条产生相同 CRC 值的消息是很容易做到的。它们非常擅长捕捉由噪声传输线路、磁盘错误或下载中断等原因造成的随机比特翻转，但对于想要在不被察觉的情况下篡改数据的攻击者，CRC 完全无法提供保护。
为什么使用它？
- 调试 Modbus RTU 驱动时，从机一直拒收你发的帧——把确切的字节序列粘贴进来，选择 CRC-16/MODBUS，先确认固件里的 CRC 例程算出来的值和参考值一致，再去排查其他环节。
- 刚用 C 或 Rust 从零手写了一个 CRC-32 查表实现，想先做个基本校验——用标准测试字符串“123456789”跑一遍，确认结果是 0xCBF43926，再放心用它处理真实数据。
- 某个 ZIP 解压工具在某个条目上报了 CRC 不匹配的错误，不确定压缩包是不是真的损坏了——把解压出来的字节重新计算一次 CRC-32，和 ZIP 本地文件头里存储的值做对比。
- 在实现 XMODEM 或类似的串口协议，文档只写了一句“在末尾附加 CRC-16”没有更多细节——先在这里算出正确值，心里有数之后再去调试发送端代码。
- 接手一个嵌入式老项目，校验字段没有文档说明，怀疑用的是 CRC-16/CCITT-FALSE 而不是 CRC-16/MODBUS——用同一段已知数据分别试两种变体，看哪个和设备实际发出的值对得上。
- 100% 本地运行：你的文本或文件完全在浏览器中通过 JavaScript 处理，不会上传到任何地方。
使用方法
- 选择“Text”标签页并粘贴或输入你的内容，或切换到“File”标签页并从设备中选择一个文件。
- 选择 CRC 算法：CRC-32（IEEE 802.3，默认且最常用）、CRC-16/CCITT-FALSE 或 CRC-16/MODBUS。
- 校验值会自动更新，以十六进制、十进制和二进制形式显示。
- 点击任意结果旁边的“Copy”即可将其复制到剪贴板。
示例
输入
123456789输出
0xCBF43926 (3421780262)这是标准公开发布的 CRC-32（IEEE 802.3）测试向量：ASCII 字符串“123456789”的 CRC-32 值始终为 0xCBF43926。你可以用这个字符串来对照本工具的输出与任何其他正确的 CRC-32 实现。
CRC 与密码学哈希（MD5 / SHA）的区别
CRC 和密码学哈希都将数据压缩为固定大小的指纹，但它们解决的问题不同，不能互相替代。
| 属性 | CRC（如 CRC-32） | MD5 / SHA-256 |
|---|---|---|
| 目的 | 检测意外损坏 | 检测蓄意篡改 / 验证完整性 |
| 速度 | 极快，硬件/软件实现简单 | 较慢，每字节需要更多计算 |
| 抗碰撞性 | 无——可轻易蓄意构造碰撞 | 设计为计算上不可行（SHA-256），或已被攻破（MD5） |
| 典型长度 | 16 或 32 位 | 128 位（MD5）或 256 位（SHA-256） |
| 常见用途 | ZIP/gzip、PNG、以太网、Modbus、存储 | 文件完整性校验、数字签名、密码存储（配合加盐） |
三种 CRC 变体一览
每种变体都由多项式、初始值、输入/输出是否反转，以及最终异或值这几个参数共同定义——只要其中一项对不上，算出来的校验值虽然“技术上有效”，但和目标系统并不兼容。
| 变体 | 多项式 | 初始值 | 是否反转 | 最终异或值 | 常见用途 |
|---|---|---|---|---|---|
| CRC-32（IEEE 802.3） | 0xEDB88320 | 0xFFFFFFFF | 是（输入和输出） | 0xFFFFFFFF | ZIP、gzip、PNG、以太网 |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | 否 | 0x0000 | XMODEM、电信类协议 |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | 是（输入和输出） | 0x0000 | Modbus RTU 串行帧 |
相关工具
如果你需要的是密码学校验值而不是纠错用的 CRC，以下工具更适合你。
常见问题
CRC 有什么用途？
CRC（循环冗余校验）是附加在数据块后面的一种错误检测码，接收方可以重新计算它，以确认数据在存储或传输过程中没有意外损坏。它被内置于 IEEE 802.3 以太网帧、ZIP 和 gzip 文件格式、PNG 图像以及许多串行和工业协议（如 Modbus）等标准中。
CRC-32 和 MD5 或 SHA-256 一样吗？
不一样。CRC-32 是一种快速、线性的错误检测校验值，不具备任何安全属性——蓄意构造两个具有相同 CRC-32 值的不同输入是很简单的事情。MD5 和 SHA-256 是密码学哈希函数，其设计目的是让这种蓄意的碰撞在计算上不可行。使用 CRC-32 来捕捉意外损坏（如磁盘划伤、网络丢包）；当你需要防篡改证明或需要抵御攻击者的完整性保证时，请使用我们的 [Hash Generator](/hash-generator) 或 [MD5 Generator](/md5-generator) 提供的密码学哈希。
本工具使用的是哪种 CRC-32 变体？
IEEE 802.3 / ZIP / PNG 变体：多项式 0xEDB88320（0x04C11DB7 的比特反转形式），初始值 0xFFFFFFFF，输入和输出都进行反转，最终异或值为 0xFFFFFFFF。这是以太网、ZIP、gzip 和 PNG 所使用的变体，也是对 ASCII 字符串“123456789”产生 0xCBF43926 的变体——这是用于验证 CRC-32 实现的标准公开测试向量。
CRC-16/CCITT-FALSE 和 CRC-16/MODBUS 有什么区别？
两者都是 16 位 CRC，但多项式和参数不同。CRC-16/CCITT-FALSE 使用多项式 0x1021，初始值为 0xFFFF，不进行比特反转；它常见于 XMODEM 等协议以及各种电信标准中。CRC-16/MODBUS 使用多项式 0x8005（反转后为 0xA001），同样以 0xFFFF 为初始值，但输入和输出都进行反转——这是 Modbus RTU 附加到每个串行帧末尾的校验值。对于相同的输入，两者会产生不同的结果，因此选择目标协议实际规定的变体非常重要。
我可以计算文件的 CRC，而不只是文本吗？
可以。切换到“File”标签页并从设备中选择一个文件——本工具会在浏览器本地（通过 File API）读取其原始字节，并针对这些确切的字节计算校验值，与 ZIP 或 PNG 读取器的做法完全相同。
我的数据会被上传到服务器吗？
不会。文本和文件的计算都完全在客户端使用 JavaScript 运行，采用标准的基于查表的 CRC 算法。你输入或上传的任何内容都不会离开你的浏览器。
为什么我自己写的 CRC-32 实现算出来的结果和这个工具不一样？
最常见的原因是初始值、最终异或值或比特反转设置没对上——CRC-32 并不是单一固定算法，而是一族参数组合，本工具使用的 IEEE 802.3 / ZIP / PNG 变体以 0xFFFFFFFF 作为初始值，输入和输出都进行反转，最终再与 0xFFFFFFFF 异或。少做其中任何一步，都会得到一个技术上“合法”但互不兼容的校验值。可以用“123456789” → 0xCBF43926 这个测试向量来定位到底是哪一步出了问题。
上传文件有大小限制吗？
工具本身没有人为设置限制，但由于 CRC 是在浏览器里用 JavaScript 逐字节计算的，非常大的文件可能会比较慢。对于常见的固件镜像、ZIP 条目或协议帧（从几个字节到几十兆字节），计算速度基本是即时的。
粘贴文本时，空白字符或换行符风格会影响 CRC 结果吗？
会——CRC 是针对输入的确切字节计算的，所以末尾多一个换行符、多一个空格，或者 Windows 风格的 CRLF 和 Unix 风格的 LF 换行符，都会得出不同的校验值，即使肉眼看起来文本内容一样。如果要对照另一个工具算出的校验值，请粘贴该工具实际处理的完全相同内容（包括末尾空白），或者更保险的做法是切换到“File”标签页直接比对原始字节。
两个完全不同的文件会不会算出相同的 CRC-32 值？
会，而且这是正常现象，不是 bug——CRC-32 只有 2^32 种可能的输出值，对于足够大的数据集合，从数学上讲碰撞是必然存在的，而且由于 CRC-32 不具备密码学意义上的抗碰撞性，蓄意构造出碰撞也非常容易。这正是为什么 CRC-32 适合捕捉意外损坏，但不适合用来验证文件是否被篡改过。
如果协议文档没有说明具体参数，应该选哪种 CRC 变体？
先从该协议家族最常关联的变体试起：Modbus RTU 串行通信用 CRC-16/MODBUS，XMODEM 以及许多源自电信标准的协议用 CRC-16/CCITT-FALSE，任何和 ZIP、gzip、PNG 或以太网相关的场景用 CRC-32（IEEE 802.3 变体）。如果拿真实设备的已知正确帧去对比，两种都对不上，那这个协议可能用的是本工具未覆盖的非标准多项式或参数组合。