安全
SHA 哈希生成器
调用浏览器原生的摘要实现，几 MB 的文件也在毫秒内算完，适合校验下载文件的完整性。
哈希值会显示在这里。
怎么用
- 粘贴文本，或选择一个文件——选择文件时计算的是文件字节。
- 选择算法。日常用 SHA-256；SHA-1 只用于兼容旧校验值。
- 点「哈希」。哈希相同只能证明输入字节完全一致。
哈希不是加密
加密可以用密钥还原，哈希完全不可逆。哈希是定长的指纹，你真正依赖的性质是：找到另一个输入产生同样的摘要在计算上不可行。MD5 和 SHA-1 已经提供不了这个性质了——可用的碰撞分别在 2004 年和 2017 年被演示出来，所以两者都不该再用于签名、证书或完整性校验，尽管老系统里仍然到处能见到。
为什么快哈希不适合存密码
在这里，快是缺点。一块现代 GPU 每秒能试几十亿个 SHA-256 候选值，而预先算好的彩虹表直接覆盖常见密码。所以密码存储要用刻意设计得慢、且吃内存的函数——bcrypt、scrypt、Argon2——并且每个用户一个盐，让相同的密码产生不同的摘要。如果在存密码却用着 SHA-256，换掉它是你能做的最有价值的一件事。
核对手上的下载文件
发布方在文件旁边给出 SHA-256，你在本地算一遍，对比两串字符，流程就完了。对比时看头八位和末八位，而不是通读 64 个十六进制字符——不一致几乎总出现在两端，而抄错比被篡改常见得多。
下载页上仍然能看到 MD5 和 SHA-1，通常只是没人去更新。它们用来发现传输损坏没问题，但对付任何有动机的攻击者都无用：MD5 的选择前缀碰撞，如今只要几美元的 GPU 时间。
常见问题
哈希能反解吗？
不能。哈希是单向指纹，只能把猜测的原文再算一遍来对比。
SHA-1 还能用吗？
不能用做签名等安全场景，实际碰撞已被构造出来。它残留在旧校验值和 git 对象 ID 里。
为什么同一段文本结果永远一样？
哈希是确定性的：同样的字节，在任何机器上都得到同样的摘要。这正是它能用来校验的原因。
同一段文字，两个工具算出的 MD5 为什么不同？
几乎总是换行或编码差异：其中一个把结尾换行、或把带 BOM 的 UTF-8 一起算了进去。要对字节求哈希，而不是对肉眼看到的字符。
哈希可以被逆向吗？
设计上不能。攻击者的做法是猜输入——之所以有效，是因为多数密码本身好猜，不是因为哈希弱。