當編碼器完全在您目前的瀏覽器分頁中執行時，在線使用文字轉十六進位在數學上是安全的，因為十六進位是對您文字已包含之相同 UTF-8 位元組的無失真顯示。您所看到的十六進位數字並非祕密 —— 任何持有這些位元組與 UTF-8 規範的人都能完整還原原始文字，而這正是為什麼真正的隱私問題在於處理過程發生在哪裡，而不是輸出結果長什麼樣子。在遠端伺服器上執行轉換的工具，會將您貼上的任何內容暴露於網路記錄、錯誤處理程序、備份快照以及潛在的濫用之中。使用瀏覽器標準化 TextEncoder API 的工具，例如 Text To HEX 工具，則不會。換句話說，安全性取決於可驗證的行為：這個分頁是否將您的文字傳送出去、是否記錄其限制，以及是否逐位元組保留原始資料？
「安全」對線上編碼工具而言的真正意涵
三項具體的特性區分了安全的線上文字轉十六進位工具與不安全的工具。首先，編碼器必須在本機執行，在現代網頁上意即使用瀏覽器內建的 TextEncoder 介面，而非將請求傳送至後端。其次，工具必須記錄明確的輸入與輸出預算，讓您準確知道它會在何時拒絕貼上內容，而不是默默地截斷或取樣。第三，工具必須說明其對邊角案例的處理方式，例如孤立的代理項、位元組順序標記、組合記號以及 NUL 位元組，因為未記錄的「修正」動作可能會毀損資料。
任何使用自訂編碼器、伺服器往返傳輸，或是針對您貼上之文字進行第三方分析呼叫的工具，根據此定義都是不安全的，無論其介面看起來多麼精緻。一套乾淨的隱私敘事在實務上是可驗證的：開啟瀏覽器的網路面板、貼上敏感輸入、將其編碼，並確認沒有任何外送請求夾帶該文字或產生的十六進位結果。只要有任何一個請求帶著您的內容離開這個分頁，該工具就不適合用於處理敏感性資料。
為何十六進位是編碼格式而非安全性工具
十六進位是一種位置記數系統，將每個位元組改寫為 0–9 與 a–f 中的兩個字元。它與底層位元組陣列為一對一對應，這表示將文字轉換為十六進位等同於在十六進位檢視器中開啟原始位元組 —— 沒有轉換、沒有金鑰、沒有祕密。WHATWG Encoding Standard 定義了如何從 Unicode 純量產生 UTF-8 位元組，而 MDN 記錄了在目前分頁內產生這些位元組至 Uint8Array 的瀏覽器端 TextEncoder.encode API。
這正是為何十六進位輸出絕不應被用於隱藏密碼、權杖或任何其他祕密的原因。如果您的威脅模型是「防止隨意窺視者讀取位元組」，十六進位毫無作用。如果您的威脅模型是「向下游系統證明這些位元組是格式正確的 UTF-8」，那麼十六進位對此非常合適 —— 位元組未經變動，因此可直接送入十六進位轉文字解碼器。Text To HEX 工具正是為第二種用途所打造：從您已可看見的文字產生精確、可驗證的 UTF-8 十六進位，且不更動其中任何一個位元組。
Text to Hex 如何在本機處理您的資料
Text To HEX 工具將管線的每一個階段都保留在瀏覽器中。編碼使用 TextEncoder API 產生 UTF-8 位元組的 Uint8Array，長度計算從位元組數量與所選格式得出精確的格式化長度，格式化以有界區塊走訪位元組陣列並加以接合，剪貼簿準備則從記憶體中的結果字串讀取。不會 POST 任何內容、不會將任何內容記錄至伺服器，亦不會儲存超越目前分頁工作階段狀態之外的任何資料。
該工具亦精確記錄其限制，讓您能在邊界處預測行為。輸入最多可包含 1,000,000 個 UTF-16 程式碼單位 —— 超過此數字一個程式碼單位會在編碼開始前以明確訊息拒絕處理。格式化輸出最多可包含 4,999,999 個 UTF-16 程式碼單位，且邊界值會被接受：一百萬個 ASCII 字元的 0x 前綴格式輸入，會產生剛好 4,999,999 個輸出程式碼單位。詳細格式下的多位元組 Unicode，可能在達到輸入上限之前就先觸及輸出上限，此時工具會回報該失敗，而非切換格式、切片位元組、捨棄後綴或取樣內容。
如何透過 Text To HEX 工具安全地將文字轉換為十六進位
- 在瀏覽器中開啟 Text To HEX 頁面。編碼器、長度計算器、格式化器與剪貼簿輔助工具皆在此分頁內執行，因此無需任何請求將您的內容送出您的裝置。
- 輸入您要編碼的文字，包括輸入欄位所接受的任何 Unicode 字元、空白、換行或 NUL 資料。文字僅保留在記憶體中；此階段不會上傳任何內容。
- 選擇輸出樣式：連續配對如 4869、以空格分隔的位元組如 48 69，或每位元組的權杖如 0x48 0x69。為十六進位數字 A 到 F 選擇大寫或小寫。
- 對文字進行編碼。工具會計算 UTF-8 位元組數、計算任何孤立代理項的替換次數、計算精確的格式化長度，並以有界區塊建構格式化輸出後再行顯示。
- 檢視位元組計數以及若有偵測到孤立代理項時的替換警告，然後複製完整的十六進位字串。即使剪貼簿權限遭到拒絕，結果仍會保留在畫面上，因此您隨時都能手動選取，資料不會離開此分頁。
在純文字、空格分隔與 0x 前綴輸出之間做選擇
這三種輸出樣式是對同一個位元組陣列的呈現選擇。下表摘要說明每種樣式如何將位元組對應至格式化字元，以及格式化器在建構字串前如何檢查輸出預算。
| 樣式 | 位元組 48 69 的範例 | 格式化長度公式 | 分隔符號行為 |
|---|---|---|---|
| 純文字（連續） | 4869 | 2n 個十六進位字元 | 第一個權杖之前與最後一個權杖之後皆無分隔符號 |
| 空格分隔（位元組配對） | 48 69 | 3n − 1 個字元（位元組配對之間有一個 ASCII 空格） | 僅在位元組配對之間插入一個空格 |
| 0x 前綴 | 0x48 0x69 | 5n − 1 個字元（權杖加分隔符） | 將每個位元組寫成 0xNN 並以一個空格分隔 |
在這些樣式之間切換 —— 或翻轉十六進位數字的大小寫 —— 永遠不會改變底層的 UTF-8 位元組，只會改變格式化字串的長度。大寫模式只會變更 a 到 f 的字母；小寫的 0x 標記與位元組值維持不變。若您打算將結果往返轉換回文字，配套的 十六進位轉文字指南 涵蓋了每種樣式的精確剖析規則。
在輸入與輸出限制處會發生什麼事
由於安全性亦意味著可預期的失敗，工具會在編碼開始前拒絕過大的輸入，並在格式化開始前拒絕過大的輸出。超過 1,000,000 個 UTF-16 程式碼單位的輸入會以明確訊息遭拒 —— 編碼器完全不會執行，因此不會產生任何部分位元組。超過 4,999,999 個程式碼單位的輸出，會在從位元組計數與所選語法計算出格式化長度之後、但在大型格式化字串建構之前遭拒，因此工具絕不會配置一個它明知無法保留的字串。
編輯輸入、變更格式或開始新的編碼，會清除先前的輸出、錯誤訊息、位元組統計、替換警告、複製狀態與複製計時器。剪貼簿寫入作業受到世代計數器、掛載狀態檢查以及計時器身分識別的保護，使得較舊權限請求所留下的延遲成功或失敗訊息，無法在較新的編輯、複製或分頁卸載之後恢復過時的狀態。若剪貼簿存取遭到拒絕，完整的唯讀結果仍會保留在畫面上可供手動選取，因此權限遭到拒絕絕不會讓您損失編碼後的輸出。
值得了解的特殊字元處理方式
TextEncoder 不會在前方加上 UTF-8 位元組順序標記，因此一般輸入會直接以第一個字元的位元組開頭。若您的輸入本身以 U+FEFF 開頭，則這些位元組會作為資料進行編碼（EF BB BF），這是因為該字元屬於字串的一部分，而非編碼器添加了詮釋資料。配套的十六進位轉文字解碼器會在其記錄的 BOM 行為下消耗開頭的 EF BB BF，因此要透過這兩個工具進行精確的往返轉換，前提是原始輸入不能以 U+FEFF 開頭。字串內部的 U+FEFF 仍會保留為文字的一部分。
JavaScript 字串為 UTF-16。一個有效的高位加低位代理配對會編碼出一個輔助純量，但孤立的高位或低位代理並非 Unicode 純量，無法在往返轉換中存活。標準化的轉換程序會在 UTF-8 編碼之前，將每個孤立代理程式碼單位替換為 U+FFFD，產生位元組序列 EF BF BD，結果面板會計算並以可見的方式警告這些替換。NUL (U+0000) 會成為位元組 00。CR、LF、Tab 與空白會依您提供的順序進行編碼。組合序列會保持分解形式，除非您的輸入已經是組合形式 —— 舉例來說，字母 e 後接 U+0301 會編碼為 65 CC 81，而不會被默默地改寫為 U+00E9。
該工具不會套用 Unicode 正規化、換行字元轉換、修剪、大小寫轉換、跳脫序列解析或依地區語言而定的改寫。您貼上什麼，經過上述已記錄的代理與 BOM 行為之後，就會被編碼為什麼，不會有其他處理。
若您正在權衡各種選項，如何在瀏覽器中進行二進位到文字的轉換 對此有詳細說明。