HMAC 生成
HMAC Generator
按选定的哈希算法和密钥编码算出消息的 HMAC，用来核对 webhook 签名。
对文本或文件计算 HMAC——带密钥的摘要——密钥可以按文本、十六进制或 Base64 读取。它和哈希工具是同一个界面、打开了 HMAC 那一半，因为 HMAC 就是带密钥的哈希，分开会变成两个共用每一个控件的页面。
输入
拖入一个文件来算校验和
在这个标签页里读取，不上传。
文本按 UTF-8 字节做哈希，这也是别的工具说“给字符串算哈希”时的意思。
摘要
粘贴一个公布的校验和，对上的那一行会亮起来。
| 算法 | 摘要 | 复制 |
|---|---|---|
| MD5造一次碰撞很便宜。当校验和还行，签名和密码就别用了。 | ||
| SHA-1碰撞已经被实际做出来过。老的校验和还能用，新的东西别碰。 | ||
| SHA-256 | ||
| SHA-384 | ||
| SHA-512 | ||
| CRC-32这是检错码，不是哈希。两个文件可能碰巧撞上同一个值，故意撞就更容易。 |
输入
0 B
来源
文本框
怎么用
打开 HMAC
密钥字段出现，CRC-32 从表里退出——它是校验和，不是哈希函数，没有 HMAC。
说明密钥该怎么读
HMAC 通常就是在这里出错的。写成 `0a1b2c` 的密钥按十六进制是三个字节，按文本是六个，两者产生完全不同的摘要。
和你收到的签名比对
把它粘进比对框；匹配的那一行会点亮。Stripe、GitHub 和 Slack 的 webhook 签名都是对一个特定字符串做的 HMAC-SHA256，所以把消息弄对和把密钥弄对一样要紧。
常见问题
为什么我的 HMAC 和请求头里的对不上？
通常是消息的问题，不是密钥。webhook 签名是对一个精确的字符串计算的——常常是时间戳、分隔符和原始正文——而一份经过 JSON 解析器再序列化的正文是另一个字符串。对你收到的字节签名。
HMAC 和把密钥和消息拼在一起做哈希一样吗？
不一样，这正是它的意义。`hash(key + message)` 在 MD5、SHA-1 和 SHA-256 上容易受长度扩展攻击；HMAC 带内外填充的两遍构造正是消除这一点的东西。永远不要自己造一个。
密钥会离开标签页吗？
不会。它只用来在这个标签页里导入一个 WebCrypto 密钥，别的什么都不做——不传输、不存储、不放进 URL。刷新页面就丢了，对一个秘密来说这是正确的行为。
密钥该多长？
至少和摘要一样长——SHA-256 是 32 字节。HMAC 接受任何长度，但比块大小长的密钥会先被哈希缩短，而短密钥就只是短密钥：安全性就是你放进去的熵。
可以从这些接进来
文本哈希计算
Text Hash
算出字符串的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 和 CRC-32，输出可选大写或 Base64。
动态口令生成
TOTP Code Generator
把 TOTP 密钥换成当前的六位验证码并带倒计时，用来验证两步验证配得对不对。
随机密钥生成
Random Key Generator
按指定长度生成密码学随机字节，输出十六进制、Base64 或 Base64URL，用作应用的 secret。
JSON 格式化与校验
JSON Formatter & Validator
把 JSON 美化成缩进形式或压成一行，校验语法并直接指出出错的行和列。
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
文本哈希计算
Text Hash
算出字符串的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 和 CRC-32，输出可选大写或 Base64。
JWT 解码
JWT Decoder
解出头部和载荷，按本地时间显示过期时刻，并用你给的密钥验证签名。
随机密钥生成
Random Key Generator
按指定长度生成密码学随机字节，输出十六进制、Base64 或 Base64URL，用作应用的 secret。
Base64 编码解码
Base64 Encoder & Decoder
对文本和文件做 Base64 与 Base64URL 编解码，UTF-8 处理正确。
curl 转代码
curl to Code
把一条 curl 命令转成 fetch、axios、Python requests、Go、PHP 或 PowerShell 代码。
JSON ⇄ CSV 互转
JSON ⇄ CSV
把嵌套 JSON 按点路径列名拍平成列，或者从表格重新拼回对象。