文字轉十六進位的轉換會產生相同的 UTF-8 位元組序列，無論你在終端機中執行 xxd，或是將文字貼到瀏覽器型的編碼器中，差別在於位元組在哪裡被處理、工具產生什麼輸出語法，以及 Unicode 邊界情況如何被顯示出來。兩條路徑都從同一條 WHATWG 編碼標準規則開始，該規則將每個 Unicode 純量對應到一到四個 UTF-8 位元組，最後都會產生一串十六進位字串，只要持有位元組並了解 UTF-8 規則的人都能讀懂。因此，兩者之間的選擇取決於工作流程、環境、錯誤回報與格式選項，而不是哪一條路徑在絕對意義上是正確的。選錯路徑通常會浪費時間：命令列工具擅長 shell 熟練度與緊湊的管線，但對格式錯誤的輸入幾乎沒有回饋；而線上編碼器提供更清楚的計數與警告，但會多出剪貼簿的步驟。本文其餘部分會逐步介紹這兩條路徑，讓你能判斷哪一條適合眼前的任務，接著示範當線上編碼器是較佳選擇時，Text To HEX 內部的確切三步驟流程。
命令列工具實際上為文字轉十六進位做了什麼
xxd、od、hexdump 和 printf 等命令列工具會將檔案或串流中的位元組透過十六進位格式化器進行管線處理，藉此轉換文字。xxd 在 Linux 上是首選，因為它能用 -ps 旗標接受純字串參數，並印出連續的小寫十六進位對；`echo -n "Hi" | xxd -ps` 會印出 4869。od 是 POSIX 標準的替代方案，搭配 -An -tx1 可得到每個位元組一個 token，而 BSD 上的 hexdump 行為類似。這些工具皆完全在本機執行，絕不會將文字傳送到遠端伺服器，並產生核心透過 stdin 傳來的位元組序列。最後這點很關鍵：shell 編碼預設值、像 LANG 和 LC_CTYPE 這類的語系變數，以及 shell 本身的引號規則，都可能在工具看到位元組之前先改變它們，這是命令列工作流程中十六進位輸出不符的最常見原因。
輸出語法由各個工具固定。xxd 加上 -ps 會輸出連續的配對，xxd 加上 -p 則會印出相同的配對並在尾端加上換行，而 od 加上 -tx1 會印出以空格分隔的位元組。它們都沒有提供 0x 前綴的模式，都不會對孤立的 UTF-16 代理項發出警告，也不會計算你實際拿到多少位元組。如果你想要大寫的 A 到 F，需要加上旗標（某些分支中是 -u）或下游的 tr 命令。在來回轉換方面，命令列工具也無法告訴你編碼出來的位元組在嚴格解碼器下是否會解碼回完全相同的文字，因此任何「位元組是否成功來回轉換？」的檢查都需要執行反向工具並手動比對。
常見命令列工具並列比較
以下是最廣泛使用的文字轉十六進位命令列工具比較表。表格列出每個工具的典型呼叫方式、輸出語法與實用備註。範例輸入 "Hi" 所顯示的位元組值僅用於說明各工具的語法；對你輸入的實際輸出永遠必須自行執行工具才能得到。
| 工具 | 常用呼叫 | 輸出語法 | 實用備註 |
|---|---|---|---|
| xxd | echo -n "Hi" | xxd -ps | 連續的小寫配對 (4869) | Linux 上最快的路徑；加上 -u 可將 A 到 F 改為大寫；沒有 0x 前綴選項。 |
| xxd -p | echo -n "Hi" | xxd -p | 連續配對加上尾端換行 | 位元組相同，只是會在傾印結尾加上一個換行。 |
| od | echo -n "Hi" | od -An -tx1 | 以空格分隔的位元組 (48 69) | 在未安裝 xxd 時的 POSIX 可攜替代方案。 |
| hexdump -C | echo -n "Hi" | hexdump -C | 標準十六進位加 ASCII 顯示 | 最利於檢視，但不利於將位元組往下游管線傳遞。 |
| printf + od | printf 'Hi' | od -An -tx1 | 以空格分隔的位元組 | 當 echo 的尾端換行會改變位元組數量時很實用。 |
| perl -e + od | perl -e 'print "Hi"' | od -An -tx1 | 以空格分隔的位元組 | 當 shell 對非 ASCII 字元或引號處理不當時很方便。 |
上述所有項目都不會加上 UTF-8 BOM，且在 shell 原封不動地傳遞位元組的前提下，它們對相同輸入都會產生相同的位元組序列。當這些工具似乎對同一個可見字元產生不同的十六進位時，語系問題通常是元凶。
如何使用線上工具將文字轉成十六進位
線上編碼器透過使用瀏覽器內建的 TextEncoder API 來排除語系問題，該 API 在內部一律將 JavaScript 字串視為 UTF-16 處理，並依 WHATWG 編碼標準轉換為 UTF-8 位元組。無論主機作業系統為何，瀏覽器都以一致的方式處理編碼，因此在 Windows、macOS 或 Linux 上於 Text To HEX 輸入相同字串都會產生相同的位元組。下方工具就是這種模式的一個範例：輸入文字、選擇格式、複製結果。
- 輸入文字，包括瀏覽器欄位能容納的任何 Unicode、空白或 NUL 資料。
- 選擇連續配對如 4869、以空格分隔的位元組如 48 69，或每個位元組獨立 token 如 0x48 0x69，並選用小寫或大寫的十六進位數字。
- 進行編碼、檢視位元組計數與替代計數，然後複製完整的十六進位輸出。
這個三步驟流程呼應了手動的命令列管線（文字輸入、位元組輸出、複製結果），同時提供兩個命令列工具很少給的東西：對孤立 UTF-16 代理項的替代警告計數，以及在不需要串接額外工具的情況下，於連續、空格分隔與 0x 前綴輸出之間選擇的能力。對於需要精確、逐位元組一致且能透過嚴格 UTF-8 解碼器（例如配套的 Hex to Text Converter）來回轉換結果的讀者而言，位元組計數與替代計數能在你複製任何內容之前告訴你這次編碼是否無損。
命令列工具常忽略的 UTF-8 邊界情況
在任何相容的編碼器中，UTF-8 的長度規則都相同：ASCII 字元使用一個位元組，常見的拉丁字元如 é 使用兩個位元組，大多數 BMP 字元如 你 使用三個位元組，補充平面的純量如 😀 (U+1F600) 使用四個位元組。具體而言，U+0041 會變成 41，U+00E9 會變成 c3a9，U+4F60 會變成 e4bda0，而 U+1F600 會變成 f09f9880。只要傳遞到位元組組工具的內容是有效的 UTF-8，命令列工具就會遵循這些規則，但當輸入中出現孤立的 UTF-16 代理項時，它們不會提供任何回饋；它們只會直接代入標準的 U+FFFD 替代字元 (EF BF BD) 然後繼續。
在命令列工作流程中還有三種容易忽略的行為。第一，WHATWG TextEncoder 不會加上 BOM，因此一般輸入會從第一個字元的位元組開始；如果輸入本身以 U+FEFF 開頭，則那些位元組會以 EF BB BF 的形式出現，因為它們是資料而非後設資料。第二，孤立的代理項不是 Unicode 純量，因此任何定義明確的編碼器會在輸出位元組之前將它們替換為 U+FFFD。命令列工具會靜默地進行這項處理，而 Text To HEX 會顯示替代計數，讓損失一目了然。第三，組合序列會保持拆解狀態，除非輸入本來就是組合好的，所以 e 加上 U+0301 會變成 65 CC 81，而不是被靜默地合併為 U+00E9。這些都不是 bug；它們是 WHATWG 編碼標準強制要求任何相容 UTF-8 編碼器採用的標準化行為。
隱私、限制與選擇正確的路徑
隱私是選擇其中一條路徑最明確的理由。命令列工具與完全在用戶端執行的瀏覽器型編碼器（例如 Text To HEX）都會將文字與輸出保留在本機，因此不會有任何位元組離開這台機器。風險只會出現在以伺服器為後端的線上轉換器上，那些服務會把輸入 POST 到遠端 API 進行編碼，因此會看到明文並可能記錄下來。命令列工具完全避免了這種風險，但代價是犧牲格式選項與明確的計數。瀏覽器端編碼器同樣避免了這種風險，同時還提供連續、空格分隔與 0x 前綴的輸出以及可見的替代計數。對於處理憑證、權杖或專屬資料的讀者而言，決定性的問題在於所選的線上工具是否在瀏覽器分頁中執行；「在本機執行」與「POST 到伺服器」在使用者可見的差異，就是私密與否的差別。更深入的隱私說明請參見 線上使用文字轉十六進位安全嗎？隱私指南。
兩條路徑的限制也不同。命令列工具受到檔案大小、磁碟空間以及 shell 命令列長度的限制，在大多數 Linux shell 中，後者預設為 ARG_MAX 約 2 MB。瀏覽器編碼器則採用各自明確的預算，WHATWG 與 MDN 文件並未對此加以標準化；每個工具自行決定。例如 Text To HEX 最多接受 1,000,000 個 UTF-16 程式碼單位的輸入，以及最多 4,999,999 個 UTF-16 程式碼單位的格式化輸出，並會以明確訊息拒絕超出上限的內容，而不是默默截斷。這個界線是精確的：100 萬個 ASCII 輸入字元以 0x 前綴格式輸出時，會恰好產生 4,999,999 個輸出程式碼單位，而工具會在建構龐大的格式化字串之前強制執行這個上限。
實際的決策樹很簡短。當文字已在磁碟上、需要將位元組管線送入另一個工具，或沒有瀏覽器可用時，使用命令列。當你需要明確的格式選項、替代警告、位元組計數，或輸入來自剪貼簿或聊天視窗時，使用像 Text To HEX 這樣的瀏覽器編碼器。選擇你信任能將位元組保留在本機的工具。對命令列而言這永遠成立，對線上工具而言，則只有當工具明確在瀏覽器中執行時才成立。
想進一步了解，請參閱 Base32 解碼：五位元群組如何重建 UTF-8 文字。