批次文字轉十六進位（UTF-8）的轉換作業中，輸入上限為 1,000,000 個 UTF-16 字碼單元，格式化輸出上限為 4,999,999 個；三種輸出格式分別會產生正好 2n、3n−1 或 5n−1 個十六進位字元，其中 n 為 UTF-8 位元組數量。Text To HEX 工具正是圍繞著這兩項明確的預算而打造：在編碼前若輸入超過字碼單元上限便會直接拒絕；而預測的格式化長度會在建構可見字串之前，依據同一道輸出上限進行驗證。與單一字串作業相比，批次轉換的其他部分並沒有任何改變。文字編碼器同樣是瀏覽器中用於單行處理的 TextEncoder API；差別在於批次工作揭示了這條規則——格式語法越繁複，撞上天花板的速度就越快。純配對格式最精簡，加空格的配對格式居中，而加上 0x 前綴的格式則帶來最多的額外負擔；因此，一份在純配對格式下綽綽有餘的酬載，換成 0x 格式時可能就會用盡格式化輸出空間，即使底層的 UTF-8 位元組仍能容納於輸入上限之內。能掌握這層關係，正是讓一項批次工作得以順利完成、而不是在半途遭到拒絕的關鍵。本文的其餘部分將逐步說明這些預算如何彼此作用、各格式各需耗費多少字元，以及如何規劃一項能完整跑完、不會被悄悄截斷的批次轉換作業。
為何批次文字轉十六進位需要明確的預算
小型十六進位查詢很少需要擔心大小問題：輸入六個字元，就會得到十二個十六進位數字。但批次情況就不同了，因為同一套操作一旦放大到數千個字元，便會暴露出工具為了持續運作而採取的各種捷徑：像是捨棄最後一個位元組、只取前 N 個樣本、切換格式以配合記憶體限制，或是悄悄截斷過長的輸出。Text To HEX 的編碼管線在設計上就拒絕上述所有情況。編碼器尚未執行之前，輸入內容就會先對照 1,000,000 個 UTF-16 字碼單元進行檢查，因此一份過大的貼上內容會在最前端就遭到拒絕並顯示明確訊息，而不是只回傳部分結果。格式化輸出上限 4,999,999 個 UTF-16 字碼單元，是依據實際的 UTF-8 位元組數量與所選語法，套用上述公式計算得出；該預測值還會再次與實際產生的字串比對，作為一道防禦性不變檢查。正是這層冗餘設計，讓上限值在批次酬載場景中值得信賴——在這類場景裡，任何一個位元組的悄悄位移，都會讓所有進行雜湊、傳輸或比對十六進位的下游消費者受到污染。
接受與拒絕之間的界線是精確的，而不是模糊的。驗證器不會為了塞進最後一個位元組而做四捨五入、雜湊或壓縮處理。5,000,000 字元的格式化輸出字串會遭到拒絕；4,999,999 字元的字串則會被接受。這道銳利的邊界，讓建置腳本能放心地圍繞這個工具進行規劃；同時也說明了為什麼同一份 UTF-8 位元組數量，在純配對格式下能成功，換成 0x 前綴格式時卻會失敗。
格式與長度：每個選項如何影響輸出長度
三種呈現格式底層共用同一套 UTF-8 位元組，差別只在於標點與大小寫，而這些標點在格式化輸出長度上會產生可計量的成本。對於一個編碼後產生 n 個 UTF-8 位元組的輸入來說：純配對格式需 2n 個字元（例如，兩個位元組的字串 "Hi" 為 4869）；加空格的配對格式需 3n−1 個字元（48 69）；加上 0x 前綴的格式則需 5n−1 個字元（0x48 0x69）。在大寫與小寫之間切換時，字元數不會改變。但在格式之間切換時，數字就會跟著變動。下表列出四組簡短 ASCII 輸入及其對應的三種格式化輸出長度，方便以實例驗證公式。
| 輸入 | 位元組數 (n) | 純配對 (2n) | 加空格 (3n−1) | 0x 前綴 (5n−1) |
|---|---|---|---|---|
| Hi | 2 | 4 | 5 | 9 |
| Hex | 3 | 6 | 8 | 14 |
| Bulk | 4 | 8 | 11 | 19 |
| Hello | 5 | 10 | 14 | 24 |
值得記住的臨界情況，正好是 1,000,000 個 ASCII 字碼單元在 0x 前綴格式下的結果。將 n = 1,000,000 代入前綴公式：5 × 1,000,000 − 1 = 4,999,999，這正是可被接受的最大格式化輸出長度。多一個字元，驗證器就會在建構輸出字串之前拒絕這項工作，正因為所要求的酬載會超出上限。同樣這筆一百萬個字元的 ASCII 輸入若採純配對格式，則仍相當寬鬆（格式化結果為 2,000,000 個字元，不到 4,999,999 上限的一半），因此格式的選擇，才是影響批次吞吐量的真正關鍵。
如何批次執行文字轉十六進位
批次作業流程與單一字串情況類似，但當輸入大到足以讓預算產生影響時，每一步都值得更仔細地檢視。
- 將完整的酬載貼入輸入欄位。該欄位可接受瀏覽器能容納的任何 Unicode 內容，包括空白字元、NUL 位元組、換行字元，以及輔助字元，上限為 1,000,000 個 UTF-16 字碼單元。若來源大小只是概略值，請在貼上前先核對大小，因為一旦貼上過大的內容，工具只會直接回傳一則明確的拒絕訊息。
- 挑選符合格式化輸出預算的格式。純配對格式耗費最少的字元；加空格的配對格式居中；0x 前綴格式則耗費最多。可隨時雙向切換而不會使輸入失效，因為底層的 UTF-8 位元組並不會改變。
- 執行編碼，然後在複製前先讀取位元組數量與格式化長度面板。兩組顯示的數字皆來自用於驗證上限的同一套公式，因此同時可作為最終大小的健全性檢查。若酬載包含孤立的 UTF-16 代理項，結果也會顯示一個可見的取代計數，代表那些未配對字碼單元所對應的 EF BF BD 位元組數量。
- 透過複製按鈕複製完整結果。若剪貼簿權限遭到拒絕，唯讀結果仍會保留在畫面上，因此內容不會遺失，且該批次工作仍可透過手動選取的方式挽救。
選擇純配對格式，幾乎能讓所有合理的 ASCII 酬載都落在預算之內。選擇 0x 前綴格式，則是犧牲格式化長度，換取一份在 C、Rust 或封包擷取中可直接視為十六進位字面值的結果。批次作業中需要特別留意的失敗模式，是冗長格式下的多位元組 Unicode：一份由三位元組字元構成的字串，會在遠早於觸及輸入上限之前就先衝破輸出上限；此時工具會回報這個溢位，而不是中途切換格式。
批次編碼器絕不會更動的部分
一個會在正規化過程中改寫輸入內容的批次編碼器，會破壞其受託保存的酬載本身。Text To HEX 批次編碼器承諾除了以下兩項明文記載的取代動作之外，不會更動任何資料。它不進行 Unicode 正規化，因此一個拉丁小寫字母 e 後接 U+0301 會保持分解狀態，並編碼為 65 CC 81，而非 U+00E9。它不進行換行轉換，因此 CR、LF 與 CRLF 都會依原始順序保留。它不做修剪、不做大小寫轉換、不進行逸出解析，也不做與地區設定相關的改寫。NUL U+0000 會編碼為字面的 00 位元組。來源中開頭的 U+FEFF 會編碼為 EF BB BF，這是因為它屬於資料，而非編碼器自行附加的 BOM——這正是配對讀取端（例如對應的Hex to Text Converter）所依賴的契約。以非配對狀態進入的代理項，會一對一地取代為 U+FFFD，每一處取代在位元組流中都會變成 EF BF BD；這項取代計數，正是稽核人員用以確認一個格式正確的來回轉換所需要的依據。在批次執行前先檢視這份清單，是最便宜的方式，以確保底層資料沒有遭到任何更動。
在大規模情境下讀取結果面板
結果面板承載四項在批次作業中重要的資訊。位元組計數代表所產生的 UTF-8 位元組數量，也就是每個長度公式中所使用的 n。格式化輸出長度代表可見字串中的字碼單元數量，並已經依據 4,999,999 上限進行過驗證。取代計數代表已轉為 U+FFFD 位元組的孤立代理字碼單元數量；對於格式正確的 Unicode 輸入，該值為零。格式化輸出本身為唯讀文字，可手動選取，因此即使剪貼簿權限遭到拒絕，也不會阻塞批次作業。若下游消費者對特定位元組提出疑問，底層 TextEncoder.encode 方法的 MDN 文件，以及 WHATWG 的 TextEncoder 規格，都是值得參考的資料。由於從輸入讀取到格式化字串組裝的所有流程，都在當前的瀏覽器分頁中完成，批次酬載永遠不會離開這個頁面——當輸入規模成長到超過單筆記錄時，這正是多數團隊最在意的一項特性。
若您正在權衡不同選項，在 Outlook 中變更 UTF-8：外寄郵件與檔案對此有更詳細的說明。