什么是HMAC 生成器？
HMAC 生成器使用密钥和哈希算法（如 SHA-256、SHA-512 等）创建基于密钥的哈希消息认证码。HMAC 可同时验证数据完整性和来源真实性，常用于 API 身份验证、Webhook 签名以及 JWT 令牌。
HMAC 把密钥混进哈希，只有掌握该密钥的人才能验证签名。工具支持 SHA-1、SHA-256、SHA-384、SHA-512，输出可选十六进制、Base64、Base64URL 或原始二进制，并为 GitHub、Stripe、Slack、Shopify 的 Webhook 提供一键预设，自动填好算法和头部前缀。消息既可直接输入纯文本，也可粘贴已编码为十六进制、Base64 或 Base64URL 的内容——签名前会先解码为原始字节。实时字节计数会标出短于生产安全标准 32 字节的密钥，输入时签名会实时重新计算，验证框还能容忍这些平台发送的 sha256= 或 v0= 前缀。消息和密钥都在你的设备上处理。
使用方法
- 第一步 — 输入您的消息正文和密钥。
- 第二步 — 选择 Webhook 预设（GitHub、Stripe、Slack、Shopify），或自行设置哈希算法（SHA-1、SHA-256、SHA-384 或 SHA-512）和输出编码（十六进制、Base64、Base64URL 或二进制）。若要传入已编码的载荷，把消息输入格式切换为十六进制或 Base64 即可。
- 第三步 — 复制生成的 HMAC 签名，用于 API 请求头或 Webhook 验证。
何时使用
- 为 Webhook 负载签名，让接收方能确认来源是你且内容未被改动。
- 为 AWS Signature Version 4 或类似 API 认证方案生成请求签名。
- 用 HS256、HS384、HS512 算法生成 JWT 签名。
结果
您的支付 API 要求对请求进行 HMAC-SHA256 签名。将请求体作为消息、API 密钥作为密钥输入，复制生成的签名填入 X-Signature 请求头中。
常见问题
- HMAC 和直接对 message+key 做一次 SHA-256 有什么区别？
- HMAC 采用一种特定的双重哈希结构，内外两次都用经过填充的密钥。这能挡住针对 SHA-1、SHA-256 等算法的长度扩展攻击，而朴素的 hash(key‖message) 写法无法防御。
- 输出应该选 hex 还是 Base64？
- 看 API 或 Webhook 提供方的要求。HTTP 头里常见的是 hex（Stripe、GitHub），JSON 内容和 JWT 里常见的是 Base64。同一个签名两种编码都能表示，只是写法不同。
- 密钥应该多长？
- 建议至少 32 字节（256 位）的随机数据，最好来自密码学随机源。过短会削弱安全性；超过哈希块大小（SHA-256 是 64 字节）也无意义，HMAC 内部会先把它们压缩。
- 为什么我算出的签名和 API 返回的不一致？
- 通常是被签名的内容不一致。空格、换行符、查询参数顺序、URL 编码、是否包含时间戳都会影响结果。请仔细按照提供方的签名规则逐字节复现。
- HMAC-SHA1 现在还安全吗？
- 新系统建议直接选 HMAC-SHA256 或更强。HMAC-SHA1 在结构上仍安全（HMAC 不依赖抗碰撞性），但全面淘汰 SHA-1 是更稳妥的长期默认。