將文字轉換為十六進位 ASCII 時,每個字元會先編碼為其 UTF-8 位元組序列,然後將每個位元組寫成兩個十六進位數字——因此「A」(U+0041)會變成 41,數字「0」(U+0030)會變成 30,空格(U+0020)會變成 20。超出 ASCII 範圍的字串每個字元會佔用超過一個位元組:é (U+00E9) 會變成 c3 a9,你 (U+4F60) 會變成 e4 bd a0,😀 (U+1F600) 會變成 f0 9f 98 80。市面上標榜能將文字轉換為十六進位 ASCII 的工具,實際輸出可能會因其內部使用的編碼方式不同而有所差異。僅支援 ASCII 的轉換器會直接捨棄非 ASCII 位元組,或以佔位符取代;使用 Windows-1252 或地區字碼表的轉換器所產生的位元組,只有在共用相同字碼表的系統上才會一致;UTF-8 轉換器則遵循 WHATWG 編碼標準,這也正是瀏覽器 TextEncoder API 所使用的編碼器。Text To HEX 工具在您的瀏覽器中套用該標準,會回報位元組數量,並針對同一組底層位元組提供三種呈現風格,讓輸出在任何能讀取 UTF-8 的環境中都能正確還原。

text to hex ascii
Text to Hex ASCII: Convert Strings to Hexadecimal Bytes

ASCII 與 UTF-8:轉換實際上做了什麼

許多搜尋「text to hex ASCII」的使用者預期會是一種「一字元對應一位元組」的對應關係,而對於純英文輸入來說,這個預期確實符合實際情況。ASCII 範圍涵蓋 128 個碼位,從 U+0000 到 U+007F,每一個都能以單一 UTF-8 位元組表示,直接從對照表就能讀出其兩位十六進位數字。字串「Hi」會產生位元組 48 與 69,因此 ASCII 轉十六進位的結果就是 4869。

一旦輸入內容超出這 128 個字元的範圍,簡單的 ASCII 圖像就不再適用。Latin-1 補充區,包括 é、à、ñ 等,位於 U+0080 以上,需要兩個 UTF-8 位元組。多數用於非拉丁文腳本的基本多文種平面字元——中文、日文、韓文、阿拉伯文、斯拉夫文、印地文——則使用三個 UTF-8 位元組。補充字元,例如表情符號與罕見的 CJK 表意文字,則使用四個位元組。若使用僅支援 ASCII 的回退方式編碼,這些字元可能會被捨棄,或被問號取代,因此任何標榜為「text to hex」的工具都應該明確採用 UTF-8 編碼。Text To HEX 使用瀏覽器的 TextEncoder API,該 API 由 WHATWG 編碼標準規範,能為任何有效的文字輸入產生明確定義的 UTF-8 位元組陣列。

同一組位元組的三種輸出格式

轉換過程會產生一組固定的位元組陣列;格式的選擇只會改變這些位元組的呈現方式。Text To HEX 工具提供三種版面配置,以及十六進位字母 a 到 f 的大小寫切換選項。

格式「Hi」的範例最佳適用情境
連續4869精簡的單行複製、驗證碼管線、十六進位傾印
以空格分隔48 69人工檢查、除錯紀錄、貼入 shell 指令
加上 0x 前綴0x48 0x69C 風格的位元組字面值、微控制器程式碼、JSON 陣列

在這三種選項之間切換,並不會改變編碼後的 UTF-8 位元組。純文字格式會將每個位元組的兩位數字串接在一起。以空格分隔的格式會在每組位元組之間插入一個 ASCII 空格。加上前綴的格式會將每個位元組寫成 0xNN,並以單一 ASCII 空格分隔各 token,第一個 token 之前與最後一個 token 之後皆不含分隔符號。選擇大寫只會改變字母 a–f;位元組數值以及前綴中的小寫「x」皆維持不過。格式化後的輸出長度則會隨之改變:連續格式使用 2n 個字元,以空格分隔的格式使用 3n−1 個字元,加上前綴的格式則使用 5n−1 個字元,其中 n 為位元組數量。

逐步將文字轉換為十六進位

  1. 在輸入欄位中輸入或貼上文字,內容可包含任何 Unicode 字元、空白字元、Tab 鍵、換行字元,或瀏覽器欄位能容納的 NUL (U+0000) 資料。
  2. 選擇一種呈現格式——連續配對、以空格分隔的位元組,或加上 0x 前綴的 token——並選擇十六進位數字的大小寫。
  3. 執行編碼。工具會回報 UTF-8 位元組數量與格式化後的輸出長度,若有孤立的 UTF-16 代理項被取代,則會顯示取代警告。
  4. 複製完整的十六進位輸出。若剪貼簿存取被拒,唯讀結果仍會保留在畫面上,可手動選取。

