🔐 哈希与校验和计算器（MD5 · SHA-256 · CRC32 · 文本和文件一次算全）

这几行分别是什么

四行 SHA 和两行 HMAC 都走 crypto.subtle，也就是浏览器自己那套实现，和 TLS 用的是同一个原语；MD5、CRC32、Adler32 由脚本现场算出来——浏览器没有 MD5，而 JavaScript 写一个 CRC32 就是三十行查表。

算的是字节，不是文字

这些算法吃的都是字节串。你算"你好"的 MD5，实际算的是它在 UTF-8 下的六个字节；同样的字用 GBK 存，摘要就完全另一个。所以遇到对不上的情况，先把整份文件当字节看：文本文件多一个结尾换行、Windows 把 \n 写成 \r\n、下载器中途补过一次请求，改的都是字节，摘要跟着全变。页面上方写着"参与计算的字节数"，就是为了让你一眼看见到底喂进去了多少个字节，而不是对着一堆十六进制猜。

跟官方公布的校验和比对

把拿到的那串贴进第四个框，比对前会自动洗掉空格、冒号、短横和 SHA256= 这种前缀——命令行工具爱写成 SHA256（文件）= …，全角的括号和冒号也照样认。大小写不敏感。之后"比对"那一列直接告诉你它是哪个算法——这本身就有信息量：别人给你的 32 个字符，可能是 MD5，也可能是同一份 MD5 的另一种字节。如果哪一行都对不上，下面的提示会说清你贴进来的长度：长度不匹配是算法不同，长度匹配却没对上，是字节不同。

CRC32 不是哈希

校验和回答的是"字节有没有意外改掉"，密码学哈希回答的是"别人能不能主动造出一份摘要相同的字节"。CRC32 是线性的：算出四个补字节附在后面，校验和原样不变——zip 里的条目能改而 CRC 不动，就是这个原因。Adler32 是两次模 65521 的求和，对结构化数据更弱。用来发现下载断了，两者都刚刚好；用来证明没人动过手脚，两者都不够格。

MD5 和 SHA-1 坏在哪里

“坏"指的是碰撞：可以为两个不同的输入做出同一个摘要。MD5 在普通笔记本上是几分钟的事；SHA-1 在 2020 年被云算力做出来（SHAttered 那对文件），后来的 chosen-prefix 碰撞已经能拿去伪造证书。原像攻击对两者仍然遥不可及，所以拿 MD5 当缓存键没问题，拿它签软件就是问题。SHA-256 至今没有任何公开的攻击，安全裕度足够，这就是下载页现在清一色写 sha256sum 的原因。

HMAC：为什么密钥那两行单列

HMAC-SHA256(消息, 密钥) 不等于 sha256(密钥 + 消息)，这个差别正是它存在的全部理由。简单拼接会被长度扩展攻击利用：拿到公开的摘要，不用再知道密钥就能往后继续算。HMAC 把掩过密钥的分组哈希了两遍，没有密钥的人既伪造不了也延长不了。Webhook、支付回调签名、JWT 用的都是这套构造——把共享密钥填进密钥框，最后两行就出来了。

常见问题

SHA 那几行为什么显示"不给用”？ crypto.subtle 只在安全上下文里存在（https://，或者本地直接双击打开的 file://，多数浏览器认它是安全的）。用普通 http:// 从别的机器上访问就会被关掉。MD5、CRC32、Adler32 是脚本自己算的，照常能看。

多大的文件还能算？ 256 MB 以内。再大就该走命令行——摘要完全一样，上面提示里给了对应的命令。

我输入的文字、我选的文件会传上去吗？ 不会。脚本里没有 fetch，没有 XMLHttpRequest，也没有任何带内容的统计请求，哈希就在本地 JS 里对着从你磁盘读到的字节算，输入的内容不会离开这台设备。