Text to hex 編碼會產生組成一段文字的每個 UTF-8 位元組的十六進位表示法，一個可靠的 text to hex 替代方案必須回傳這些確切的位元組，而不是用猜的方式判斷編碼。這款以瀏覽器為基礎的 Text To HEX 工具透過瀏覽器內建的 TextEncoder API 遵循 WHATWG Encoding Standard，因此 ASCII 會變成一個位元組，常見的拉丁重音字元會變成兩個，大多數 BMP 字元會變成三個，而增補的 Unicode 純量會變成四個。接著每個位元組都會寫成兩個十六進位數字，同一組位元組陣列提供三種格式選擇：連續成對的形式如 4869、以空格分隔成對的形式如 48 69，或帶有 0x 前綴的形式如 0x48 0x69。a 到 f 的字母大小寫可以切換，絕不會加上 BOM，而包括計算長度、格式化、顯示與剪貼簿準備在內的每個步驟，都會在目前的分頁本機執行，因此輸入與輸出永遠不會離開瀏覽器。
為什麼有人會搜尋 text to hex 替代方案
任何把文字字串轉成十六進位的人都知道，結果的可信度取決於背後的編碼步驟。許多線上轉換器會截斷大型資料、遺漏高位 BMP 或增補字元、在未說明的情況下加上位元組順序記號，或把輸出限制在幾百個位元組以內。有些會把輸入上傳到遠端伺服器處理，當資料是私密的時候，這根本不可行。像 xxd 或 hexdump 這類命令列工具在不同平台上行為不一，而以 Windows-1252 為後備方案的工具，可能會在使用者原本期望維持純 UTF-8 的情況下，悄悄改寫字元。搜尋 text to hex 替代方案的人，通常代表他們已經遇到上述其中一個問題，想要一個確定性、本機、精確 UTF-8 的方案，並具備可預期的格式選項。
同樣的困擾也促使讀者在相鄰的類別中尋找 以本機方式取代遠端 API 式轉換器的替代方案。無論目標是二進位、Base64 還是十六進位，背後的需求都是一樣的：一個行為符合已發布標準、限制寫得清清楚楚、輸出可以逐位元組驗證的轉換器。
這個替代方案有哪些不同做法
Text To HEX 工具以 WHATWG Encoding Standard 所定義的標準 TextEncoder.encode 方法為基礎，這代表 UTF-8 輸出是由驅動現代網頁平台的同一套程式碼路徑產生的，而不是靠自訂編解碼器。這個編碼器對 JavaScript 的 UTF-16 字串具備配對感知能力：一組有效的高低代理對（surrogate pair）代表一個增補 Unicode 純量，會照常編碼；而孤立的高位或低位代理則會在 UTF-8 編碼前被替換成 U+FFFD，產生位元組序列 EF BF BD。結果面板會計算並明顯警示這類替換，因為把位元組解碼回去無法重建原本孤立的碼元。
還有三項行為讓這個替代方案有別於一般的網頁轉換器。第一，這個編碼器不會加上 UTF-8 的 BOM；如果輸入內含字面上的 U+FEFF，那些位元組會照樣被當成資料編碼。第二，輸入不會被正規化：組合符號會維持分解狀態，除非輸入原本就是已組合的形式，因此字母 e 後面接著 U+0301 會產生 65 CC 81，而不會被悄悄改寫成 U+00E9。第三，格式化後的輸出長度會事先計算好，並在建立大型字串之前先做檢查，因此只超出一個碼元的情況會被明確拒絕並顯示訊息，而不會產生被截斷的結果。
如何用這個 text to hex 替代方案編碼文字
- 開啟 Text To HEX 工具，並在輸入欄位輸入你想轉換的文字，包括瀏覽器欄位能容納的任何 Unicode、空白字元或 NUL 資料。
- 選擇一種輸出樣式：連續成對如 4869、以空格分隔成對如 48 69，或帶有 0x 前綴的形式如 0x48 0x69。
- 選擇小寫或大寫的十六進位數字。大小寫只會改變 a 到 f 這幾個字母；位元組數值與小寫的 0x 記號都維持不變。
- 執行編碼，並檢視結果面板中顯示的位元組數、格式化後的輸出長度，以及任何孤立代理替換的計數。
- 用複製控制項複製完整的十六進位輸出。如果剪貼簿存取被拒絕，唯讀的結果仍可供手動選取。
- 編輯輸入內容、變更格式或大小寫，或重新開始一次編碼，都會清除先前的輸出、位元組統計、替換警示與複製狀態。
選擇正確的輸出格式
這三種輸出格式只是針對同一組 UTF-8 位元組陣列的呈現方式選擇，因此變更格式或字母大小寫絕不會改變編碼後的位元組。它們確實會改變格式化後的輸出長度，其計算方式為：連續成對為 2n，以空格分隔成對為 3n 減 1，帶有 0x 前綴的形式為 5n 減 1，其中 n 是 UTF-8 位元組的數量。以兩位元組的輸入 Hi 為例，結果分別是：純格式四個碼元（4869）、空格格式五個碼元（48 69）、前綴格式九個碼元（0x48 0x69）。純格式最精簡，容易貼進單行原始碼。空格格式對視覺掃描較友善，因為每個位元組各自獨立呈現。前綴格式對程式碼產生器、記錄檔分析工具，以及任何預期字面 0xNN 記號的消費端來說是最安全的選擇。
| 格式 | 公式（n 個位元組） | 以 Hi 為例 | 最適合 |
|---|---|---|---|
| 連續成對 | 2n | 4869 | 精簡的傾印、原始碼字面值 |
| 以空格分隔 | 3n − 1 | 48 69 | 視覺掃描、除錯 |
| 帶有 0x 前綴的記號 | 5n − 1 | 0x48 0x69 | 具記號感知的剖析器、組合語言、設定檔 |
同樣的公式也決定了輸出的硬性上限。由於格式化後的輸出上限是 4,999,999 個 UTF-16 碼元，任何超出所選格式計算長度的請求，都會在建立任何字串之前就被拒絕。這就是一百萬個 ASCII 輸入字元以 0x 前綴格式輸出恰好產生 4,999,999 個輸出碼元、因而被接受，與只多一個輸入碼元或輸出碼元、因而被明確拒絕並顯示訊息，這兩者之間的差別。
其他工具容易出錯的 Unicode 邊界情況
網頁文字經常包含超出 ASCII 範圍的字元，而一個處理不好這些字元的十六進位編碼器，會產生一個無法解碼回去的結果。這個替代方案文件中的四個參考案例，完整展示了預期的行為：U+0041 變成 41，U+00E9 變成 c3a9，U+4F60 變成 e4bda0，U+1F600 變成 f09f9880。這幾個對應分別是一、二、三、四個位元組，與標準的 UTF-8 寬度相符。有幾款線上轉換器只支援到三個位元組，會把 U+1F600 弄壞或替換成問號；這個替代方案使用 WHATWG Encoding Standard 所定義的標準化 TextEncoder 轉換為純量值字串，因此增補字元能完好保留。
其他邊界情況也會被原樣忠實處理，而不會被正規化。NUL 字元 U+0000 會變成位元組 00，CR、LF、定位字元與空格會依照輸入的原本順序編碼，編輯輸入內容或切換格式，都不會觸發換行轉換、去除空白、大小寫折疊、跳脫解析或依語系改寫。因此這個工具是使用者所輸入確切位元組的忠實記錄者。唯一無法精確往返的字元，是輸入中內部的 U+FEFF，以及孤立的 UTF-16 代理，這兩種情況都會在結果面板中標示出來，讓使用者可以修正輸入，或接受所選解碼器已記載的行為。
硬性限制：這個工具接受與拒絕的內容
有兩個明確的上限。輸入欄位最多可容納 1,000,000 個 UTF-16 碼元，格式化後的輸出最多可容納 4,999,999 個 UTF-16 碼元。只要超出對應驗證器一個輸入碼元或一個輸出碼元，就會被明確拒絕並顯示訊息，這代表這個工具絕不會悄悄截斷或抽樣內容。完整文字會先完成編碼才進行格式化，所需的輸出大小會依位元組數與所選語法計算出來，而這項計算會在建立大型格式化字串之前先被檢查。
以較冗長的格式呈現多位元組 Unicode 時，可能會在觸及輸入上限之前就先觸及輸出上限，這個工具會回報這項失敗，而不是切換格式、切割位元組、捨去尾端或抽樣內容。格式化接著會以有界的位元組區塊進行，並把每個區塊拼接起來，這能降低暫時記憶體配置的高峰，而不會改變或限制輸出，最終字串的長度也會依已驗證的預測值做檢查，作為一項防禦性不變量。搭配使用的 Hex to Text Converter 會依照其記載的 TextDecoder BOM 行為，吃掉開頭的 EF BB BF，因此透過該特定工具進行精確往返，還需要原始文字開頭不是 U+FEFF。在格式正確的 Unicode，以及這一項開頭 BOM 的但書之下，text to hex 再 to text 的往返轉換是精確的。
如需更深入的說明，請參閱 AES Encryption Online API Alternative: Browser-Side。