HMAC 產生器速查表是一份快速參考，把每一個 HMAC 決策對應到一個具體動作:要選哪個雜湊、如何輸入精確的金鑰與訊息位元組、以及接收端系統實際預期的輸出編碼方式。金鑰雜湊訊息驗證碼 (HMAC) 結合了密碼學雜湊與一把共用秘密金鑰，持有同一把秘密、並餵入同一份訊息位元組的驗證端，能夠重新算出完全相同的標籤。該標籤可驗證送出端身分並偵測竄改，但無法隱藏訊息內容。任何看到明文的人依然能讀取，而任何取得秘密的人都能偽造有效的標籤。這正是速查表中每一行——雜湊選擇、位元組編碼、輸出格式——存在的原因:其中任何一項改變，就會產生不同的標籤，驗證端便會判定為無效而拒絕。
本頁圍繞著 HMAC 產生器 建置，完全在瀏覽器中透過 Web Cryptography API 執行，絕不會把金鑰資料上傳到伺服器。下列內容皆預設你已從規範協議的協定中，確認精確的演算法、金鑰位元組與訊息位元組。
雜湊選擇速查
HMAC 演算法就是 HMAC;真正會改變標籤長度與可接受性的，是底層的雜湊。請挑選協定所指定的雜湊，而不是最強的那一個。
| 雜湊 | 標籤長度 (位元組) | 十六進位字元數 | 標準 Base64 字元數 | 典型用途 |
|---|---|---|---|---|
| SHA-256 | 32 | 64 | 44 | JWT HS256、AWS Signature v4、大多數 REST webhook |
| SHA-384 | 48 | 96 | 64 | 明確要求 SHA-384 的協定 |
| SHA-512 | 64 | 128 | 88 | 高安全性 API 與長訊息簽章 |
其關係是固定的:十六進位字元數等於 tag_bytes × 2，標準含填充 Base64 等於 ceil(tag_bytes / 3) × 4。SHA-256 一律回傳 32 位元組，SHA-384 一律回傳 48,SHA-512 一律回傳 64。長度不對的標籤，無法靠重新編碼來配對;請先選好雜湊，再產生標籤。
金鑰與訊息位元組的編碼
HMAC 處理的是位元組，而不是文字。每份速查表都從這裡開始，因為標籤不符的最常見原因，正是「文字看起來一樣」但位元組卻不同。HMAC 產生器為每個欄位提供兩種編碼——UTF-8 與十六進位——金鑰與訊息各自獨立選擇。
UTF-8 模式將該欄位視為文字，並依標準 UTF-8 規則編碼。這代表含音字母、CJK 字元、表情符號各佔用多個位元組，單一字元就可能讓位元組數變動一個以上。十六進位模式只接受偶數個十六進位數字，保留每一個位元組 (含零)，並拒絕 0x 前綴、空格、冒號與奇數半位元組，以避免格式字元在不知情的情況下悄悄改掉協定值。
若協定或公開的測試向量提供的是原始位元組、二進位標頭，或不可列印的金鑰，請優先使用十六進位模式。若規格把秘密命名為「API 金鑰字串」、或把訊息命名為「以文字表示的請求本文」，則優先使用 UTF-8 模式。當協定未說明編碼方式時，唯一依據就是實際簽章或驗證的實作——請複製該實作所讀入的位元組，而不是在編輯器中看起來合理的位元組。
如何逐步產生 HMAC 標籤
- 開啟 HMAC 產生器，並確認協定預期的是完整的 HMAC 標籤——而非原始雜湊、簽章封包、或帶演算法前綴的識別碼。
- 選擇協定指定的雜湊:SHA-256、SHA-384 或 SHA-512。若驗證端預期的是其他演算法，預設的 SHA-256 就是錯的。
- 為金鑰欄位獨立選擇 UTF-8 或十六進位，然後輸入精確的位元組。若是 UTF-8 秘密，直接貼上秘密字串，前後不要有空白;若是十六進位金鑰，則貼上偶數個十六進位數字，不要有 0x 前綴或分隔符號。
- 為訊息欄位獨立選擇 UTF-8 或十六進位，並輸入驗證端將雜湊的精確位元組。請留意尾端的換行:送出端若有一個 \n，驗證端若沒有 \n，就會產生不同的標籤。
- 產生標籤後，複製小寫十六進位或標準含填充 Base64。兩種呈現是同一組標籤位元組;只是格式不同。
- 只有在協定明確要求時，才轉換或截斷標籤。常見的轉換包括截斷為 N 位元組、加上演算法識別前綴、將訊息連同標籤一起封裝、或改用 Base64url。每一條規則都應依規格套用;不要用肉眼去編輯一個有效的標籤。
輸出格式規則:十六進位 vs Base64
HMAC 產生器一律同時以兩種呈現方式回傳完整標籤。兩者之間的選擇是協定的問題，不是偏好。
| 編碼 | 樣式 | 要求使用的場合 |
|---|---|---|
| 小寫十六進位 | 64 / 96 / 128 個十六進位數字，無前綴 | JWT 簽章段、許多 webhook 標頭、除錯紀錄 |
| 標準含填充 Base64 | 44 / 64 / 88 個字元，結尾帶 = 填充 | OAuth 1.0 簽章、部分 REST API |
| Base64url (未輸出) | 長度相同，以 - 取代 +、以 _ 取代 /、去除填充 | JWT 與部分現代 API——請貼上標準 Base64 並於外部轉換 |
十六進位與 Base64 編碼的是相同的位元組。本頁不會輸出 Base64url、不會加上演算法識別前綴，也不會把訊息連同標籤一起封裝。若協定預期其中任何一種，該格式轉換是 HMAC 產生之後的獨立步驟。視覺上相似的編碼並不可互換:把 Base64url 值當成標準 Base64 解碼，反之亦然，都會產生不同的位元組與驗證失敗。
為何你的標籤與其他工具不同
當兩個實作對看似相同的輸入產生不同的 HMAC 標籤時，請依序走過這份檢查清單。每一項都是文件化的不符原因，編碼部分的實務慣例與 Base64 解碼速查表 一致。
- 雜湊錯誤。 SHA-256、SHA-384 與 SHA-512 各自產生不同的標籤。請確認驗證端使用的是相同的演算法名稱。
- 位元組編碼錯誤。 同一段金鑰或訊息文字，以 UTF-8 與十六進位處理會得到不同的位元組。請確認兩端對 UTF-8 與原始十六進位的認知一致。
- 隱藏的空白或換行。 尾端的空格、歸位字元或換行字元都是訊息位元組的一部分。請將兩端依相同的慣例去除。
- 標籤被截斷。 有些協定只保留最左邊的 N 位元組;HMAC 產生器一律回傳完整標籤。請僅在協定有指示時才截斷。
- Base64 變體不符。 標準含填充 Base64 與 Base64url 不可互換。請以對應的字元集解碼預期的值。
- 演算法前綴。 部分協定會在標籤前加上識別碼，如 HMAC-SHA256=。產生器並不會自動加上此前綴。
若依檢查清單仍無法解決不符情形，請以同一份輸入在兩端對照公開的測試向量。若對已知向量能達成一致，即代表實作正確;剩下不符的部分就屬於應用層協定，而非 HMAC 原語的問題。
對照 RFC 4231 測試向量進行驗證
HMAC 產生器已鎖定八組 RFC 4231 一致性標籤，涵蓋短金鑰、二進位重複位元組的金鑰與資料、比摘要長度短的金鑰，以及跨越雜湊區塊邊界的資料。SHA-256 與 SHA-512 各以四組獨立輸入進行檢查，介面也額外提供 SHA-384，因為 Web Cryptography API 已定義。以已知向量為基準來比對，而不是從新的簽章開始，是在任何正式金鑰尚未介入前，確認位元組編碼、雜湊選擇與標籤呈現皆與驗證端相符的最快方式。
請使用十六進位模式處理公開向量:輸入是以原始位元組列出，若改走 UTF-8 模式，看起來平凡的字元會被悄悄以多位元組編碼。請以驗證端預期的編碼比對完整標籤。根據 RFC 4231 測試向量，在已知向量上達成一致，只能證明金鑰與位元組的一致性——並不能證明訊息的機密性，也無法保護已被貼入不受信任裝置的正式金鑰。
若想深入了解，請參閱 Punycode 轉換器速查表:RFC 3492 規則與限制。