一個十六進位位元組永遠使用兩個數字，所以 ASCII 字母 A (U+0041) 在 UTF-8 十六進位中會變成 41，小寫的 é (U+00E9) 會變成 c3 a9，CJK 字元 你 (U+4F60) 會變成 e4 bd a0，而表情符號 😀 (U+1F600) 會變成 f0 9f 98 80。這份文字轉十六進位的速查表將最常見的字元對應到其 UTF-8 位元組值，解釋每個 Unicode 範圍應有的位元組寬度，並說明 Text to HEX 轉換器如何在瀏覽器本地端產生這些位元組序列，而無需上傳您的輸入或輸出。當目標是除錯一個承載資料、驗證雜湊輸入，或瞭解位元組如何對齊時，轉換規則保持不變，且位元組邊界可從碼點值本身預測。ASCII 字母與標點佔用單一位元組，常見的拉丁文擴展佔用兩個位元組，基本多語言平面的絕大部分佔用三個位元組，而像咧嘴笑表情符號這類輔助 Unicode 純量則佔用四個位元組。
常用字元的 UTF-8 十六進位值
閱讀十六進位傾印最快的方法是辨識幾個地標。NUL U+0000 就是位元組 00。可列印的 ASCII 位元組從 2 (空格) 開始到 7 (~) 結束，因此 20–7e 範圍內的任何位元組都會解碼為單一可見的 ASCII 碼點。80–bf 位元組本身永遠不會作為一個 UTF-8 字元的開頭；它們是接續位元組，會跟在先前的引導位元組之後。c0–c1 位元組作為 UTF-8 引導位元組是不合法的，這就是為什麼以 c0 開頭的十六進位傾印是個警訊，代表上游某個環節出了問題。
| 字元 | 碼點 | UTF-8 位元組 (十六進位) | 寬度 |
|---|---|---|---|
| NUL | U+0000 | 00 | 1 個位元組 |
| Space | U+0020 | 20 | 1 個位元組 |
| 0 | U+0030 | 30 | 1 個位元組 |
| A | U+0041 | 41 | 1 個位元組 |
| a | U+0061 | 61 | 1 個位元組 |
| ~ | U+007E | 7e | 1 個位元組 |
| © | U+00A9 | c2 a9 | 2 個位元組 |
| é | U+00E9 | c3 a9 | 2 個位元組 |
| ñ | U+00F1 | c3 b1 | 2 個位元組 |
| € | U+20AC | e2 82 ac | 3 個位元組 |
| 中 | U+4E2D | e4 b8 ad | 3 個位元組 |
| 你 | U+4F60 | e4 bd a0 | 3 個位元組 |
| 𝄞 | U+1D11E | f0 9d 84 9e | 4 個位元組 |
| 😀 | U+1F600 | f0 9f 98 80 | 4 個位元組 |
上述十六進位值在 a 到 f 之間使用小寫字母，並採用空格分隔的呈現方式。將工具切換為大寫只會更改這些字母，所以 é 會變成 C3 A9，而 😀 會變成 F0 9F 98 80。位元組值本身並不會改變。
依碼點範圍的 UTF-8 位元組寬度
編碼標準根據碼點值定義 UTF-8 位元組寬度，這就是為什麼十六進位傾印是驗證字串是否如預期編碼的可靠方式。U+0000 到 U+007F 的 ASCII 字元各佔用一個位元組。U+0080 到 U+07FF 中的許多常見拉丁文擴展及其他文字系統佔用兩個位元組。基本多語言平面的絕大部分，即 U+0800 到 U+FFFF，佔用三個位元組。U+10000 到 U+10FFFF 的輔助 Unicode 純量佔用四個位元組。
引導位元組的模式直接反映了寬度。一位元組引導落在 00–7f，兩位元組引導落在 c2–df，三位元組引導落在 e0–ef，四位元組引導落在 f0–f4。引導位元組 c0 與 c1 是不合法的，因為沒有任何 Unicode 純量需要它們；而引導位元組 f5–fd 也是不合法的，因為在 U+10FFFF 以上沒有定義的純量。看到十六進位傾印以 c0 或 f5 開頭，是輸入在編碼前就不是合法 UTF-8 的強烈跡象，這就是為什麼 Text to HEX 工具採用 WHATWG 編碼標準中描述的標準化 TextEncoder 轉換，而非字碼頁後備機制。
組合附加符號不會被編碼器合併到其預先組成的對應字元。e 後接 U+0301 的序列會保持分解狀態，並編碼為 65 cc 81，而不會被正規化為 é (c3 a9)。如果您的作業流程需要預先組成的輸出，請先將輸入通過一個正規化工具；轉換器本身不會套用 Unicode 正規化、大小寫轉換、修剪、換行符轉換、跳脫序列解析或區域設定感知的重寫。
如何使用 Text to HEX 工具將文字轉換為十六進位
- 在瀏覽器中開啟 Text to HEX 轉換器，並將文字貼上或輸入到輸入欄位中。該欄位接受 Unicode、空白字元以及 NUL U+0000；一般輸入會直接以第一個字元的位元組開始，因為編碼器不會加上 UTF-8 BOM。
- 選擇輸出格式：連續配對（例如 4869）、以空格分隔的位元組（例如 48 69），或每個位元組加上 0x 前綴的符記（例如 0x48 0x69）。這三種是針對同一個位元組陣列的不同呈現選擇。
- 選擇小寫或大寫的十六進位數字。大寫模式只會更改 a 到 f；位元組值與小寫的 0x 標記保持不變。
- 執行編碼器。結果面板會顯示格式化後的十六進位輸出，並同時顯示 UTF-8 位元組計數、格式化輸出長度，以及編碼過程中執行的孤立代理取代次數。
- 將完整結果複製到您的剪貼簿。剪貼簿寫入作業採用產生代數、掛載狀態與計時器識別碼的防護機制，因此來自較舊權限請求的延遲成功或失敗訊息，無法在編輯、重新編碼或另一次複製嘗試之後還原為過時狀態。若剪貼簿存取被拒絕，完整的唯讀結果仍可手動選取。
連續、空格分隔與 0x 前綴輸出比較
| 格式 | "Hi" 的範例 | 輸出長度公式 | 典型用途 |
|---|---|---|---|
| 連續 | 4869 | 2n 個字元 | 貼到十六進位搜尋中，嵌入到承載資料中 |
| 空格分隔 | 48 69 | 3n − 1 個字元 | 人可讀的傾印、文件 |
| 0x 前綴 | 0x48 0x69 | 5n − 1 個字元 | 原始碼、暫存器列表、C 風格的位元組陣列 |
公式中的變數 n 是 UTF-8 位元組計數。對於 n = 2，連續格式為 4 個字元 (4869)，空格分隔為 5 個字元 (48 69)，而 0x 前綴為 9 個字元 (0x48 0x69)；這與上表一致。第一個符記之前與最後一個符記之後不會放置分隔符，因此 n − 1 個分隔符位置說明了 3n − 1 與 5n − 1 這兩個表達式。Text to HEX 工具會根據位元組計數與所選語法計算所需的輸出大小，若預估值超出輸出預算，則會在格式化前拒絕該次編碼。
位元組計數、取代警告與輸出限制
每次編碼都會回報兩個可作為基準事實的計數。UTF-8 位元組計數是 TextEncoder API 輸出的位元組數。取代計數是在編碼前被取代為 U+FFFD 的孤立 UTF-16 代理碼元數量，因為孤立代理不是 Unicode 純量，標準化轉換會將每一個取代為位元組 EF BF BD。結果面板會顯示該計數並呈現一個警告，因為解碼 EF BF BD 無法還原原始的孤立碼元。
限制是明確的，並在建構大型格式化字串之前就已套用。輸入欄位最多接受 1,000,000 個 UTF-16 碼元；超出上限一個碼元就會以明確訊息拒絕。格式化輸出必須容納於 4,999,999 個 UTF-16 碼元之內，並接受精確的邊界值：一百萬個 ASCII 字元以 0x 前綴格式產生正好 4,999,999 個輸出碼元，因為 n = 1,000,000 且 5n − 1 = 4,999,999。在冗長格式中使用多位元組 Unicode 時，可能會在達到輸入預算之前就觸及輸出預算；此時工具會回報該失敗，而非切換格式、截斷位元組或抽樣內容。
編輯文字、變更格式或大小寫，或開始新的編碼時，會清除先前的輸出、錯誤、位元組統計、取代警告、複製狀態與複製計時器。格式化以有界位元組區塊進行並串接所有區塊；這屬於內部處理，不會更改或限制可見輸出，只影響其在記憶體中的建構方式。
將十六進位轉回文字的來回轉換規則
精確的文字轉十六進位再轉回文字的來回轉換，需要格式正確的 Unicode，並對開頭的 U+FEFF 特別留意。JavaScript 字串是 UTF-16，一個有效的高位元加低位元代理對代表一個輔助 Unicode 純量，編碼器會正常處理。孤立的高位元或低位元代理碼元會在編碼前變成 U+FFFD，這是不可逆的：位元組 EF BF BD 無法還原為原始的孤立碼元。請留意結果面板中的取代計數；非零的計數代表來回轉換將無法精確。
如果您的輸入以 U+FEFF 開頭，該字元的位元組會編碼為資料 EF BB BF，因為它是資料，並非因為編碼器加了 BOM。TextEncoder 不會在前面加上 UTF-8 位元組順序標記。對應的 Hex to Text 工具會在其文件化的 BOM 行為下消費開頭的 EF BB BF，因此透過該特定工具進行精確的來回轉換，也要求原始輸入不以 U+FEFF 開頭。字串中間的內部 U+FEFF 仍會保留為文字的一部分。如需反向處理的背景說明，請參閱如何以純文字與 0xNN 格式將十六進位轉換為可讀文字。
驅動此轉換器的瀏覽器 API 是標準化的。MDN 文件化了 TextEncoder 介面及其回傳的 Uint8Array；WHATWG 編碼標準定義了純量值轉換與 UTF-8 編碼器。十六進位是這些位元組的顯示編碼，而非加密、雜湊、壓縮或機密保護；任何擁有位元組並瞭解 UTF-8 規則的人，都能還原原始文字，但須遵循所選解碼器的文件化開頭 BOM 行為。
如需更深入的探討，請參閱如何變更 Windows 文字檔案的 UTF-8 編碼。