哈希计算器
一次算出 MD5 / SHA-1 / SHA-256 / SHA-512 四个摘要。文本和文件都支持,全部在本地算完 —— 文件一个字节都不会上传。要的只是"传坏了没有",去 CRC32 校验 更快。
| MD5 | — | |
| SHA-1 | — | |
| SHA-256 | — | |
| SHA-512 | — |
—
哈希不是加密
加密可以还原,哈希不能。无论输入多长,输出都是固定长度的一串,而且无法从这串反推出原文。所以它适合做"完整性校验"和"指纹",不适合做"把内容藏起来" —— 要藏内容得用真正的加密。也正因为不可逆,它不该被拿来存密码:同样的一次 SHA-256 在显卡上每秒能算几十亿次,存密码要用专门的慢哈希(bcrypt / scrypt / Argon2)。
MD5 和 SHA-1 现在还能用吗
看你要防什么。 防"文件传坏了",两者都还好用,而且快。防"有人故意改过",两者都不行 —— MD5 的碰撞攻击 2004 年就实用了,SHA-1 在 2017 年也被实际构造出来。这一页把它们和 SHA-256 / SHA-512 并排给出来,是为了让你比对老系统里已有的值,不是为了推荐你用它们。新东西一律用 SHA-256。
算的是字节
同一段中文,按 UTF-8 和按 GBK 编码出来的字节完全不同,摘要自然也不同。这一页一律用 UTF-8,所以拿它和一个按 GBK 算出来的值比会「对不上」—— 那不是谁算错了。文件没有这个问题。
常见问题
因为 SHA 那一族用的是浏览器自带的 crypto.subtle,而它只在安全上下文(HTTPS 或 localhost)里可用。这是浏览器的规定,不是这一页的限制。MD5 是页面自己实现的,不受影响 —— 所以在不满足条件的环境里,你会看到 MD5 有值、另外三个是破折号。
不会。 文件由浏览器读进内存(File.arrayBuffer()),摘要在本页算完,全程没有网络请求。断网也能用。
上限 128 MB,原因和 CRC32 那一页一样:整份文件要先进内存。再大的文件请用命令行的 sha256sum / certutil -hashfile,它们可以流式处理。
最可能是编码不同:那一侧可能按 GBK 或 UTF-16 算的。其次是末尾多了换行。先用一段纯 ASCII 的短文本(比如 abc)对一下 —— 它应当得到 900150983cd24fb0d6963f7d28e17f72,对得上说明两边算法没问题,差别在输入的那几个字节上。
