CRC32 校验
把一段文本或一个文件算成一个八位十六进制的数,再和你手上的值比一比。CRC32 只回答一件事:这段数据在传的过程中有没有变样。它挡不住有意篡改,也不该被当成密码学摘要 —— 要那个,去 哈希计算器。
—
—
CRC32 能说明什么,不能说明什么
它能说明的是传输或拷贝过程中有没有一个字节变了。它不能说明的是"这份文件是不是我要的那一份" —— CRC32 是线性的,故意构造一对 CRC32 相同的不同文件是很容易的,而且只有 32 位,随便找两个不相干的文件撞上的概率也不是零。所以下载校验、防损坏用它;证明来源、防篡改用 SHA-256。
算的是字节,不是字符
中文在 UTF-8 里是三个字节,在 GBK 里是两个 —— 同一段文字按不同编码算出来的 CRC32 完全不同。这一页一律按 UTF-8 算(现代系统的默认),所以拿它和一个 Windows 上按 GBK 算出来的值比,对不上是正常的,不是谁算错了。文件那一侧没有这个问题:文件本来就是字节。
这一页的 CRC32 是哪一个
CRC32 这个名字底下有好几种参数组合。这一页用的是最通行的那一个:多项式 0xEDB88320(反转形式)、初值 0xFFFFFFFF、末尾取反、输出小写八位 —— 也就是 zlib、PNG、ZIP 里的那个 CRC32。标准检查值:把 123456789 三个字算一遍,应当得到 cbf43926。
常见问题
用途不同。 CRC32 只有 32 位,设计目标是发现传输错误,算得极快,常见于压缩包、PNG 和网络协议;MD5 是 128 位、SHA-256 是 256 位,设计目标是防止篡改,慢一些。要检查文件有没有传坏,CRC32 够用;要证明文件没被别人动过,得用 SHA-256。
按可能性从高到低排:(1) 文本编码不同 —— 中文按 UTF-8 还是 GBK,结果完全不同;(2) 末尾多了一个换行(很多编辑器保存时会自动加);(3) 对方用的不是这一套参数(有的实现输出大写、有的不补前导零、有的初值不同);(4) 你拿到的是另一个文件。文件对比建议直接选文件,不要复制粘贴文本。
不会。 文件是交给浏览器读的(File.arrayBuffer()),CRC32 在这个页面里算完,全程没有一次网络请求。关掉网络也能用 —— 你可以断网试一下。
这一页的上限是 128 MB。不是因为算法慢(CRC32 每秒能过几百 MB),而是因为整份文件要先进内存:超过这个量级,浏览器会明显卡顿甚至崩掉。再大的文件请用命令行的 cksum / zlib 工具,或者系统的哈希命令。
