HMAC-SHA256 標籤是一個 32 位元組的加密指紋，用來證明訊息來自知道同一把秘密金鑰的對方。與單純的 SHA-256 雜湊不同，HMAC 在雜湊計算的每一個步驟都會綁定金鑰，因此即使攻擊者看見訊息，也無法在沒有金的情況下偽造有效的標籤。這項特性讓 HMAC 非常適合用於 API 請求簽章、檔案完整性檢查以及短期有效的權杖。HMAC 產生器工具可讓你以 UTF-8 文字或原始十六進位位元組輸入金鑰與訊息，選擇 SHA-256、SHA-384 或 SHA-512，並以小寫十六進位或標準 Base64 接收完整輸出，藉此產生符合你通訊協定預期的精確標籤——整個過程完全不需要將資料上傳到伺服器。
當你需要簽署 API 承載、驗證韌體更新或認證 JWT 時，通訊協定規格會告訴你該使用哪種雜湊、金鑰與訊息是 UTF-8 字串還是二進位資料區塊，以及如何編碼最終的標。例如 AWS Signature Version 4 要求使用 UTF-8 金鑰與訊息的 HMAC-SHA256，而韌體清單則可能使用以十六進位編碼之二進位資料的 HMAC-SHA512。HMAC 產生器提供獨立的 UTF-8 或十六進位輸入模式，可滿足這些需求，讓你直接貼上通訊協定所定義的精確位元組，而不會因格式意外變動。該工具也透過八組 RFC 4231 測試向量鎖定正確性，確保短金鑰、重複位元組資料以及跨越區塊邊界的輸入都能產生預期的標籤。
HMAC 實際做的是什麼——以及它不做什麼
HMAC 結合了加密雜湊與共用秘密金鑰。擁有相同秘密與精確訊息位元組的驗證者可以計算出相同的標籤，藉此偵測修改並認證知道金鑰的對方。然而它並不會隱藏訊息。任何看到明文的人仍然可以讀取它，而任何取得金鑰的人都可以偽造有效的標籤。這項區別至關重要：HMAC 回答的是「這個秘密的持有者是否產生了這個精確的位元組序列？」——它並不能回答「我能把這則訊息保密嗎？」如果你需要兩種特性，請將 HMAC 與認證加密機制搭配使用，或採用將機密性與完整性結合的通訊協定，例如 AES-GCM、ChaCha20-Poly1305 或 libsodium 的 secretbox。
位元組的一致性至關重要。文字模式會將兩個欄位都以 UTF-8 編碼，因此帶有變音符號的字母、CJK 字元與表情符號會佔用多個位元組。十六進位模式只接受偶數個十六進位數字，並保留每一個位元組，包括零。它會拒絕前綴、空格、冒號與奇數的半位元組，如此一來，意外出現的格式字元便無法悄悄改變通訊協定的數值。選擇的雜湊會決定標籤長度：SHA-256 會回傳 32 位元組，SHA-384 回傳 48 位元組，SHA-512 回傳 64 位元組。本頁面一律顯示完整輸出。通訊協定可能會要求截斷、前置演算法識別符、標準化請求字串、二進位封包，或使用 Base64url 而非標準 Base64。這些規則僅能依據通訊協定規格來套用；切勿以目測方式裁剪標籤。
何時該使用 SHA-256、SHA-384 或 SHA-512
HMAC-SHA256 是最廣泛部署的變體，因為它在安全性與效能之間取得平衡。SHA-256 的 32 位元組輸出提供強大的碰撞抗性，同時仍保持緊湊，足以放入 HTTP 標頭、資料庫欄位以及嵌入式系統。SHA-384 與 SHA-512 提供更高的安全邊際，並產生更長的標籤——48 與 64 位元組——這可能會增加儲存空間與頻寬的負擔。請僅在通訊協定明確要求時使用 SHA-384 或 SHA-512，例如在強制要求使用更高安全等級之 FIPS 認可演算法的環境中，或是當長期封存需要更強的碰撞抗性時。本產生器提供全部三種選項，讓你能精確符合管轄的通訊協定。
| 雜湊 | 標籤長度（位元組） | 十六進位字元數 | Base64 字元數 | 典型使用情境 |
|---|---|---|---|---|
| HMAC-SHA-256 | 32 | 64 | 44 | API 簽章、JWT、webhook |
| HMAC-SHA-384 | 48 | 96 | 64 | FIPS 認可模組、長效期秘密 |
| HMAC-SHA-512 | 64 | 128 | 88 | 韌體清單、高安全性權杖 |
逐步產生 HMAC 標籤
- 在瀏覽器中開啟 HMAC 產生器。
- 選擇雜湊演算法：SHA-256、SHA-384 或 SHA-512。請確認你的通訊協定預期的是完整標籤長度——除非規格明確要求，否則不要截斷。
- 為金鑰與訊息分別選擇輸入編碼。UTF-8 模式會將文字編碼為 UTF-8 位元組，而十六進位模式僅接受偶數個十六進位數字（不含前綴、空格或冒號）。
- 以精確的位元組輸入秘密金鑰與訊息。若使用 UTF-8，請貼上原始文字；若使用十六進位，請貼上連續的十六進位字串。該工具會拒絕奇數半位元組與格式字元，以防止位元組被悄悄更動。
- 點擊「Generate HMAC」以計算標籤。結果會以小寫十六進位與標準填補式 Base64 顯示。請複製你的通訊協定所要求的編碼——除非規格指示，否則不要轉換或截斷。
- 將完整標籤與預期值進行比對。位元組的一致性至關重要：只要有一個位元的差異，就代表金鑰或訊息的位元組不一致。
常見的輸入陷阱與避免方法
HMAC 標籤對金鑰與訊息中的每一個位元組都非常敏感。單一不可見的變動——例如結尾的換行、Unicode 標準化方式的差異，或一個意外多出的空格——就會產生完全不同的標籤。HMAC 產生器會透過拒絕格式錯誤的十六進位輸入並保留精確的 UTF-8 編碼，來防範許多這類錯誤。然而，在你按下產生按鈕之前，仍有一些陷阱需要注意：
- 空白與換行：如果你的通訊協定將訊息定義為 JSON 承載或標準化請求字串，請確認你包含了規格所要求的精確空白與行尾字元。該工具會逐字元處理每個位元組，因此缺少一個換行或多出一個空格都會改變標。
- Unicode 標準化：UTF-8 模式會以原樣編碼文字，因此「café」（使用尖音符 e）與「cafe」加上組合式尖音符會產生不同的位元組。請使用與驗證者相同的標準化形式（NFC 或 NFD）。
- 十六進位格式：十六進位模式僅接受連續的十六進位數字。像「0x」這類前綴、冒號或空格這類分隔符，以及奇數的半位元組都會被拒絕。如果你的金鑰或訊息在發布時附帶了格式，請先將其移除再貼上。
- 空欄位：介面會拒絕空白的金鑰與訊息，以防止誤觸，儘管某些低階標準可能會定義長度為零的資料之行為。如果你的通訊協定確實需要空白欄位，請先確認規格中的精確規則。
- 金鑰熵：人為設定的密碼並不會自動成為強健的 HMAC 金。如果通訊協定允許使用密碼，請採用其要求的密碼型金鑰衍生函式（PBKDF2、Argon2、scrypt 等）並使用精確的參數。HMAC 產生器不會衍生金鑰——它預期接收的是最終的位元組字串。
在除錯標籤不符的問題時，請先確認雜湊演算法、金鑰位元組與訊息位元組。使用十六進位模式以排除編碼差異，並以十六進位完整比對標籤，以排除 Base64 填補或 URL 安全變體的差異。Base64 轉十六進位轉換器可以在通訊協定預期一種編碼、工具卻輸出另一種時，協助你轉換。請記住，十六進位與 Base64 只是相同標籤位元組的不同呈現方式——在進行任何比較之前，將任一者解碼為原始位元組都必須產生完全相同的值。
HMAC 產生器如何確保正確性與安全性
HMAC 產生器使用瀏覽器原生的 Web Cryptography API 來執行 HMAC 計算。金鑰與訊息的位元組會以不可匯出的 HMAC 金鑰形式匯入，搭配 SHA-256、SHA-384 或 SHA-512，並透過 subtle.sign 方法在不做截斷的情況下回傳完整標籤。這種做法確保計算發生在你瀏覽器分頁的本機端——資料不會傳送至任何伺服器，金鑰資料也絕不會離開你的裝置。非同步工作會帶有身分識別權杖，因此在 Web Crypto 執行期間變更輸入，可避免較舊的結果覆蓋新狀態。
正確性透過八組 RFC 4231 測試向量鎖定，涵蓋短金鑰、二進位重複位元組的金鑰與資料、小於摘要長度的金鑰，以及跨越雜湊區塊邊界的資料。SHA-256 與 SHA-512 各檢查四組獨立輸入，而介面也提供 WebCrypto 所定義的 SHA-384 選項。這些測試案例保證本產生器所產生的標籤與其他相容實作相同，因此你可以放心將其輸出用於正式環境。
安全性取決於金鑰資料與相關做法。該工具強制每個解碼後欄位的大小上限為 1,000,000 位元組，以防止意外輸入過大的資料，但並不會驗證金的熵或其分發方式。請使用依通訊協定獨立產生之高熵的金鑰資料，透過受保護的管道進行分發，依用途區分不同金鑰，在遭到破解後立即更換，並在伺服器端以常數時間函式比對標籤。當密碼必須轉為金鑰時，請遵循應用程式所要求的密碼型衍生機制與參數。密碼產生器可以在你的通訊協定允許使用原始秘密的情況下，於本機產生強健的隨機資料，但請務必避免將正式環境的秘密貼入不受信任的裝置。
產生標籤後的通訊協定特定調整
HMAC 產生器一律以小寫十六進位和標準填補 Base64 輸出完整標籤。許多通訊協定在傳輸或儲存標籤之前，需要額外的步驟。請僅在 HMAC 本身已正確計算後，且僅依據通訊協定規格來套用這些調整：
- 截斷：某些規格要求的標籤長度比完整雜湊輸出還短。請僅在產生完整標籤後再進行截斷——不要更改 HMAC 計算本身。請依規格精確截斷到位元組數，絕對不要依視覺長度截斷。
- 演算法識別碼：JWT 和某些 API 簽章會在標籤前加上演算法名稱，例如「sha256=」或明確的「HS256」標頭。請僅在通訊協定要求時才加上這些識別碼——不要將它們納入 HMAC 計算，因為這會改變訊息位元組。
- Base64url 編碼：JWT 和其他網路通訊協定使用 Base64url，它省略填補，並將「+」替換為「-」、「/」替換為「_」。請僅在規格指示時，才將標準 Base64 輸出轉換為 Base64url。HMAC 產生器不會直接輸出 Base64url，以避免與標準 Base64 混淆，且這兩種編碼無法互換——解碼後會產生不同的位元組。
- 二進位封包：某些通訊協定會將訊息和標籤一起打包成二進位格式，例如 protobuf 或自訂標頭。請從產生器的輸出中擷取標籤，並依通訊協定的規則將其插入封包中。
- 標準化請求字串：許多簽章通訊協定會先從標頭、酬載和時間戳記組裝出標準化字串。請對該精確的標準化字串產生 HMAC，而不是對原始請求主體，並使用通訊協定所規定的金鑰位元組。
兩個 HMAC 標籤成功一致，只能證明共用金鑰和位元組的一致性，並不能證明訊息的機密性。請依通訊協定儲存和傳輸每個欄位，因為視覺相似的編碼無法互換。請僅在從主導通訊協定中識別出精確的位元組和演算法後再使用產生器，優先對已發布的向量和二進位欄位使用十六進位模式，並記住此工具僅作為計算輔助——金鑰管理、傳輸安全以及驗證器實作仍由您的應用程式負責。
如果您正在權衡各種方案，如何在 Windows 中產生 SHA256 雜湊對此有詳細說明。
如果您正在權衡各種方案，Base64 與十六進位轉換：命令列與線上工具比較對此有詳細說明。