Hash 生成器

这个 Hash 生成器会把输入框中的精确文本转换成固定长度的十六进制摘要。它适合用于内容一致性比对、完整性校验、API 签名前摘要准备，或者生成某个系统明确要求的 SHA 结果。需要先明确的是，摘要不是加密后的文本，不能再“解密”回原文。

SHA 摘要是如何产生的

SHA 算法会先把消息变成字节序列，再按规则填充成固定大小的分组，并通过位运算反复把每个分组压缩进内部状态。输入只要发生很小变化，输出也应明显不同，这就是摘要适合做比对、却不适合做可还原存储的原因。SHA-224 属于 SHA-2，它使用 SHA-256 的压缩结构，但初始值不同，最终只输出前 224 位摘要。

• SHA-1 输出 160 位摘要，由于已经存在实际碰撞攻击，今天主要只适合历史兼容。
• SHA-224 与 SHA-256 都使用 512 位消息分组和 32 位运算，但输出长度与初始值不同。
• SHA-384 与 SHA-512 使用 1024 位分组和 64 位运算，摘要更长，常见于要求更严格的兼容策略。

如何使用这个工具

1. 先根据兼容性或完整性校验需求选择合适的 SHA 算法。
2. 粘贴要计算摘要的精确文本后，重点确认空白字符和换行是否一致。
3. 确认算法、输出大小写和源内容字节级一致后，再复制摘要结果。

更可靠的文本摘要流程

Hash 看起来只是点一次运行按钮，但多数错误结果都来自选错算法，或者输入内容与预期文本有一个不显眼的差异。更稳妥的做法是把算法名称、输入字节和输出格式看成一组必须同时成立的证据。

1. 先确认下游系统要求的算法，再粘贴文本。
2. 保持待摘要文本与目标内容完全一致，包括空格、制表符、标点和末尾换行。
3. 生成摘要后，同时核对长度和完整十六进制字符，不要只看开头几位。

经典示例：文本 `abc`

短字符串 `abc` 是很适合用来核对实现的测试样本，因为许多 SHA 实现都会公开同一组已知摘要。它也能直观说明：算法名称不能混用，同样的输入在 SHA-224 和 SHA-256 下会得到不同长度、不同内容的结果。

`abc` 的已知摘要

输入：
abc

SHA-224：
23097d223405d8228642a477bda255b32aadbce4bda0b3f7e36c9da7

SHA-256：
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Web Crypto 摘要计算最小示例

const bytes = new TextEncoder().encode("abc");
const digest = await crypto.subtle.digest("SHA-256", bytes);

实现说明

浏览器 Web Crypto 的 `crypto.subtle.digest()` 原生暴露 SHA-1、SHA-256、SHA-384 和 SHA-512。由于该 API 不暴露 SHA-224，本工具会在本地使用 SHA-256 同族实现计算 SHA-224。

这个工具适合用在哪些场景

当来源内容是文本，并且下一步需要一个 SHA 摘要时，就适合使用这个工具。典型场景包括比对复制出来的 payload、确认配置文本是否变化、准备 API 签名流程中的摘要部分，以及复现另一个系统使用的类校验和值。

常见使用场景

Hash 生成器 最适合用在需要做 SHA 系列摘要比对的文本内容需要快速变成所选算法对应的固定长度十六进制摘要的场景，尤其是文本完整性校验、类校验和值比对、发布记录、API 签名前准备和跨系统摘要核对。

• 用于生成 SHA-1、SHA-224、SHA-256、SHA-384 或 SHA-512 哈希，服务于文本完整性校验、类校验和值比对、发布记录、API 签名前准备和跨系统摘要核对。
• 处理重要输入前，可先用示例流程确认算法选择、大小写比对、精确输入字节、空白字符，以及 SHA-1 是否只用于兼容。
• 当结果符合目标流程后，再复制或下载所选算法对应的固定长度十六进制摘要。

哈希校验在实务里最容易失败的地方

哈希校验最常见的失败，不是因为算法坏了，而是因为团队比对了错误的字节、错误的算法，或者错误地假设了文本规范化方式。很多时候文件看起来一样、字符串看起来一样，但只要换行、空白、BOM 或编码不同，结果就会彻底变化。所以页面输出有价值的前提，是你先把“输入字节”“输出算法”“目标比对标准”三件事对齐。

• 在开始比对之前，先确认目标系统要求的到底是哪一种算法。
• 如果源内容是复制来的文本，就应保留原始文件或原始字节来源，以防无形细节在复制时已经丢失。
• 新的信任敏感流程应优先选更强的 SHA 变体，较弱方案只保留在兼容场景中。

导致 SHA 结果看起来不对的常见误区

当摘要比对不上时，算法实现本身通常不是最先应该怀疑的对象。实际工作里，更常见的原因是输入里有不可见差异、字符编码不同、复制时带上了包装文本，或者下游系统实际使用的是另一个 SHA 变体。

• 末尾多一个换行或空格也是输入内容的一部分，会改变摘要。
• 不要把 SHA-1 用在新的安全敏感设计里，只有旧协议明确要求时才保留。
• 不要把快速 SHA 摘要当成密码存储方案；密码存储需要带盐和成本参数的慢速密码哈希方案。

Hash 能证明什么，不能证明什么

Hash 擅长回答的是“这份内容和那份内容是不是同一份字节”，而不是“这是谁发的”“它是不是保密过”“它是否天然可信”。如果你要证明来源身份或防止篡改，还需要签名、认证链路或传输保护一起工作。

本工具支持的 SHA 算法对比

使用注意

• 复用所选算法对应的固定长度十六进制摘要前，先检查算法选择、大小写比对、精确输入字节、空白字符，以及 SHA-1 是否只用于兼容。
• 哈希是单向摘要，不是加密；安全敏感的完整性校验应使用 SHA-256 或更强算法。
• 当结果会影响生产工作或客户可见内容时，应保留原始需要做 SHA 系列摘要比对的文本内容以便回退和核对。

Hash 生成器 参考说明

Hash 生成器 会说明摘要算法、完整性校验用途，以及哈希为什么不是加密。

• SHA 系列哈希会把消息切成固定大小的分组，逐轮压缩进内部状态，最后输出固定长度的摘要。
• SHA-1 使用 512 位分组并输出 160 位摘要，但由于已经存在成熟碰撞攻击，现在只应保留在兼容场景中。
• SHA-256 同样基于 512 位分组和 32 位运算；SHA-384 与 SHA-512 则基于 1024 位分组和 64 位运算，其中 SHA-384 本质上是带不同初始值的截断版 SHA-512。
• 哈希不能被解密，只能与已知摘要进行比较。

参考资料

• FIPS 180-4: Secure Hash Standard (SHS)
• MDN: SubtleCrypto.digest()
• NIST Policy on Hash Functions