— 输入上方文本以获取哈希值 —— 输入上方文本以获取哈希值 —— 输入上方文本以获取哈希值 —— 输入上方文本以获取哈希值 —— 输入上方文本以获取哈希值 —— 输入上方文本以获取哈希值 —关于 哈希生成器
校验文件是否被完整传输、比对两段文本是否一致、给内容生成一个固定长度的指纹，这些都属于哈希的用途。典型场景包括：下载页给出 SHA-256 供用户核对安装包、日志系统按内容哈希去重、接口用摘要判断缓存是否失效、教学时演示雪崩效应（改一个字符输出面目全非）。 哈希函数的原理是把任意长度的输入压缩成固定长度的输出（摘要），并且满足三条性质：同样的输入永远得到同样的输出、不同输入极难得到同一输出（抗碰撞）、无法从输出反推输入（单向）。本工具用浏览器原生的 Web Crypto 计算 SHA-1、SHA-256、SHA-384、SHA-512，MD5 与 RIPEMD-160 则用本地实现补足。 使用要点：核对下载文件时，必须同时核对算法与摘要值，只对摘要不对算法等于没校验；很多发布方同时给出 SHA-256 和 SHA-1，应优先按 SHA-256 比对。计算文件哈希要读整个文件而不是文件名，注意某些系统会在下载时自动改写换行符（CRLF 与 LF 的差异会改变哈希），文本类文件的哈希因此天然脆弱。 边界与限制：MD5 与 SHA-1 都已经存在实用化的碰撞构造，可以用于「传输是否出错」的完整性核对，但不能用于签名、口令存储或防篡改——这些场景必须从 SHA-256 起步。另一个常见误解是把哈希当加密：哈希不可逆，没有任何「解密」操作，忘掉的口令只能重置而不能还原。口令场景还必须使用带工作因子的算法加盐（见 bcrypt 工具），无盐的 SHA-256 在现代 GPU 上每秒可尝试数十亿次。 数据与隐私：需要计算哈希的内容经常是口令、身份证号、带签名的令牌或未公开的文档。哈希本身不可逆，但如果原文很短（如六位数字口令），攻击者可以穷举所有候选并逐个比对摘要，因此把「明文 + 摘要」一起上传仍然等于泄露。本工具全程在浏览器内计算，原文不离开设备；你可以断开网络后使用，或观察网络面板确认没有任何请求发出。
算法选择与工程实践上有几条经验。文件校验用 SHA-256 已经足够，需要更强抗碰撞时可以上 SHA-512 或 SHA-3；MD5 与 SHA-1 只在对接遗留系统、且对方只支持这两种时保留，并在文档中注明这是兼容性妥协而非安全选择。大文件不要先读进内存再算哈希，流式分块喂给摘要函数即可，几十吉字节的镜像也能在普通机器上完成。做「内容是否变化」的判断时留意换行规范化：同一份文本在 Windows 与 Linux 上因 CRLF 与 LF 的差异会得到不同摘要，跨平台使用的清单文件应在生成时显式规定行尾。最后，把哈希当作唯一标识使用时要注意理论碰撞虽极难出现，但用截断摘要（如前 8 位）做去重键会显著提高碰撞概率，去重键应当保留完整摘要或改用更长的长度。
另外要区分哈希与校验和：CRC32 之类的校验和用于发现传输中的随机位翻转，速度快但极易被构造出冲突，因此只能作为快速筛查；判断「内容是否被恶意替换」必须使用密码学哈希。两者混用会把安全判断建立在脆弱的假设上。
实现原理
散列把任意长度输入压缩成固定长度输出，并保证同输入同输出、不同输入极难同输出、且无法从输出反推输入。所谓「雪崩效应」正是这三条性质的表现：输入改一个比特，输出约一半比特翻转。它是单向的，因此不存在「解密」这一步，忘记原文只能重置而不能还原。
abcba7816bf8f01cfea…（完整摘要 64 个十六进制字符）使用方法
- 打开文本哈希工具
- 在输入框中粘贴要哈希的文本
- 自动计算并显示 MD5、SHA-1、SHA-256、SHA-512 等哈希值
- 支持文件哈希：切换到文件模式上传文件
- 点击哈希值旁的复制按钮获取结果
使用场景
- 校验文件完整性 — 比对下载文件的 SHA-256，与官方公布值一致才能确认未被篡改。
- 密码存储前预处理 — 配合 salt 使用，但密码存储建议使用 bcrypt（本站「Bcrypt 哈希」工具）。
- Git commit 验证 — Git 用 SHA-1 标识 commit，本工具可手动复算验证 commit 内容。
- API 签名计算 — 配合 HMAC（本站「HMAC 生成器」）生成请求签名。
- 去重 / 缓存 key — 用内容哈希做缓存 key，相同内容只存一份。
常见问题
SHA-1 还能用吗？
密码学场景已不安全（2017 年 Google 公布碰撞攻击），但用于校验和、Git commit ID 等非对抗场景仍可。
SHA-256 和 SHA-512 哪个更安全？
都足够安全。SHA-512 输出更长（128 位十六进制 vs 64 位）但计算稍慢，绝大多数场景用 SHA-256 即可。
为什么没有 MD5？
MD5 早已被破解（2004 年王小云团队），不建议任何新代码使用。如确需 MD5，浏览器原生 API 也不再提供。
同一段文本每次计算结果都一样吗？
是的。哈希函数是确定性的——相同输入永远输出相同哈希，这正是它能用于校验的原因。
能从哈希反推原文吗？
不能。哈希是单向函数，无法从输出反推输入。但短弱密码可被字典或彩虹表攻击，这就是为什么密码存储要用 bcrypt+salt。
为什么同样的密码两次算出的哈希不一样？
因为加了盐（salt）。哈希本身是确定性的，但密码校验系统通常在每次注册或改密时生成随机盐拼进原文再计算，使相同密码得到不同摘要，从而抵御彩虹表与相同密码关联分析。盐一般随哈希一起保存（如 bcrypt 的盐前缀），校验时取出盐重新计算比对。若两次结果不同且格式里没有盐的痕迹，多半是输入编码或是否追加了换行符不一致，先统一 UTF-8 再试。
同一段文本在不同工具算出的哈希为什么不一样？
多半是编码或空白差异：UTF-8 与 UTF-16、大小写、末尾换行、首尾空格都会改变参与计算的字节，摘要自然不同。例如 Windows 记事本保存的文件可能带 BOM 或 CRLF，与 Linux 的 LF 结尾字节不一致。排查时把输入按十六进制查看、确认字节级完全一致，再统一为 UTF-8 加 LF 换行，任意工具都会得到相同结果。
同一文本每次计算的哈希都一样，这不是不安全吗？
哈希函数是确定性的，同输入必同输出——这正是它能用于校验完整性的原因。不安全的是「直接拿密码哈希当验证」而非加盐：盐让同一密码在不同用户/系统下产生不同哈希，从而抵抗彩虹表。