「文字轉十六進位代碼」的意思是把文字中的每個字元轉換成代表其 UTF-8 位元組的十六進位數字，每個位元組用兩個十六進位數字表示，因此每個字元都會變成固定寬度、機器可讀的權杖。例如，字串 "Hi" 在連續格式中會變成 4869，在以空格分隔的格式中會變成 48 69，在加上 0x 前綴的格式中則會變成 0x48 0x69，因為 'H' 是 U+0048（位元組 0x48），而 'i' 是 U+0069（位元組 0x69）。Text To HEX 正是直接在您的瀏覽器中執行這項作業，使用符合 WHATWG 標準的 TextEncoder API 來產生精確的 UTF-8 位元組，再依您選擇的三種樣式之一進行格式化。它不會加入 BOM，會保留 NUL 和空白字元，並顯示位元組計數以及任何孤立的代理替換項目，讓轉換過程可被稽核而非黑箱作業。您可以直接使用結果來偵錯酬載、撰寫單元測試，或將位元組貼入原始碼：十六進位字串就是同一個 UTF-8 位元組陣列的字面表示，會依照目的地調整樣式。
「十六進位代碼」對文字來說究竟代表什麼
當您要求取得文字的「十六進位代碼」時，您要求的其實是代表每個字元 UTF-8 位元組序列的十六進位數字，每個位元組正好用兩個十六進位數字表示。像 'A'（U+0041）和 '0'（U+0030）這類 ASCII 字元各佔一個位元組，因此會變成 41 和 30 這樣的兩位數配對。像 'é'（U+00E9）這類帶重音的拉丁字母則佔用兩個位元組，會變成四位數的配對（c3a9）。基本多語言平面（BMP）中的大多數字元（包括中文、日文、阿拉伯文和希臘文）佔用三個位元組。補充字元（包含大多數表情符號和少數罕見的歷史文字）則佔用四個位元組。
因為每個位元組正好對應兩個十六進位數字，輸入大小與輸出大小之間的關係是機械式而非概略的。值得注意的是，一個輸入字元可能產生兩個、三個或四個位元組，因此十六進位字串的長度會隨著位元組計數而非字元計數增長。一個包含一個表情符號的短句，可能會產生比整段純 ASCII 段落更長的十六進位字串。
如需快速參考每個 Unicode 範圍如何對應到位元組與十六進位數字，Text to Hex 速查表 並列列出了標準範例。
| 字元類別 | 範例 | 碼位 | UTF-8 位元組 | 十六進位數字 |
|---|---|---|---|---|
| ASCII | A | U+0041 | 1 | 2 |
| 帶重音的拉丁字母 | é | U+00E9 | 2 | 4 |
| 大多數 BMP 字元 | 你 | U+4F60 | 3 | 6 |
| 補充字元（表情符號） | 😀 | U+1F600 | 4 | 8 |
如何將文字轉換為十六進位代碼
Text To HEX 工具遵循 WHATWG TextEncoder 規範所描述的相同三步驟流程，但將原始 API 包裝在可選擇的格式化選項中，讓您可以直接將結果貼入測試、組態檔或程式碼字面值中。
- 在輸入欄位中輸入您的文字。瀏覽器能容納的任何字元皆可接受：ASCII、帶重音字母、CJK、表情符號、空白字元（空格、定位字元、換行）以及 NUL 位元組。該工具不會去除、標準化或修剪輸入內容。
- 挑選一種輸出樣式與字母大小寫。選擇連續格式以取得精簡的位元組（例如 4869）、選擇以空格分隔的格式以取得人類可讀的位元組（48 69），或選擇0x 前綴格式以取得 C 風格的字面值（0x48 0x69）。接著選擇小寫或大寫的十六進位數字。大小寫只會影響字母 a–f；位元組值與小寫的 0x 標記不會受到影響。
- 進行編碼，然後檢視位元組計數、格式化後的輸出長度，以及任何針對孤立 UTF-16 代理的替換警告。使用複製按鈕複製完整結果。若剪貼簿權限被拒絕，仍可使用唯讀輸出，讓您手動選取並複製。
編輯輸入或變更任何選項時，會清除先前的輸出、位元組與替換計數、替換警告，以及任何進行中的複製狀態，因此過時的結果絕不會與新一輪的編碼混雜在一起。
三種輸出格式及其適用時機
這三種格式都是同一個 UTF-8 位元組陣列的呈現方式選擇，依據 MDN 對於 TextEncoder.encode 的參考資料。切換格式時位元組本身並不會改變；改變的只有數字周圍的標點與間距。
| 格式 | "Hi" 的範例 | 長度公式（n = 位元組計數） | 最佳用途 |
|---|---|---|---|
| 連續 | 4869 | 2n | 精簡酬載、雜湊摘要、標頭值 |
| 以空格分隔 | 48 69 | 3n − 1 | 記錄、偵錯、快速目視檢查 |
| 0x 前綴 | 0x48 0x69 | 5n − 1 | C/C++/Rust 位元組陣列、嵌入式測試向量 |
就這個演算範例而言，n = 2（即 "Hi" 的兩個 UTF-8 位元組）。連續格式的長度為 2 × 2 = 4 個字元（4869）。以空格分隔的長度為 3 × 2 − 1 = 5 個字元（48 69）。0x 前綴的長度為 5 × 2 − 1 = 9 個字元（0x48 0x69）。相同的算術可應用於任何輸入，這也是為什麼該工具會在格式化位元組之前，先將輸出預算與預測長度進行比對。
字母大小寫與格式選擇如何影響輸出
切換小寫與大寫十六進位只會把字母 a 到 f 改寫為 A 到 F。數字 0–9、位元組值本身，以及小寫的 0x 標記都會被保留下來。值為 0x3c 的位元組在小寫模式下會變成 3c，在大寫模式下則會變成 3C；不論哪種方式，所代表的位元組完全相同，且位元組計數也不會改變。
切換格式會因為加入了標點而產生更大的視覺效果。連續格式為每個位元組放置兩個字元；以空格分隔的格式為每個位元組放置三個字元（兩個十六進位數字加上位元組之間的一個 ASCII 空格，尾端不含分隔符）；0x 前綴格式則為每個位元組放置五個字元（字面值 0xNN 的四個字元加上位元組之間的一個 ASCII 空格，尾端不含分隔符）。如果您要精確比對目標輸出（例如規範中的總和檢查碼字串或固定寬度欄位），格式的選擇與位元組內容本身同樣重要。
該工具會依據位元組計數與所選語法計算所需的輸出長度，然後在配置格式化字串之前，先將該值與輸出預算進行驗證。這與上方長度公式欄中所示的算術相同，只是會依各別格式來套用。
邊界情況：NUL 位元組、組合標記、代理與 BOM
有幾個邊界情況在初次見到時會讓人感到意外。事先了解規則，可避免在十六進位輸出與預期不符時產生困惑。
- NUL 位元組（U+0000）會被保留。它們會被編碼為位元組 00，而非作為結束符使用。整段文字（包括任何嵌入的 NUL 字元）會在格式化之前完整編碼。
- 空白字元的順序會被保留。CR、LF、定位字元與空格會依照其在輸入中出現的順序進行編碼。該工具不會轉換行尾符號或修剪結尾字元。
- 組合標記保持分解形式。'e' 字元後接著 U+0301（組合銳音符）會變成三個位元組 65 CC 81，而非預先組成的 U+00E9。Unicode 正規化並不會被套用。
- 不會附加 BOM。WHATWG TextEncoder 編碼 步驟會為輸入的第一個字元產生 UTF-8 位元組，且不加上前置的 EF BB BF。若輸入本身以 U+FEFF 開頭，則這些位元組會被編碼為資料。
- 孤立的 UTF-16 代理會被替換。任何不屬於有效配對的高位或低位代理碼元，會在被編碼之前被替換為 U+FFFD，產生 EF BF BD。結果面板會計算並明顯警告每一次這類替換，因為原始的代理碼元無法從位元組中還原。
- 精確的往返轉換需要格式正確的 Unicode。唯有當輸入格式正確且不以 U+FEFF 開頭時，將位元組解碼回文字才能還原原始內容。對應的 Hex to Text 工具會依其明定政策消耗前導 BOM，因此若原始輸入中含有前導 U+FEFF，會在解碼過程中被消耗，而不會作為字元回傳。
大型貼文的輸入與輸出限制
有兩項明確的預算規範管轄每一次編碼作業，工具會在格式化任何位元組之前同時檢查這兩項。這正是防止 1,000,000 字元的貼文被悄悄截斷、切換成不同格式或取樣的機制。
- 輸入預算：最多 1,000,000 個 UTF-16 碼元。空白的輸入以及超過此上限的輸入，會在編碼開始前以明確的訊息拒絕。
- 輸出預算：最多 4,999,999 個 UTF-16 碼元的格式化輸出。由於格式化後的長度取決於位元組計數與所選格式，多位元組字元在較冗長的格式中，可能會比輸入預算更早觸及此上限。
可接受的邊界是精確的：100 萬個 ASCII 輸入字元以 0x 前綴格式輸出，會正好產生 4,999,999 個輸出碼元（5 × 1,000,000 − 1）。任何超過任一驗證項一個輸入碼元或一個輸出碼元，都會被拒絕並顯示明確訊息。該工具不會切換格式、切割位元組、刪除後綴，或取樣內容以符合預算——它只會回報錯誤。
若冗長的 0x 格式成為瓶頸而需要處理大型貼文，切換為連續或以空格分隔的輸出，通常能讓相同的輸入維持在上限以內。針對非常大的 UTF-8 貼文的實務指引（包括分塊工作流程與精確的邊界條件），記載於大量編碼指南中。