关于 哈希与校验和计算
哈希与校验和生成器对你输入的文本或选中的文件计算 MD5、SHA-1、SHA-256、SHA-384、SHA-512 摘要，并以小写十六进制输出。它只回答一个问题：在发布方使用的算法下，这两段字节序列是否完全相同？
哈希是单向指纹，不是加密。它没有密钥、没有逆运算，所以「解密摘要」这件事根本不存在，攻击者做的是猜输入再比对。「被攻破」同样需要分辨：MD5 和 SHA-1 被攻破的是抗碰撞性，即有人能构造出摘要相同的两份不同文件，但没有人能拿着你的摘要还原出你的文件。
如何使用这个开发者工具
- 选择发布方使用的算法。只有在同一算法下比较，摘要才有意义。
- 在文本区输入或粘贴内容，或用文件选择器处理本地文件，单个文件上限 64 MB。
- 执行计算，原样复制十六进制字符串，不要额外添加首尾空白。
- 把两个值粘进文本比较工具做比对，不要用肉眼核对 128 个十六进制字符。
- 保存摘要时把算法名一并记下。没有注明算法的十六进制串，不构成可验证的声明。
实例：同一行文本，三个不同的摘要
一个只有 hello world 一行的文件，分别以不带结尾换行、带 Unix 换行、带 Windows 换行的方式保存。在人看来内容毫无变化。
hello world 11 字节，无结尾换行
hello world + LF 12 字节，Unix 换行
hello world + CRLF 13 字节，Windows 换行b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
572a95fee9c0f320030789e4883707affe12482fbb1ea04b3ea8267c87a890fb这是官方校验和对不上的头号原因：文件提交进 Git 后，在开启 core.autocrlf 的环境里检出，字节已与维护者当初计算时的那份不同。请对真正分发出来的产物计算摘要，而不是解压后再存一遍的副本。
各摘要算法今天还适合用在哪里
本工具提供前五行。表中的「已攻破」一律指抗碰撞性，即攻击者能构造出摘要相同的两个输入。这些算法都还没有可行的原像攻击，这也是老算法仍可用于检测意外损坏的原因。
| 算法 | 摘要长度 | 抗碰撞性 | 今天的用途 |
|---|---|---|---|
| MD5 | 128 位 / 32 个十六进制字符 | 2004 年起已攻破，2009 年起可做选定前缀碰撞 | 仅用于损坏检测和缓存键 |
| SHA-1 | 160 位 / 40 个十六进制字符 | 2017 年起实际可碰撞 | 仅用于兼容遗留系统，不可用于新设计 |
| SHA-256 | 256 位 / 64 个十六进制字符 | 无已知弱点 | 完整性校验与签名的默认选择 |
| SHA-384 | 384 位 / 96 个十六进制字符 | 无已知弱点 | SHA-512 的截断版，常见于 TLS 与 SRI |
| SHA-512 | 512 位 / 128 个十六进制字符 | 无已知弱点 | 在 64 位 CPU 上往往比 SHA-256 更快 |
| SHA-3、BLAKE2、BLAKE3 | 通常 256 位 | 无已知弱点 | 本工具未提供，请用命令行 |
常见问题排查
文件摘要和项目公布的值对不上。
成因 内容看着一样，字节却不同。最常见的是换行符转换，其次是编辑器补上的结尾换行，再次是对解压后的内容而非被签名的压缩包做了摘要。
解决办法 下载后先算摘要再做任何处理；纳入 Git 的文件把 core.autocrlf 设为 input，让检出不改写换行。
公布的校验和比工具输出短，而且带有 + / 和 = 号。
成因 那是同一个摘要的 Base64 形式，不是十六进制。npm 的 integrity 字段和子资源完整性属性用的都是原始摘要字节的 Base64。
解决办法 用进制与编码转换工具互转。上面 LF 那一行的摘要，十六进制是 a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447，Base64 是 qUiQTy8PR5uPgZdpSzAYSw0u0cHNKh7A+4XSmaGSpEc=，同一个值，两种写法。
同一段文本，在这里算出的摘要和命令行不一样。
成因 echo 会补一个换行，算的是 12 字节；而文本区只对你输入的 11 个字符按 UTF-8 编码计算。
解决办法 要和浏览器端对照时请改用 printf '%s' 或 echo -n；仍然不一致就先核对两边的字节数。
校验和对上了，下载的东西却仍然被篡改过。
成因 校验和与文件来自同一个页面、同一条连接。能替换其中之一的人也能替换另一个。
解决办法 威胁是「被替换」时应验证签名而不是校验和，并通过独立渠道核对发布方的密钥；证书解析工具能告诉你一条证书链到底声明了什么。
适合用这个工具的场景
- 用发布方公布的校验和验证下载到的发行包。
- 确认文件在传输、备份恢复或存储迁移之后没有发生变化。
- 实现或调试哈希逻辑时，复现一个已知的测试向量。
- 为缓存、去重表或 ETag 生成稳定的内容键。
应该换用别的工具的场景
- 存储用户密码。裸 SHA-256 算得太快，而这正是拿到数据库的攻击者想要的；htpasswd 条目生成器会给出 bcrypt 校验值。
- 让数据不可读但仍可还原。这件事需要加密：哈希没有密钥也没有逆运算。
- 证明文件出自谁手。摘要只能说明字节与某人公布的值一致，归属问题需要签名。
隐私与数据处理
SHA 系列由浏览器内置的 WebCrypto 实现计算，MD5 由打包进页面的库计算。文件字节通过 File API 在本地读取：不上传，关闭标签页后不留痕迹。有一点对所有哈希工具都成立：可猜测的值，其摘要本身就是一把查找键，所以在这里对真实密码做哈希并不能保护它。
相关开发者工具
常见问题
哈希能被逆推回去吗？
无法通过求逆得到——函数丢弃了信息，也没有密钥。但取值空间很小的输入可以被穷举：一个六位密码的 SHA-256 在普通硬件上几秒就能跑穿。
MD5 现在是不是完全不能用了？
凡是攻击者能施加影响的场景都不能用，因为碰撞构造成本很低。但用于检测复制过程中的意外损坏，或者对自己掌控的数据做缓存键，它依然够用而且快。
为什么我的文件摘要和服务器的不一样？
任何一个字节都算数：换行符、字符编码、结尾换行，甚至压缩包内嵌的时间戳。请确认两边对的是同一个产物、同一个阶段，并且用了同一个算法。
超过 64 MB 的文件怎么办？
这个上限源于浏览器必须把字节整份装进内存。更大的文件请用 shasum -a 256，Windows 上用 certutil -hashfile——它们分块读取，不需要整体载入。
SHA-512 比 SHA-256 更安全吗？
它的抗碰撞余量更大，但 256 位早已远超任何暴力破解的预算，实际差别等于没有。按协议要求选即可；在 64 位 CPU 上 SHA-512 往往还更快。
文本区会带上结尾换行吗？
不会。它严格按 UTF-8 编码输入框里的字符。如果需要结尾换行才能与某个文件的摘要一致，这个差异来自文件本身。