哈希与文件校验怎么选

4 个决策要点 · 涉及 7 款工具 · 哈希与校验 · 内容最后核对 2026-10-25

MD5 还能用，但不能用在所有地方——先分清你要防的是「传输出错」还是「有人动手脚」。

一句话结论

防随机损坏：CRC32 / MD5 够用且快；防人为篡改：用 SHA-256 及以上；存密码：必须 bcrypt / argon2，绝不能直接 MD5。

「用 MD5 还是 SHA-256」——这个问题的答案取决于你在防什么。如果你的目标是确认一个文件在下载过程中有没有损坏，MD5 完全够用，而且算得快；但如果你要防止有人刻意伪造一个哈希值相同的恶意文件，MD5 早就不可靠了。同一个算法，在两种场景下的结论完全相反，所以先想清楚威胁模型比记算法名字更重要。

哈希算法可以按「能不能抗人为碰撞」排一条线：CRC32 连密码学哈希都不算，它只能发现随机错误；MD5 和 SHA-1 曾经是安全哈希，但如今已被证明能构造出碰撞，不适合对抗有意的篡改；SHA-256 及以上目前仍是安全的。而存密码是另一个领域——那里不该用「快速哈希」，反而要用故意很慢、并加盐的算法。下面按用途分开说。

选型对照表

看逐项详解 →

你要做的事	推荐工具	推荐算法 / 原因	注意
确认下载的文件有没有损坏	文件哈希校验	MD5 / SHA-256 均可，与官方公布值比对	先确认官方公布的哈希是从可信渠道拿到的
防止有人伪造内容相同的文件	文件哈希校验	SHA-256 或更强；MD5/SHA-1 已可构造碰撞	碰撞攻击需要精心构造，但不代表做不到
快速检查传输错误	CRC32 校验工具	CRC32 极快，对随机位翻转敏感	它不是密码学哈希，不能防篡改
计算一段文本的指纹	Hash生成器	按用途选：校验用 SHA-256，非安全场合 MD5 也行	同一输入永远得到同一结果，这是特性也是风险
为 Apache 生成 .htpasswd 密码行	.htpasswd生成器	务必用 bcrypt 或 APR1，不要用明文	明文口令等于没设密码
校验两个文本内容是否完全一致	文本对比	逐字符比对比哈希更直观	哈希只能告诉你「一不一样」，不能指出差异在哪
校验 JSON 结构是否被改动	JSON比较工具	结构化对比，忽略无意义的格式差异	配合键排序工具消除键序造成的假差异
生成不容易被猜测的密码	密码生成器	生成端与校验端是两件事	再强的密码，存储方式不对也会被拖库破解

表格中列出的工具均可直接点击进入，全部免费、无需注册。

逐项详解

全部工具总览 →

1先分清：随机损坏 vs 人为篡改

这是选哈希算法的唯一决策点。网络传输中的比特翻转、磁盘坏道、内存错误造成的都是「随机损坏」，这类错误的特征是均匀、无目的，任何具备良好雪崩效应的哈希（甚至 CRC32）都能敏锐地检测出来。而「人为篡改」是有攻击者主动构造的：他可以让一个恶意文件和一个正常文件的 MD5 值完全相同，从而骗过只校验 MD5 的机制。对抗这类攻击需要算法本身具备抗碰撞性，也就是 SHA-256 及以上。所以：下载镜像选源、光盘归档、内部传输 → 便宜快速的算法就够；软件发布、代码签名、安全审计 → 必须用强哈希。

文件哈希校验 CRC32 校验工具

2CRC32 的定位：它不是加密哈希

CRC32 经常和 MD5 放在一起比较，但两者的设计目标不同。CRC 是为「检测传输错误」设计的校验码，本质是多项式除法取余，计算极快、实现极简（网络协议、压缩格式、存储设备里到处都是它）。它没有任何密码学性质：既不能抗碰撞，也不具备单向性。所以它的正确用法是快速验证「数据在链路上有没有出错」，绝不能用来判断文件是否被恶意替换，更不能用来存密码。

