CRC32、MD5、SHA-256 有什么区别？

一、三类算法分别解决什么问题

算法	位数	十六进制长度	设计目标	能否判断内容被替换
CRC32	32 位	8 位	传输/存储检错	不能
MD5	128 位	32 位	摘要（已被证明可构造碰撞）	不宜
SHA-1	160 位	40 位	摘要（已弃用）	不宜
SHA-256	256 位	64 位	密码学摘要	可以（前提见下）

一句话分工：「下载有没有下坏」用 CRC32；「内容有没有被人换过」用 SHA-256。 CRC32 不是密码学摘要，构造两段 CRC32 相同的内容是可行的，而正常文件的 CRC32 又是公开的，所以它证明不了任何安全性。

二、同一份内容算出的值

以文本 hello 为例（UTF-8 编码，5 字节）：

算法	结果
CRC32	3610A686
MD5	5d41402abc4b2a76b9719d911017c592
SHA-1	aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
SHA-256	2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

两个固定锚点可以用来验证工具是否可靠：

• CRC32 的标准检校值：字符串 123456789 的结果是 CBF43926（十进制 3421780262）；如果你手里的工具算出来不是这个值，说明它用的不是 IEEE 802.3 多项式（CRC32C、Adler-32 是别的算法，值都不一样）。
• 空内容也有合法结果：CRC32 为 00000000（十进制 0）。

中文内容的编码差异：你好 按 UTF-8 是 6 字节（一个汉字 3 字节），SHA-256 为 670d9743542cae3ea7ebe36af56bd53648b0a1126162e78d81a32934a711302e。同一个汉字在 GBK 下字节不同，摘要自然也不同——「看着一样却对不上」多半是编码不同。

三、下载文件校验四步

1. 拿官方的哈希值：官网 HTTPS 页面或官方公告，别用第三方转发来的值。
2. 本地算：Linux / macOS 用 sha256sum 文件名 或 shasum -a 256 文件名；Windows 用 certutil -hashfile 文件名 SHA256。
3. 逐位比对：忽略大小写和空格，但一个字符都不能少；把两串值贴到同一个编辑器里对齐看。
4. 对不上就重下：换镜像或换时间重试，确认版本号一致，并确认对方给的是压缩包还是解压后的文件。

四、哈希对不上时的排查顺序

按概率从高到低：

1. 文件没下载完整（断流、代理截断）——重新下载；
2. 版本不对——你拿的是新版文件、对方给的是旧版哈希；
3. 算法混用——把 SHA-1 的值和 MD5 的比对；
4. 复制时漏了首尾字符；
5. 下载工具做了「自动修改」（少数加速器会改动文件尾部）；
6. 压缩包与解压后文件混比——压缩包是容器，含文件名、目录结构与元数据，与里面单个文件的摘要必然不同。

五、两个边界要认清

• 哈希一致 ≠ 文件安全，它只说明「你拿到的内容与发布者给出的内容一致」。如果哈希值本身来自被攻破的站点或陌生人转发，比对通过也不代表无害。
• MD5 不是加密。它是单向摘要，不能用来「加密」文件，也不该用来存密码。大文件建议用命令行（流式读取），20 MB 以上在浏览器里算会明显卡顿。

六、直接算

→ CRC32 校验：文本/字节的 CRC-32 值，十六进制与十进制并列显示

→ 文件哈希计算：选文件或贴文本，一次给出 MD5、SHA-1、SHA-256

→ SHA-256 生成：单算法详细输出，含字节数

→ MD5 生成：大写形式与 16 位短码