跳到正文
DevTools / 哈希生成器

哈希生成器

无需上传任何字节,即可为文本或文件生成校验和与加密摘要。本工具覆盖了开发者日常真正会用到的全部算法:用于遗留校验的 MD5 与 CRC32、用于旧式签名的 SHA-1、用于现代完整性校验的 SHA-256/384/512,以及用于带密钥消息认证的 HMAC-SHA256。文本输入即时计算;文件以 4 MB 分片流式读取,因此几个 GB 的归档文件也只会占用极小的内存。

完全在浏览器本地运行——不会上传任何内容。

0 字符 · 0 字节(UTF-8)

结果
暂无内容

计算本地文件哈希

或将文件拖到此处

文件按 4 MB 分片流式读取,不会上传。

工作原理

SHA-256 属于美国国家安全局设计、NIST 于 2001 年发布的 SHA-2 家族。它先对输入做填充,切成 512 位的分组,再对每组执行 64 轮压缩函数——由按位旋转、模加法和一组取自前 64 个质数立方根的固定常量构成。输出是 256 位摘要,即 64 个十六进制字符,具备雪崩效应:输入改变一个比特,输出大约一半的比特都会翻转。

MD5 和 CRC32 是出于兼容性而保留的,并非为了安全。MD5 产生 128 位摘要,自 2004 年起已被成功构造碰撞;CRC32 是 32 位循环冗余校验,设计目的仅仅是发现传输错误。但两者仍在使用:S3 的 ETag、ZIP 条目、PNG 数据块、静态资源指纹文件名以及旧版 API 签名都依赖它们,所以工具箱里仍然值得保留。HMAC-SHA256 则是用密钥包裹 SHA-256,摘要同时证明完整性与密钥持有者身份——这正是 AWS SigV4、Stripe Webhook 和 JWT HS256 背后的机制。

本工具全部通过 Web Crypto API 在本地执行,浏览器未原生提供的 MD5 与 CRC32 由紧凑的 JavaScript 实现补齐。文件路径使用 File.slice() 按 4 MB 分块读取并送入流式哈希器,因此无论文件多大,内存占用都保持恒定。输入的任何部分都不会被传输——计算摘要时打开浏览器网络面板即可自行验证。

常见应用场景

  • 用厂商公布的校验和验证刚下载的 ISO 或发行包是否完整。
  • 为对象存储上传生成 S3 风格的 ETag 或 Content-MD5 请求头。
  • 生成 HMAC-SHA256 签名,排查 Webhook 验签失败的原因。
  • 为静态资源文件名生成用于破除缓存的内容指纹。
  • 在不做逐字节对比的情况下判断两个大文件是否完全相同。
  • 手工构造 ZIP 或 PNG 数据块时计算资源的 CRC32。

最后更新: 2026-10-14

常见问题解答

SHA-256 可以被逆向还原吗?

不能。加密哈希是单向函数:没有密钥,也没有逆运算,摘要无法还原成原文。现实中唯一可行的攻击方式是暴力枚举——不断尝试候选输入并比对摘要——这正是短密码或可猜测密码会被彩虹表和字典攻击攻破、而长随机输入不会的原因。

什么是彩虹表?加盐为什么能破解它?

彩虹表是事先算好的“摘要 → 原文”映射表。攻击者不再逐个猜测再哈希,而是直接查表。盐是混入每个输入的一段唯一随机值,它使相同密码的存储摘要也各不相同,于是预计算表彻底失效,攻击者只能退回到针对单个目标的暴力枚举。

应该用 MD5 还是 SHA-256?

凡是与安全相关的场景——签名、口令存储、需要防篡改的完整性校验——都应使用 SHA-256 或 SHA-512。只有在必须与已有系统保持一致时才用 MD5,例如对接旧式 ETag 或历史校验文件。在普通硬件上,MD5 碰撞可以在数秒内构造出来,今天它已不提供任何有意义的安全保证。

文本或文件会被上传吗?

不会。哈希完全在浏览器内通过 Web Crypto API 和本地 JavaScript 完成。文件通过 File.slice() 按 4 MB 分片读取,浏览器不会把它们发送到任何地方,计算过程中页面不会发起任何网络请求。打开开发者工具的网络面板即可确认。

为什么 CRC32 的结果只有 8 位?

因为 CRC32 产生的是一个 32 位数值,正好是 8 个十六进制字符。它是校验和而非加密摘要:能可靠地发现传输中的比特翻转等意外损坏,但无法抵御蓄意篡改——构造一个修改过却具有相同 CRC32 的输入轻而易举。

相关工具