使用 Web Crypto API 在浏览器内计算你输入文本的 SHA-256 与 SHA-1。输入不会被上传。哈希不是加密——并非「缺少还原用的钥匙」，而是还原所需的信息本身就被丢弃了。但这并不意味着「安全」——只要可能的输入集合有限，把它们逐一算过去比对，原值立刻就能还原。

情形	会发生什么	怎么处理
拿 SHA-256 来保存密码	SHA-256 的设计目标就是「快」。校验文件完整性时越快越好——但拿它来保存密码，这份速度就直接成了攻击者的武器。现代 GPU 每秒能算数十亿次 SHA-256，因此八位字母数字的密码，暴力破解几小时内就能拿下。加盐也不改变这一点：盐能让彩虹表失效、避免相同密码产生相同哈希，但对单个账户被暴力破解的速度毫无影响。	密码请使用 `bcrypt` / `scrypt` / `Argon2id`。它们被刻意设计成又慢又吃内存——吃内存这一点很关键，因为GPU 每个计算单元分到的内存很少，这就抹掉了它的并行优势。请不要自创「SHA-256 加盐再迭代一万次」的方案——直觉没错，但这套构造早已标准化为 `PBKDF2`，而自己手写的实现必定在某处出错。截至 2026 年，推荐 `Argon2id`；若语言或框架不提供，则退而使用 `bcrypt`。
同一段文本，在别的工具里算出的值不一样	哈希函数接收的是字节序列，而不是字符。因此看起来完全相同的文本，只要有一个字节不同，结果就是彻底不同的。实务中的原因几乎总是这四种之一：末尾的换行、换行符是 LF 还是 CRLF、有没有 BOM、字符编码是 UTF-8 还是别的。shell 是最典型的：`echo "abc" \| sha256sum` 算的是含换行在内的 4 个字节，而不是 `abc` 的 3 个字节。	在 shell 中请使用 `printf %s abc \| sha256sum`，它不会追加任何多余字节（避免用 `echo -n`，其行为因环境而异）。两边对不上时，先数一数各自的字节数——`wc -c` 或 `xxd` 能立刻暴露 1 个字节的差异。API 签名校验不通过，根源也几乎相同：请确认待签字符串的拼接顺序、分隔符、末尾换行，以及重新序列化 JSON 是否改变了键顺序或空白。不要假定「应该一样」，去比对真实的字节序列，是唯一的解法。
一直沿用着 SHA-1	SHA-1 的碰撞不是理论问题：2017 年 Google 与 CWI 公开了内容不同却具有相同 SHA-1 的两份 PDF（SHAttered）。到 2020 年，选择前缀碰撞已进入可承受的成本范围——这是强得多的攻击：可以让两份文档各自保持你想要的内容，同时发生碰撞。Git 至今仍用 SHA-1，是因为「能构造碰撞」和「能攻击 Git」是两个不同的问题，而不是因为 SHA-1 依然稳固。	新做的东西一律用 SHA-256 或更强。对既有的 SHA-1，请按用途判断：用于防篡改、签名、证书的必须迁移；而 ETag、缓存键、分片这类「撞了也无所谓」的用途并不急。这个区分很重要，因为试图把所有 SHA-1 一刀切地替换掉，反而会让你腾不出手去处理真正危险的地方。判断标准只有一个问题：攻击者在这里刻意制造碰撞，能捞到什么好处吗？捞不到就放着；捞得到就最优先修。

「做了哈希所以已经匿名化」这种说法站不住脚。把邮箱地址或电话号码的 SHA-256 当作非个人信息来共享是危险的：电话号码来自有限空间（日本手机号不足十亿种），全部算一遍再比对，几分钟就能还原。邮箱地址对着已知地址清单一比，也是一样。这正是广告行业真实出过问题的路径，哈希只有在输入空间实质上无限时才构成匿名化。若确实需要一个可比对的标识符，请使用带密钥的 HMAC——没有密钥的一方就无法暴力枚举（代价是你要额外承担密钥管理的责任）。在采用「把哈希作为 ID 公开」的设计之前，请切实估算一下穷举那个输入空间需要几个小时。

📖 使用方法

1

输入要哈希的文本

在输入框中输入文本,SHA-256 和 SHA-1 实时计算。
2

查看哈希值

显示 SHA-256 和 SHA-1 哈希值。
3

复制使用

点击复制按钮复制哈希值。

❓ 常见问题

应该用 SHA-256 还是 SHA-1?

安全敏感场景请用 SHA-256。SHA-1 存在已知碰撞漏洞。

哈希值是单向的吗?

是。哈希是单向的,但短文本可能被彩虹表查询。

我的输入会发送到服务器吗?

不会。哈希计算完全在浏览器中通过 Web Crypto API 进行。

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。

文本哈希计算（SHA-256 · SHA-1）

其他工具

相关文章

📖 常见的坑

📖 使用方法

❓ 常见问题

感谢您的反馈！