以兩個字元的 ASCII 字串「Hi」為例,轉換過程是直接的。H 是 U+0048,因此其十六進位位元組為 48。i 是 U+0069,因此其十六進位位元組為 69。串接後,在連續格式下得到 4869,以空格分隔的格式下得到 48 69,加上前綴的格式下則得到 0x48 0x69。位元組數量為 2,格式化後的輸出長度符合所選格式的公式,也不會出現取代警告,因為輸入中不含孤立代理項。

依字元範圍的位元組長度

字元的位元組成本完全取決於其 Unicode 碼位,而非其在畫面上的外觀。下表使用與 Text To HEX 工具相同紀錄的範例,方便讀者驗證對應關係。

字元碼位位元組十六進位(連續)
AU+0041141
éU+00E92c3a9
你U+4F603e4bda0
😀U+1F6004f09f9880

這些位元組長度說明了為何部分「text to hex ASCII」工具會產生令人意外的結果:一段 50 字元的表情符號字串,在連續格式下的十六進位數字並非 100 個,而是 400 個,因為每個表情符號都佔用 4 個位元組。為緩衝區、傳輸協定或資料庫欄位規劃十六進位輸出時,應以位元組數量而非字元數量為基準。

值得了解的邊界情況

Text To HEX 不會對輸入進行正規化或重寫。組合附加符號會保持分解狀態,因此輸入中的「e」後接組合銳音符 U+0301 時,會編碼為 65 cc 81,而非合併為預組成的 U+00E9。換行字元會依您提供的順序編碼;CR、LF 與 CRLF 各自擁有對應的位元組序列,工具不會在三者之間互相轉換。NUL (U+0000) 會成為位元組 00,因此輸入開頭的 NUL 會在輸出開頭產生 00。其他資料不會被視為終止符號。

輸入中開頭的 U+FEFF 會編碼為 ef bb bf,因為 TextEncoder 不會自動加上 BOM。若接著將該輸出帶到對應的 Hex to Text 工具,該解碼器會依其紀錄的規則消耗開頭的 BOM,這代表兩工具之間的往返轉換,要求原始文字不能以 U+FEFF 開頭。位於字串內部(第一個碼位以外的任何位置)的 U+FEFF 則會保留為文字的一部分。

JavaScript 字串採用 UTF-16 編碼,而孤立的高位元或低位元代理碼位並非有效的 Unicode。Text To HEX 工具會以具備代理項配對感知能力的 UTF-16 掃描方式計算這些孤立代理項,並在編碼前將每個取代為 U+FFFD。U+FFFD 會編碼為 ef bf bd,而結果面板會回報發生了多少次取代,因為這些位元組無法再解碼回原始的孤立碼位。

輸入與輸出限制

工具設有明確的配額。輸入最多可包含 1,000,000 個 UTF-16 碼位,而格式化後的輸出最多可包含 4,999,999 個 UTF-16 碼位。在進行任何編碼之前,空輸入以及超過輸入上限的內容會被直接拒絕。格式化長度上限會依所選格式的公式——2n、3n−1 或 5n−1——進行檢查,因此工具能準確判斷某種輸出選擇何時會超出預算。1,000,000 個 ASCII 字元以 0x 前綴格式呈現時,正好產生 4,999,999 個輸出碼位,工具會將此視為邊界值並予以接受。

若某個多位元組 Unicode 字串在較為冗長的格式下會使輸出超過上限,工具會直接回報失敗,而不會切換格式、切割位元組、捨棄尾段或擷取部分內容。完整文字會先進行編碼,接著計算所需的輸出大小,然後檢查是否超出限制,只有在通過檢查後,才會以有界限的位元組區塊進行格式化,最後再將其合併。最終字串長度會與預測值進行比對,作為防禦性的不變式檢查。編輯輸入、變更格式或字母大小寫,或重新開始編碼,皆會清除先前的輸出、錯誤、位元組統計資料、取代警告與複製狀態。

本地處理與隱私

編碼、位元組計算、取代偵測、格式化、顯示與剪貼簿準備作業,皆在當前瀏覽器分頁中透過 TextEncoder API 於本地端執行。不會上傳任何資料,因此含有機密、個人資料或專屬字串的文字都會保留在裝置上。剪貼簿寫入作業會受到保護,以避免使用過時編碼嘗試的結果或已卸載元件的內容;若權限被拒,唯讀結果仍可供手動選取。

十六進位是一種編碼顯示方式,並非加密、雜湊或壓縮。只要擁有位元組與 UTF-8 規則,任何人都能在符合所選解碼器紀錄的開頭 BOM 行為下,還原結構完整的文字。如需進一步了解此方式與在自有腳本中執行編碼器的差異,請參閱 Text to Hex:正確編碼 UTF-8 字串 指南。

延伸閱讀:在 Java 程式碼與瀏覽器工具中解碼 URL 字串。