文件哈希计算

哈希值到底是干什么用的

最常见的是校验完整性：软件站给出一个 sha256，下载完自己算一遍对一下，一致就说明文件在传输过程中没有损坏，也没有被人悄悄替换。镜像站、Linux 发行版 ISO、Maven 中央仓库都提供这种校验和。第二类用途是「秒传」：网盘先算出文件哈希，如果服务器上已经有这个哈希，就不用再上传一遍，直接从已有文件复制一份给你。第三类是在数据库里存密码，但那要用专门的慢哈希（bcrypt、scrypt、Argon2），不能拿这里的 SHA-256 直接存。

Git 也用哈希给每个对象编号。Git 早期用 SHA-1，后来因为构造碰撞攻击的成本降到了可接受范围，社区一直在往 SHA-256 迁移，新仓库已经可以选 sha256 对象格式。

MD5 和 SHA-1 已经不安全，但校验时还在用

这里说的不安全是指「抗碰撞性」被攻破：攻击者能造出两个内容不同、哈希值却相同的文件。MD5 早在 2004 年就被王小云团队破解，2008 年就有人用碰撞伪造了 CA 证书；SHA-1 在 2017 年被 Google 的 SHAttered 项目公开碰撞（两个不同的 PDF 算出同一个 SHA-1）。所以不要把 MD5/SHA-1 用在签名、证书、密码这类需要主动对抗攻击者的地方。

但作为「防传输损坏」的校验和，它们仍然够用，因为损坏是随机比特翻转，不是人为构造的碰撞。很多老系统（老版本的下载页、Maven 仓库的 .md5 文件、AWS 的 ETag）也只提供 MD5，所以这个工具还是把它放在第一位。真要防篡改，请用 SHA-256 或更强的算法，并且从可信渠道获取校验值本身——如果哈希和文件来自同一个被黑的页面，那对上了也说明不了什么。

哈希相同不代表文件一定相同

哈希是定长的摘要，SHA-256 把任意长度输入压成 256 位，也就是 2²⁵⁶ 种可能，理论上存在无限多组不同文件共用一个哈希值，这叫碰撞。概率上完全随机碰撞的可能低到可以忽略（远比硬盘静默出错小），但如果对方是蓄意构造的，MD5 和 SHA-1 的碰撞是可以在普通电脑上算出来的。所以「哈希一致」在正常场景下可以放心当作「内容一致」，在对抗场景下则要选更长的算法。

还有两个容易踩的点：一是哈希算的是字节，不是内容。同一个文本文件，Windows 存成 CRLF、Linux 存成 LF，哈希完全不同；给文件加一行注释、改一次保存时间，哈希也会全变。二是文件名不参与计算，把 a.zip 改名成 b.zip，哈希一模一样——所以校验清单里必须带上文件名，不能只看哈希列表。

关于性能与隐私

整个计算过程在浏览器里完成，文件一个字节都不会发到服务器（你也可以断网验证：加载完页面后拔掉网线，功能照常）。MD5 是自己按 RFC 1321 实现的增量版本，读取时按 64 KiB 分块喂进去，所以算一个 2 GB 的文件内存占用也只有几 MB；SHA 系列走浏览器内置的 crypto.subtle.digest，它只有一次性接口，必须把整块数据准备好，这就是上面提示大文件的原因。手机浏览器对大文件哈希会比较吃力，30 GB 以上的文件建议改用命令行：sha256sum 文件名。