HMAC 產生器會根據一把密鑰與一段訊息計算出鍵控雜湊訊息鑑別碼，並回傳完整、以小寫十六進位與標準帶填充 Base64 呈現的 SHA-256、SHA-384 或 SHA-512 標籤。「批次 HMAC 產生」描述的是在多組密鑰/訊息配對上產出這些標籤的做法——通常是長長的伺服器記錄、已簽章的 webhook payload、已簽章的 CSV 資料列，或大批的 API 請求——而不會把密鑰或訊息送到遠端服務。HMAC 產生器正符合這個模式：每一次迭代都會把密鑰位元組匯入為一把不可匯出的 WebCrypto HMAC 密鑰，在瀏覽器內部簽署訊息，然後輸出完整標籤，所有資料都不會離開目前的分頁。由於每個雜湊家族的輸出大小都是固定的——SHA-256 為 32 位元組、SHA-384 為 48 位元組、SHA-512 為 64 位元組——頁面一律顯示完整標籤，並把任何截斷、前綴處理或 Base64url 替換留給通訊協定規範決定。介面會拒絕空白的密鑰與空白的訊息，並將每個解碼後的欄位上限設為一百萬位元組，因此批次執行必須事先把非常大的 payload 切成多塊，並驗證沒有任何資料列不小心混入空白。內建八項 RFC 4231 一致性檢查，可在使用短密鑰、二進位密鑰，以及跨越雜湊區塊邊界的資料時，確保實作品質如實。
批次 HMAC 產生：它真正的含義
大多數 HMAC 實作在每一組密鑰與訊息的配對上只產生一個標籤，因此「批次」工作本質上是一種迭代模式：一段腳本、一位開發人員連續執行多次計算機操作，或是一份仍需要位元組級精確處理的一次性大型 payload。HMAC 產生器在每一次迭代中都保持一致，這是因為演算法是確定性的；給定相同的密鑰位元組與相同的訊息位元組，它會逐位元組地回傳相同的標籤。這種確定性正是讓批次操作值得信賴的關鍵，因為任何驗證端只要執行同一批配對，就會得到相同的結果。對於非常大的資料集而言，「批次」也可以指單一筆數百萬位元組等級的資料，例如一個序列化後的 JSON 文件或一份冗長的記錄匯出，以單一次操作處理，而非分派到多列上處理。在這兩種情況下，要求都完全相同：位元組完全一致、編碼模式正確（UTF-8 或十六進位），以及標籤沒有被截斷、沒有前綴。
如何批次產生 HMAC 標籤
HMAC 產生器的每一次迭代都遵循相同的位元組級精確步驟。請在批次執行時，針對每一組密鑰/訊息配對套用此程序。
- 確認您的通訊協定預期的是完整的 HMAC-SHA-256、HMAC-SHA-384 或 HMAC-SHA-512 標籤，並記下驗證端所預期的編碼方式，無論是小寫十六進位或標準帶填充 Base64。
- 在介面中選擇對應的雜湊演算法，然後針對密鑰與訊息分別獨立選擇 UTF-8 或十六進位。人類可讀的字串以及以文字形式撰寫的公開測試向量請使用 UTF-8；只要規格提供的是原始位元組或十六進位位元組字串，則請使用十六進位。
- 將精確的位元組貼到每個欄位中，不要加上前綴、空格、冒號或尾端換行。介面會拒絕長度為奇數的十六進位、嵌入的 0x 前綴，以及散落的分隔符，因此格式上的筆誤絕不會悄悄改變通訊協定的數值。
- 產生標籤，並以您的通訊協定所要求的編碼格式複製。十六進位與 Base64 只是相同標籤位元組的不同呈現方式，因此兩者不可混用——以十六進位驗證的驗證端遇到 Base64 標籤會驗證失敗，反之亦然。
- 對下一組密鑰/訊息配對重複相同步驟。請將每一次迭代視為獨立作業：重新匯入密鑰、簽署訊息，並比對完整輸出，絕不要以手動截斷的前綴作為比對依據。
- 在擴大批次執行之前，先把最初的幾個結果與獨立的驗證端或 RFC 4231 測試向量進行交叉比對，這樣可以及早發現密鑰或編碼上的錯誤。
大型 Payload 的輸入限制與切塊策略
HMAC 產生器將每個解碼後的欄位上限設為 1,000,000 位元組。單一筆數百萬位元組的記錄匯出可能就會觸及這個上限，因此批次工作必須在首次貼上之前就備妥明確的切塊計畫。此上限是按欄位計算的，也就是說密鑰與訊息會被獨立評估，較小的欄位可能已經達到上限，而較大的欄位卻仍匯入失敗。以下是幾條實用的規則：
- 在貼上之前以位元組（而非字元）為單位測量訊息大小。帶有腔調字、CJK 或表情符號的 UTF-8 文字，每個碼位會展開為一到四個位元組，因此一個 300,000 字元的訊息很可能就會超過上限。
- 把非常大的輸入切成符合上限的區塊，然後對每個區塊分別執行計算機。若通訊協定是對連續串流進行簽章，請對每個區塊分別執行一次 HMAC 運算並串接標籤，或依照規格所定義的分塊 MAC 機制處理。
- 讓密鑰也維持在相同的 1,000,000 位元組上限內。1 MB 的密鑰雖然罕見，但對某些建構方式而言仍屬合法；只要解碼後的位元組數不超過上限，頁面都能支援。
- 小心從記錄檔或 CSV 匯出貼上時夾帶的尾端換行。原本 1,000,000 位元組的訊息，只要編輯器多加了一個行尾換行符，就會變成 1,000,001 位元組，運算也將無法執行。
對於任何接近上限的輸入，瀏覽器的 Web Crypto 管線會以非同步方式執行，而頁面會為每個工作指派一組身分權杖，這表示在前一個工作仍在處理時變更輸入，並不會讓舊值覆蓋到新值。
以 RFC 4231 測試向量驗證批次輸出
RFC 4231 為 HMAC-SHA-256 與 HMAC-SHA-512 定義了正式的測試案例，是位元組級精確驗證的權威參考。HMAC 產生器內建八項完整的一致性檢查：四組 SHA-256 向量與四組 SHA-512 向量，涵蓋短密鑰、小於底層雜湊區塊的密鑰、重複位元組的二進位密鑰，以及跨越雜湊區塊邊界的資料。在任何正式批次執行之前先將這些向量送入產生器，是確認實作正確的快速方法；只要密鑰中有一個位元組損毀，批次中所有輸出都會變成亂碼，因此 RFC 向量同時也兼具其餘管線冒煙測試的角色。如需正式定義，請參閱 RFC 4231 規格。
若讀者需要將同樣的位元組級精確紀律套用於單一、固定的通訊協定步驟，HMAC-SHA256 位元組級精確步驟指南會以具體輸入帶領您走過相同的程序。
批次 HMAC 執行中的常見陷阱
大多數批次 HMAC 的失敗，都來自會在整批中被放大的細小輸入錯誤。下表摘要了 UTF-8 與十六進位模式處理邊界情況的方式，而下列四種模式則是批次執行最常與驗證端出現分歧之處。
| 考量點 | UTF-8 模式 | 十六進位模式 |
|---|---|---|
| 接受的輸入 | 純文字字元 | 偶數長度的十六進位數字 (0–9, a–f, A–F) |
| 編碼步驟 | 簽署前先將文字編碼為 UTF-8 位元組 | 將輸入視為原始位元組；不做額外編碼 |
| 腔調字 / CJK / 表情符號 | 每個碼位佔一到四個位元組 | 必須以對應的十六進位位元組表示法提供 |
| 更嚴格的驗證 | 拒絕空白輸入 | 拒絕空白輸入、長度為奇數的半位元組、0x 前綴、空格、冒號、嵌入的分隔符 |
| 適用情境 | 人類可讀的字串與公開的文字測試向量 | 二進位欄位、原始位元組常數、通訊協定定義的十六進位字串 |
- 換行符慣例不一致。 Windows 風格的 CRLF 與 Unix 的 LF 會產生不同的訊息位元組，因此在其中一種環境下計算出的標籤，會在另一種環境下驗證失敗。請在批次貼上之前先統一換行符，或依照通訊協定所規定的精確慣例。
- 貼上時夾帶尾端空白。 編輯器與剪貼簿管理員常常會多加一個空格或換行，而這並非通訊協定原本的內容，這同樣會改變訊息位元組並破壞標籤。
- 在同一批次中混用 UTF-8 與十六進位。 若一列以文字輸入，另一列卻以同一段文字的十六進位表示法輸入，即使螢幕上看起來字元相同，兩者的標籤也會不同。
- 手動截斷標籤。 64 字元的 SHA-256 十六進位，並不等於其前 32 字元；唯有當通訊協定明確要求時，截斷才算合法。
在批次工作中選擇 SHA-256、SHA-384 或 SHA-512
雜湊演算法的選擇會改變標籤長度，但不會改變演算法結構。SHA-256 是大多數現代 Web API 簽章的預設值，會產生 32 位元組的標籤。計算範例：32 位元組 × 每位元組 2 個十六進位字元 = 64 個十六進位字元。SHA-384 會產生 48 位元組，呈現為 96 個十六進位字元；SHA-512 則產生 64 位元組，呈現為 128 個十六進位字元——兩者都遵循相同的「位元組數乘以二」規律。標準 Base64 的展開比例也與相同的位元組數成正比，並帶有餘數的填充字元；SHA-256 標籤轉換後為 44 個 Base64 字元，而 SHA-384 與 SHA-512 的標籤，套用四組三位元組的規則後，會佔用更多的空間。
| 雜湊演算法 | 輸出位元組 | 十六進位字元數 | 標準 Base64 字元數 |
|---|---|---|---|
| SHA-256 | 32 | 64 | 44 |
| SHA-384 | 48 | 96 | 64 |
| SHA-512 | 64 | 128 | 88 |
在伺服器端比對標籤的批次工作流程中，必須在第一次迭代之前，就為所選的雜湊家族預留足夠的儲存空間與傳輸頻寬，並與驗證端約定好線上格式到底是十六進位還是標準 Base64。
跨大量訊息迭代時的關鍵衛生習慣
金鑰處理決定了批次部署的成敗。以下三條規則能在多次迭代中保護秘密：
- 使用為該協定獨立產生的高熵金鑰素材。此頁面不會產生金鑰，而是匯入您所提供的位元組，因此熵必須來自工具外部。
- 透過受保護的管道分送金鑰，並僅將其保留在目前的分頁中。由於 Web Crypto 金鑰物件在匯入後即不可匯出，因此瀏覽器不會意外地將其交回給 JavaScript，這降低了批次執行期間意外外洩的攻擊面。
- 在伺服器上使用常數時間函式比對標籤。若批次執行使用一般相等性來比對字串，會洩漏時序資訊，使攻擊者得以一次一個比較地還原 MAC 的位元組，因此驗證端無論標籤是如何產生的，都必須使用常數時間比對輔助函式。
人類可讀的密碼並不會自動成為強健的 HMAC 金鑰。當必須將密碼轉為金鑰時，請使用該協定所要求的密碼型 KDF 及其參數，切勿自行變通。使用弱、低熵金鑰所產生的標籤雖然仍具確定性，但也同樣可被猜測，從而失去認證的意義。
至此已完整涵蓋批次工作流程的各個環節。HMAC Generator 將同樣的模式實作於單次與迭代使用情境中，並將其與 RFC 4231 向量搭配作為冒煙測試，可確保整個管線從第一次到最後一次迭代都能達到位元組層級的完全一致。
想進一步了解，請參閱 Punycode Converter 批次處理：處理多標籤 IDN 網域。