文字轉十六進位編碼會將 UTF-8 字串的每個位元組轉成兩個十六進位數字,因此七個位元組的 ASCII 字串 "Lizely!" 會變成 14 個字元的十六進位字串 4c697a656c7921。這種對應關係非常直接:每個輸入位元組會精準產生兩個輸出字元,字元來自 0–9 與 a–f,而多位元組字元(例如 é、中或 🙂)會展開成兩個、三個或四個 UTF-8 位元組,每個位元組各自佔用一個兩位數的欄位。這種位元組對位元組的精確度,正是十六進位傾印在協定追蹤、韌體除錯、檔案標頭,以及任何不能發生靜默字元替換的低階資料交換場景中值得信賴的原因。
人們會從截然不同的起點接觸到這個主題。正在設計二進位協定的開發人員,需要知道一個字串實際透過線路傳輸時會產生哪些位元組;檢視封包擷取結果的逆向工程師,想要從十六進位欄位重建出 ASCII;正在學習字元編碼的學生,則想一次看清楚 "café" 與 "cafe" 為何會展開成不同的結果。每種使用情境都共享同一個底層需求:轉換必須嚴格遵循 UTF-8、保留 NUL 位元組與空白字元,而且絕不能在遇到不支援的字元時,默默把它換成替代字元。一個可靠的線上轉換器應該把這些保證直接攤在使用者眼前,而不是藏在黑箱結果之後。
"text to hex" 真正的意思
十六進位是以 16 為基底的數字系統,使用 0 到 9 的數字與 a 到 f 的字母。由於一個十六進位數字恰好承載 4 位元的資訊,兩個十六進位數字合起來就描述一個位元組(8 位元)。當你把文字編碼成十六進位時,轉換器會先以一種字元編碼——在現代網路上幾乎一定是 UTF-8——把輸入解讀成一系列位元組,然後把每個位元組寫成兩個十六進位數字。
編碼的選擇比大多數教學文章承認的更為關鍵。宣稱能執行 "ASCII to hex" 的老舊工具,遇到非 ASCII 字元時會直接換成問號或整個丟掉;對 "hello" 來說沒問題,但碰到 "こんにちは" 就是一場災難。具備 UTF-8 感知能力的轉換器則能完整保留所有字元:"café" 中的 é 是兩位元組序列 C3 A9,日文平假名 こ 是 E3 81 93,而 🙂 表情符號則是四位元組序列 F0 9F 99 82。看到精確的位元組往往是這項作業的全部目的。
十六進位輸出有三種常見格式。連續輸出把所有位元組對緊緊相連、中間沒有分隔,適合把值塞進 URL 參數或單行日誌;以空白分隔的輸出會在每個位元組之間插入一個空白,在固定寬度字型下對齊得整整齊齊,也與大多數封包分析器的呈現方式一致。0x 前綴格式則在每個位元組前面加上 "0x",對應 C、Rust、Go 與 Python 原始碼中以 0x4c、0x69、0x7a 等方式撰寫位元組字面值的慣例。
為何 UTF-8 感知與替代警告很重要
瀏覽器、文字欄位與剪貼簿複製貼上的流程,可能會默默替換掉它們無法表示的字元。Unicode 標準定義 U+FFFD REPLACEMENT CHARACTER,作為「原始位元組序列無法解碼」的明確標記;一個表現良好的轉換器會誠實呈現它不得不產生多少次這種替代,而不是假裝輸入是乾淨的。原本是兩位元組字元 é,若經過一個預期為 Latin-1 的流程,通常會以三位元組序列 EF BF BD 呈現,接著再編碼為 efbfbd——這是值得認得的指紋。
Text To HEX 工具在編碼後會同時回報輸入位元組數與替代次數,讓你在錯誤繼續擴散之前就抓到意外毀損。它也能正確處理 NUL 位元組(0x00)、定位字元(tab)與尾端空白,而不會把它們修剪掉——當你正在編碼恰好含有可列印文字的二進位區塊,或反之亦然時,這是不可或缺的特性。想要更深入了解位元組反向流動的情形,可以參考 Hex to Text Converter,它在解碼時同樣遵守嚴格規則,當位元組沒有落在有效的 UTF-8 邊界上時,絕不會默默捏造字元。
如何在線上把文字轉成十六進位
- 在瀏覽器中開啟 Text To HEX 工具。
- 把你想編碼的文字貼上或輸入到輸入欄位中。視需要一併保留任何 Unicode、空白或 NUL 位元組——這個欄位會原封不動地保留它們。
- 挑選輸出格式:連續(無分隔)、以空白分隔,或 0x 前綴。並依你的程式碼或規格慣例,選擇小寫或大寫的十六進位數字。
- 執行編碼器。檢視工具回報的位元組數與 Unicode 替代次數;如果任何一個數字看起來不對勁,先修正輸入再複製。
- 把完整的十六進位輸出複製到剪貼簿,再貼到你的程式碼、日誌檔、文件或協定分析器中。
一眼讀懂十六進位傾印
一旦手上有一串十六進位字串,認得幾個模式就能大幅加速人工檢視。可列印的 ASCII 字元(代碼 0x20 到 0x7e)會以各自的兩位數十六進位值呈現——0x48 是 'H'、0x69 是 'i';而控制字元,例如換行(0x0a)、歸位(0x0d)與定位(tab,0x09),則會以較短的代碼出現,經常聚集在協定標頭處。多位元組 UTF-8 序列遵循 Unicode 標準定義的嚴謹位元模式:接續位元組的開頭一定是位元 10,而首位的位元組的前幾位則告訴你後面還會接著多少個位元組。舉例來說,表情符號 🙂 編碼為 F0 9F 99 82,其中 F0 宣告這是一個四位元組序列,而每個後續位元組以 8 或 9 開頭,符合 10xxxxxx 的接續模式。
| 輸入字元 | UTF-8 位元組(十六進位) | 編碼輸出 |
|---|---|---|
| A | 1 個位元組 | 41 |
| é | 2 個位元組 | c3 a9 |
| 中 | 3 個位元組 | e4 b8 ad |
| 🙂 | 4 個位元組 | f0 9f 99 82 |
這個表格定性地說明了字元複雜度與位元組數之間的關係;é、中與 🙂 所顯示的精確十六進位值,是 Unicode 標準定義的正式 UTF-8 編碼,你可以透過上方連結的工具在幾秒鐘內自行驗證。
把文字編碼成十六進位時的常見陷阱
第一個陷阱是輕信一個不告訴你它假設哪種編碼的轉換器。一個會對 é 默默產出 "3f" 的工具,已經把你的字元換成了問號,這是一組與原始資料實際內容截然不同的位元組。務必留意明確的替代次數,或選擇讓你自己指定編碼的選項。
第二個陷阱是把連續輸出與分隔輸出混為一談。許多線路格式與校驗和常式都預期固定的排版,只要多一個或少一個空白,就會打斷以兩個字元為單位掃描的解析器。挑選你的下游程式碼所預期的格式並堅持使用;Text To HEX 工具提供三種常見排版,讓你不必手動編輯就能對應慣例。
第三個陷阱是忘了十六進位輸出在某些情境下是大小寫敏感的。C 與 C++ 的十六進位字面值不區分大小寫,但某些十六進位摘要、簽章格式與憑證指紋,慣例上會全用小寫或全用大寫。在工具中選擇「uppercase」可以省下手動轉換的步驟,並避免在逐位元組比對字串的程式碼中潛藏的 bug。
第四個陷阱是把十六進位當成安全性或雜湊的工具來使用。十六進位是一種表示法,不是加密:任何拿到十六進位字串的人都擁有原始位元組。如果你需要機密性,請在它之上疊加真正的加密演算法;若你需要完整性,則應使用雜湊函式。password hash guide 詳細說明了兩者之間的差異。
text-to-hex 在實際工作中出現的場景
開發人員在除錯 HTTP/2 訊框、WebSocket 承載內容或自訂 TCP 訊息等二進位協定時,經常會借助十六進位。網路分析器預設以十六進位顯示位元組,能夠把字串轉成同樣的檢視方式,讓你更容易抓到框架上的錯誤。嵌入式韌體開發人員同樣以此方式檢視 flash 內容與 EEPROM 映像:十六進位既精簡又無損,而且可列印。
安全研究人員與 CTF 玩家把字串轉成十六進位,以便與記憶體傾印比對、建構用於漏洞開發的承載字串,以及檢查經過混淆的 JavaScript 或 shellcode。guide on converting hex dumps to text 以同樣重視 UTF-8 邊界的態度,涵蓋了反向的工作流程。
教育工作者與學生利用十六進位讓字元編碼變得具體可感。展示 "café" 會產生 63 61 66 c3 a9,而 "cafe" 會產生 63 61 66 65,讓附加音字元所付出的成本一目了然,進而促成轉向具備 Unicode 感知能力的工具。把編碼器與 Binary To Text 轉換器搭配使用,就能把同樣的教學延伸到位元——每個十六進位數字在那裡會變成 4 位元。
把這個編碼器與相關工具搭配使用
十六進位處於一族表示法的中段。位元比它低一個層級,把每個位元呈現為 0 或 1;Text to Binary Converter 把同一組 UTF-8 位元組渲染成 8 位數的二進位字串。Base64 則高一個層級,每 3 個位元組打包成 4 個可列印的 ASCII 字元;Base64 Encode / Decode 以完整的 Unicode 支援處理這個往返。URL 編碼又是另一個層級,設計目的是在查詢字串中安全傳輸,而不是用於精簡儲存;URL Decoder 涵蓋百分比編碼的值。
若協定偏好古典密碼勝過現代編碼,Caesar Cipher Decoder 與 Vigenere Cipher Decoder 涵蓋了歷史悠期的移位。當目的只是快速混淆而非真正的安全性時,ROT13 Encoder Decoder 仍是 ASCII 字母一種實用的可逆轉換。
若要探討超出十六進位之外的其他字元集問題,ASCII Converter 顯示原始 7 位元 ASCII 範圍的十進位代碼點,而 Morse Code Translator 則把文字對應到一套完全不同的符號系統,並提供音訊播放以驗證時序。每個工具都在你的瀏覽器中本地執行,因此含有敏感資訊的字串——API 金鑰、除錯承載內容、客戶資料——永遠不會離開你的機器。
A quick worked example
Take the string "Hi". It contains two ASCII characters, each one byte in UTF-8: 'H' is code point U+0048, encoded as the single byte 0x48, and 'i' is code point U+0069, encoded as the single byte 0x69. Concatenated with no separator, the hex output is 4869. With a space separator it is 48 69. With the 0x prefix it is 0x48 0x69. The byte count is 2 and the replacement count is 0. Try the same workflow with "Hé" and the result length jumps from 4 hex characters to 6, because é adds the byte 0xc3 and 0xa9 — a visible reminder that UTF-8 is a variable-width encoding and that "text to hex" really means "UTF-8 bytes to hex".
If you're weighing options, Decode Base32 Strings Back to Readable Text in One Click covers this in detail.
If you're weighing options, Encrypt and Decrypt Text with AES-256 Online in Your Browser covers this in detail.