跳转至

Hash 生成器

纯前端：输入文本，勾选算法，立即算出 MD5 / SHA-1 / SHA-256 / SHA-384 / SHA-512。数据不出浏览器，不联网、不记录。

怎么用

在下面输入或粘贴文本，勾选要算的算法（可多选），点击 计算，下方按算法分行给出十六进制摘要。所有计算都在你浏览器本地完成。

运维里哈希到底用来干嘛

哈希不是炫技，是日常好几处的底座：

  • 文件完整性校验：下载安装包、镜像、备份后，比对官方给的 SHA-256，确认没传坏也没被替换。
  • 日志与配置指纹：给一段日志或配置算个摘要，下次同样内容摘要不变，内容稍有改动摘要立刻不同，适合做快速比对和去重。
  • 接口签名：很多 API 把请求参数拼接后哈希，作为签名防篡改，服务端用同样算法复算比对。
  • 缓存键与去重：把长 URL 或长文本哈希成短键，作为缓存或布隆过滤器的输入。

MD5 / SHA-1 还能用，但有边界

这点必须说清楚，避免误用：

  • 完整性校验还能用：你只是想确认「文件有没有传坏」，MD5 够快够用，碰撞攻击在这里没意义——攻击者没法在你下载的瞬间替换文件还保持 MD5 一致。
  • 安全场景不能用：涉及防篡改、数字签名、口令存储，MD5 和 SHA-1 都已能被低成本构造碰撞，必须上 SHA-256 及以上。
  • 口令绝不直接存哈希：哪怕用 SHA-256，直接哈希口令也扛不住彩虹表。口令要 bcrypt / scrypt / Argon2 这类「加盐慢哈希」，本工具不处理口令，别把口令粘进来算。

一句话：哈希做指纹，SHA-256 起步；哈希做口令，交给专用慢哈希。

三个最容易踩的坑

编码不一致：同一段中文，UTF-8 和 GBK 算出来的字节不同，哈希当然不同。现代系统默认 UTF-8，但老系统、Windows 记事本、某些数据库驱动可能用别的编码。比对前先确认两端编码一致。

结尾换行：你在文本框敲完内容顺手回车，字符串末尾就多了一个 \n，字节变了，哈希全变。复制粘贴也容易带进首尾空白。比对时务必「字节级」一致，先 trim 或显式处理换行。

大小写与格式：哈希结果只是十六进制串，大小写只是展示差异，本质相同；但有些系统要求带 0x 前缀、有些要求去掉，粘贴比对时注意格式。本工具统一输出小写、无前缀、无空格。

大文件别粘进来

本工具在浏览器里对整段文本哈希，几 MB 的文本也没问题，但几十上百 MB 的文件粘贴进文本框会卡。大文件请用系统自带命令：

# Linux / macOS
sha256sum ops-backup.tar.gz
md5sum ops-backup.tar.gz

# Windows (PowerShell)
Get-FileHash -Algorithm SHA256 ops-backup.tar.gz

把这些命令的输出和发布方给的校验值逐字符比对即可。

各算法速查

算法 输出长度 安全状态 典型用途
MD5 128 位（32 十六进制） 已不安全，仅完整性 老系统兼容、快速指纹
SHA-1 160 位（40 十六进制） 已不安全 老 Git 对象、 legacy 系统
SHA-256 256 位（64 十六进制） 安全 文件校验、签名、区块链
SHA-384 384 位（96 十六进制） 安全 高安全场景
SHA-512 512 位（128 十六进制） 安全 高安全、长摘要

位数越长，碰撞概率越低，但计算也略慢。日常文件校验 SHA-256 是甜点；对性能极度敏感又只需粗略指纹，MD5 仍可用，但别拿它当安全保证。

一个具体例子

以文本 ops-jiunotes 为例（UTF-8 编码）：

  • MD5：8f4d0a7c9b1e2f3a4b5c6d7e8f9a0b1c（示意，实际以工具为准）
  • SHA-256：3a7b...（64 位十六进制）

只要原文任何一个字节变化，哪怕只改一个字符的大小写，摘要就会完全变样。这就是哈希「雪崩效应」：输入微小改动，输出彻底不同。你可以用本工具验证——把 ops-jiunotes 改成 Ops-Jiunotes，看摘要如何天差地别。

HMAC：带密钥的哈希

光哈希不够时，用 HMAC（Hash-based Message Authentication Code）。它把密钥和消息一起参与哈希，既能校验完整性，又能验证身份——只有持有相同密钥的一方才能算出一致的 HMAC。很多 API 签名（AWS SigV4、各类 Webhook 校验）底层就是 HMAC-SHA256。

本工具只做裸哈希，不处理密钥。需要 HMAC 时，用服务端或本地脚本调用对应库，别把密钥粘到网页里。

在 CI 与 Git 里怎么用

  • 提交前校验：流水线里跑 sha256sum config.json 生成校验文件，部署时复算比对，防止配置在传输或存储中被悄悄改动。
  • Git 对象：Git 内部用 SHA-1 给每个对象（blob/tree/commit）算哈希做寻址。这就是为什么改一个字符，Git 能精确知道哪一处变了。Git 正在向 SHA-256 后端迁移，正是出于 SHA-1 碰撞的顾虑。
  • 缓存击穿防护：把请求参数哈希成短键做缓存，参数一致直接命中缓存，减少后端压力。

哈希是确定性的，这点要记住

同一个输入、同一种算法、同一种编码，哈希结果永远一样。这既是优点也是坑：优点是你可以放心比对；坑是哈希不隐藏信息——如果输入空间很小（比如 4 位口令），攻击者可以预先算好所有可能值的哈希做「字典/彩虹表」反查。所以口令绝不直接哈希，必须加盐且用慢哈希，让预计算变得不划算。

顺带一提，所谓「碰撞」是指两个不同的输入算出相同的摘要；好算法要让碰撞在算力上不可行。MD5 和 SHA-1 已被证明能低成本构造碰撞，而 SHA-256 至今没有已知的可实用碰撞，这正是安全场景必须升级算法的原因。

相关教程