CRC32 校验工具

3存密码是另一个世界：要慢、要加盐

哈希的通用价值是「快」，但存密码恰恰相反——我们希望它「慢」。因为攻击者拿到哈希库后会做离线暴力枚举，如果算法足够快，他每秒能试上亿次；如果算法被设计成每次计算要几十毫秒，攻击成本就被抬高了几个数量级。这就是 bcrypt、scrypt、argon2 存在的意义：它们是「慢哈希」，还内置了随机盐，让相同密码产生完全不同的哈希值，从而让彩虹表失效。直接对密码做 MD5 是安全实践中典型的错误做法，Apache 的 .htpasswd 之所以默认用 bcrypt，原因就在这里。

.htpasswd生成器密码生成器

4校验文件的操作顺序

用哈希校验文件时，顺序很重要。第一步，从可信渠道获取官方公布的哈希值——如果哈希和文件是从同一个被攻陷的页面下载的，校验就失去了意义。第二步，用文件哈希工具对本地文件计算摘要，注意核对算法是否与官方一致（有的是 MD5，有的是 SHA-256，还有的会同时给多种）。第三步，逐字符比对——注意大小写差异，有些工具输出大写，官方给的是小写，这只是显示格式不同，不影响结果。如果只差一两个字符，说明文件确实不同，不要抱侥幸心理。

文件哈希校验 Hash生成器

关于「哈希与文件校验怎么选」的常见问题

MD5 现在完全不能用了吗？

不是完全不能用，而是不能用在需要对抗人为篡改的地方。用于检测随机损坏（下载出错、磁盘坏道），MD5 依然灵敏且快速，没有任何问题。但因为它已被证明能构造碰撞——攻击者可以造出两个内容不同而 MD5 相同的文件——所以软件发布、安全校验、数字签名这类场景必须换成 SHA-256 或更强。关键是想清楚你在防什么。

SHA-1 和 SHA-256 差在哪里？为什么 SHA-1 也要被淘汰？

主要差在输出长度和抗碰撞强度：SHA-1 输出 160 位，SHA-256 输出 256 位。SHA-1 也已被实际构造出碰撞（研究者演示过两份内容不同但 SHA-1 相同的 PDF），主流浏览器和证书颁发机构早已停止签发 SHA-1 证书。新项目一律用 SHA-256 起步，不要为了「兼容」而继续使用 SHA-1。

CRC32 和 MD5 有什么本质区别？

CRC32 不是密码学哈希，它的设计目标是快速检测传输错误，本质是多项式除法，计算极快但没有任何抗碰撞或单向性保证。MD5 是为密码学设计的哈希，具备单向性，只是抗碰撞性已被攻破。两者都不能用于密码存储，也都不能对抗精心构造的篡改；但两者都能发现随机错误，其中 CRC32 更轻量。

文件哈希对得上，是不是就一定安全？

不一定。哈希校验只能证明「你拿到的文件与我拿来比对的哈希值一致」，它有两个前提：哈希值本身来自可信渠道，且算法足够强。如果官方哈希和文件都发布在同一个被攻陷的页面上，攻击者可以同时替换；如果用的是 MD5，攻击者可能构造出哈希相同的恶意文件。所以哈希校验是必要环节而非充分保证，发布方还应当使用数字签名。

为什么 .htpasswd 里不要写明文密码？

因为 .htpasswd 文件一旦被读取（配置错误、备份泄露、目录遍历漏洞），明文密码就直接暴露，还可能被拿去撞其他系统的账号。正确做法是写入 bcrypt 或 APR1 哈希，即使文件泄露，攻击者也需要付出极高的计算成本才能还原。本站的 .htpasswd 生成器默认采用安全哈希，请不要手动改成明文。