Notepad++ 是一款文字編輯器，只有在額外安裝外掛或第 3 方腳本時，才會把位元組視為十六進位處理，這正是為什麼「convert hex to text notepad ++」通常會變成一連串複製貼上的步驟，而無法以單一乾淨的動作完成。Hex to Text Converter 將同樣的工作完整地在你的瀏覽器中執行，可解析連續、以空白分隔或 0xNN 格式的十六進位位元組，並使用嚴格的 UTF-8 解碼器進行解碼，該解碼器在遇到錯誤序列時不會回傳部分結果。前端的位元組順序標記會由標準的 TextDecoder 包裝函式自動消耗，位元組 00 會保留為真正的 NUL 字元，而大寫或小寫的十六進位數字會產生完全相同的結果。編輯輸入、切換語法選項或重新開始解碼，都會立即清除先前的結果、錯誤以及複製狀態，因此你所看到的內容永遠與你輸入的內容一致。純粹模式會拒絕奇數的半位元組、逗號、連字號、冒號、方括號以及非十六進位的字母；前置模式則不允許與純粹模式的群組混合使用。原始輸入的上限為 2,000,000 個 UTF-16 程式碼單位，解析後位元組的上限為 1,000,000 個，解碼後文字的上限則為 1,000,000 個 UTF-16 程式碼單位，每一項都會被精確地強制執行。
為什麼 Notepad++ 把十六進位視為文字而非位元組
Notepad++ 以文字檢視開啟檔案，這表示每個位元組都會透過一個字碼頁進行解讀，通常是系統預設值或檔案本身所宣告的字碼頁。內建的外掛生態系統提供了十六進位檢視功能，但「檢視」與「轉換」是不同的兩件事。
當你在 Notepad++ 安裝十六進位編輯器外掛時，可以查看當前檔案背後的位元組。這個顯示本身只是側邊面板，而非轉換器。若要真的從中取出文字，你必須切換回文字檢視、確認檔案開啟時所使用的編碼，然後祈禱該檔案的位元組剛好能在該編碼下被視為有效。以上這些步驟中，沒有一個算是真正的十六進位轉文字動作。
如果來源是程式碼檔案中的一段十六進位字串、從記錄檔擷取的片段，或從十六進位傾印中貼出的一整欄，Notepad++ 會把那些字元顯示為字面上的 ASCII 文字 "48 65 6c 6c 6f"，而不是位元組 0x48 0x65 0x6C 0x6C 0x6F。若要把這段 ASCII 文字轉成 "Hello" 這個字，你必須撰寫或尋找一段腳本、把字串複製到另一個網站，或自行建立一個小型巨集外掛。最終結果取決於該腳本對錯誤輸入的容忍度，而這通常沒有文件說明。
即使真的有腳本執行了轉換，Notepad++ 也並未提供內建且嚴格的 UTF-8 檢查。在 JavaScript、Python 或 Windows 主控台中進行寬鬆的位元組對字串轉型，可能會悄悄地把無效序列替換為 U+FFFD 取代字元，或者更糟的是，丟棄部分前綴並假裝其餘部分已完成解碼。而這正是嚴格的瀏覽器工具設計來避免的失敗模式。
如何在瀏覽器中將十六進位轉換為文字
- 在瀏覽器分頁中開啟 Hex to Text Converter。不需要安裝、帳號或外掛。
- 將你的十六進位貼到輸入欄位中。連續配對如 48656c6c6f、以空白分隔的群組如 48 65 6c 6c 6f，以及逐位元組的 0xNN 標記如 0x48 0x65 0x6c 0x6c 0x6f，在各自的模式下都可被接受。
- 選擇允許的語法。可獨立切換 ASCII 空白分隔符與 0x 前綴；純粹與前置形式不可在同一輸入中混用。
- 執行解碼。工具會先檢查 2,000,000 個程式碼單位的原始上限，接著解析嚴格的位元組，再驗證 1,000,000 位元組的輸出上限，最後以嚴格的 UTF-8 進行解碼。
- 讀取結果與位元組數。若出現錯誤，請修正其所指出的確切問題，例如奇數半位元組、語法混用、無效的位元組序列或超出上限，然後重新解碼。
- 複製解碼後的文字。只要有可複製的文字，複製按鈕就會啟用，並會在原地回報剪貼簿的成敗狀態。
轉換器可接受的十六進位格式
Notepad++ 的外掛與臨時腳本通常會接受解析作者當時隨手寫下的任何格式。Hex to Text Converter 則採用更嚴格且有文件記載的語法，並由兩個切換選項控制。
| 面向 | Notepad++ 外掛或腳本 | Hex to Text Converter |
|---|---|---|
| 連續配對，例如 48656c6c6f | 取決於腳本的解析器 | 在純粹模式下接受 |
| 以 ASCII 空位分隔的位元組，例如 48 65 6c | 通常會被接受 | 在啟用空白分隔時接受 |
| 0xNN 標記，例如 0x48 0x65 | 鮮少與純粹形式區分 | 在獨立的前置模式下接受 |
| 混合的純粹與 0xNN 輸入 | 有時會被默默調和 | 以語法混用為由拒絕 |
| 奇數半位元組，例如 4 8 | 可能會自動合併為 48 | 予以拒絕；分隔符絕不會修補半位元組 |
| UTF-8 驗證 | 預設無嚴格檢查 | 嚴格模式；錯誤序列會回傳錯誤 |
| 前置 BOM EF BB BF | 經常被保留為 U+FEFF | 由標準包裝函式消耗 |
| 資料位置 | 磁碟上的檔案加上任何雲端步驟 | 本機瀏覽器分輯；無任何上傳 |
純粹模式刻意設計得很嚴格。每個群組只能包含十六進位數字 0 到 9、A 到 F 或 a 到 f，且必須包含偶數個位數。一個群組可以包含多個位元組，因此 4869 與 48 69 在啟用空白分隔時皆為有效。大寫與小寫的數字會產生相同的位元組值。可啟用的分隔符僅限於 ASCII 空格、水平製表符、換行符、換頁符與歸位符；其他 Unicode 空白字元（包括不中斷空格）會被拒絕，而不是被悄悄標準化。
0x 選項本身就是一個獨立的模式。只要出現任何大小寫不拘的 0x 前綴，每個標記就必須正好是 0xNN，標記之間必須以啟用的 ASCII 空白分隔，且同一輸入中不能出現純粹形式的標記。諸如 0x410x42、0x041、僅一個半位元組的 0x4、單獨的 0x，或標記之間以逗號分隔等格式，都屬於錯誤。停用前置選項時，會直接拒絕前置輸入，而不是默默地去掉前綴。
此工具中「有效的 UTF-8」代表什麼
此轉換器使用瀏覽器的 TextDecoder 並設定 fatal 旗標，因此只要出現一個錯誤位元組，就會中止整個解碼程序，而不是產生部分結果。這與預設的取代模式正好相反，後者會默默插入 U+FFFD，讓損壞的位元組看起來像是正常的文字。
此解碼器遵循 WHATWG Encoding Standard 與 RFC 3629，這表示單位元組的 ASCII 值 00 到 7F 為有效，雙位元組序列可編碼 U+0080 到 U+07FF，三位元組序列涵蓋 U+0800 到 U+FFFF，四位元組序列則涵蓋 U+10000 到 U+10FFFF。獨立的續接位元組、被截斷的多位元組序列、過長編碼、編碼後的代理 U+D800 到 U+DFFF，以及超過 U+10FFFF 的值，都屬於錯誤。前端的位元組順序標記 EF BB BF 會被消耗；若同樣的位元組出現在文字中間，則會成為真正的 U+FEFF 字元。位元組 00 是真正的 NUL，不會被當作 C 樣式字串的終止符。
以下幾組具體的配對可方便驗證規則。雙位元組序列 C3 A9 為 é。三位元組序列 E4 B8 AD 為中文字元 中。四位元組序列 F0 9F 98 80 為笑臉 😀。獨立的續接位元組 80 單獨存在是無效的；過長的 C0 AF 是無效的；以 E4 B8 開頭、被截斷的三位元組序列是無效的；編碼後的代理 ED A0 80 是無效的；超過 U+10FFFF 的四位元組值也是無效的。介面會在原地說明每一種結果。
脫離 Notepad++ 時常見的陷阱
來自 Notepad++ 生態的三種模式，往往在第一次將十六進位貼進嚴格工具時就會出問題。
首先，Notepad++ 腳本中的分隔符通常較為寬鬆。一段像 48-65:6C,6F 的貼上內容看似十六進位，卻使用了連字號、冒號與逗號。此轉換器會拒絕這三種字元；在啟用空白選項時，只有 ASCII 空格、水平製表符、換行符、換頁符與歸位符會被接受，且不會有任何一個被悄悄替換為其他空白字元。分隔符也絕不會修補不完整的半位元組，因此 "4 8" 會被拒絕，而不會變成 "48"。
其次，BOM 與 NUL 經常被誤處理。以 EF BB BF 開頭的貼上內容，在許多檔案格式中是真正的位元組順序標記。此工具會將其消耗，因此顯示出來的輸出就是檔案其餘部分實際所代表的內容，而不會帶著一個鬼魅般的前置 U+FEFF。承載資料中間出現的位元組 00 會成為真正的 NUL 字元，當這段文字再被送回另一個工具時，這一點可能至關重要。
第三，部分輸出是無聲的失敗模式。預設的 TextDecoder、腳本語言中寬鬆的型別轉型，以及多個標榜快速「decode hex」的網站，都會回傳直到第一個錯誤位元組之前的所有內容，並假裝其餘輸入為空。這裡使用的嚴格模式讓這種情況不可能發生，因此解碼結果要不是回傳完整文字，就是回傳錯誤而不產生任何結果。
限制、上限與相關工具
此轉換器受到三個獨立上限的限制。原始輸入最多只能包含 2,000,000 個 UTF-16 程式碼單位，解析後的輸出最多只能包含 1,000,000 個位元組，解碼後的文字最多只能包含 1,000,000 個 UTF-16 程式碼單位。每個上限都正好接受邊界值，並以「未解碼任何內容」或「未截斷」的措辭拒絕超過一個單位的情況。由於前置記法每個位元組會使用較多的來源字元，因此可能會比位元組上限更早觸及原始輸入上限；這屬於預期行為，並會予以回報。
編輯十六進位輸入、變更任一語法選項，或重新開始解碼，都會立即清除先前的輸出、錯誤、已複製狀態以及複製計時器。剪貼簿的寫入是非同步的，並由世代編號保護，因此在輸入已變更後，較晚到期的授權成功或失敗都不會更新介面。
此工具僅支援 UTF-8。它不會猜測 Windows-1252、ISO-8859-1、UTF-16 或 Shift_JIS，因為默默猜測可能會改變位元組的意義。它不會解讀整數字面值、反轉位元組順序、移除 NUL、求值跳脫序列、解析帶有位址的十六進位傾印，或解密資料。若要處理格式化的記憶體傾印，請先透過可信的工作流程擷取位元組欄位；若輸入是二進位而非十六進位，請使用 Binary to Text 工具；若要處理 Base64 傳輸資料，請使用 Base64 Encode and Decode 工具。如需進一步了解如何實際上將十六進位位元組視為 UTF-8 來讀取，可參考這份將十六進位字串視為 UTF-8 位元組來讀取的姊妹指南，其中提供了更多範例。
延伸閱讀：ROT13 命令列與線上工具：選擇正確的路線。