跳至主要內容
Lizely

十六進位轉文字工具

依據明確的分隔符與 0x 字首規則解析十六進位位元組，僅解碼完整有效的 UTF-8，不進行靜默取代。

隱私權：你的檔案不會離開裝置，所有處理均在瀏覽器本機完成。

使用方式

  1. 1.貼上連續的偶數長度十六進位組合或精確的 0xNN 位元組標記，然後選擇哪些 ASCII 分隔符與字首被允許。
  2. 2.以致命 UTF-8 驗證進行解碼；修正任何報告的奇數半字元、混合語法、無效位元組序列或預算錯誤。
  3. 3.檢視解碼文字與位元組數量，然後若瀏覽器允許剪貼簿存取，即可複製文字。

關於十六進位轉文字工具

十六進位轉文字工具將十六進位位元組表示法轉換為 UTF-8 文字，全程在當前瀏覽器標籤頁中完成。可貼上連續的對應組合，如 48656c6c6f、空白分隔的組合，如 48 65 6c 6c 6f，或明確的每字元標記，如 0x48 0x65 0x6c 0x6c 0x6f。選擇是否允許普通 ASCII 空白分隔符與 0x 字首，然後進行解碼。成功解碼的文字會顯示在只讀欄位中，並可複製。不會將原始位元組、解碼字元或剪貼簿內容上傳至 Lizely。

接受的語法刻意比任意程式師表達更為狹窄。在純模式下，每組必須僅包含十六進位數字 0–9、A–F 或 a–f，且必須為偶數位元。一組可包含多個位元，因此當空白分隔符啟用時，4869 與 48 69 均為有效。分隔符永遠無法修復不完整的半字元：4 8 會被拒絕，而非靜默轉為 48。奇數長度輸入、逗號、連字元、冒號、括號、轉義、註解、單位標籤及非十六進位字母皆為錯誤。大寫與小寫數字產生相同的位元組值。

空白支援可配置且範圍明確。啟用的分隔符僅限於 ASCII 空白、水平製表、換行、換頁與歸位字元。其他 Unicode 空白字元，包括不破斷空白，將被拒絕，而非無形地標準化。當選項關閉時，任何這些 ASCII 空白字元亦將被拒絕。原始輸入在執行 2,000,000 UTF-16 程式碼單元預算檢查前，絕不會被修剪或重寫。啟用的前導或尾導 ASCII 空白字元可作為有效內容的分隔，但僅空白輸入仍為錯誤。

0x 選項使用獨立的明確模式。若出現任何不區分大小寫的 0x 字首，則每個標記必須恰好為 0xNN，其中 NN 為一個位元，且標記必須以啟用的 ASCII 空白分隔。純模式與帶字首模式不可混合，因此 0x41 42 會失敗。連線字首如 0x410x42、三碼標記如 0x041、單半字元標記、標記間的逗號以及純 0x 均會失敗。若空白被關閉，帶字首模式僅能包含一個 0xNN 標記，因為沒有允許的標記分隔符。關閉字首功能將拒絕帶字首輸入，而非在使用者不知情的情況下移除字首。

經過嚴格的十六進位解析後，瀏覽器會使用 TextDecoder 將完整的位元組陣列解碼為 UTF-8，並進行致命錯誤處理。致命模式很重要：預設的取代解碼器在位元組有誤時會插入 U+FFFD，使損壞的輸入看起來像成功解碼的文字。此工具則會回傳錯誤，並對於零散的連續位元組、截斷的多位元組序列、過長編碼、UTF-8 的代理區碼點以及超過 U+10FFFF 的值，一律不產生部分輸出。它從不捨棄錯誤的字尾、返回較早的有效字首，或插入取代字元。

UTF-8 支援單位元組 ASCII 與有效的兩、三、四位元組標量編碼。典型案例包括 ASCII、U+00E9、兩個 CJK 字元、一個補充表情符標量，以及 U+10FFFF 最大邊界。錯誤案例包括單獨的續位元、過長的 C0 AF 形式、截斷的三位元組序列、編碼的代理、四位元組值超過 U+10FFFF，以及部分 BOM。這些檢查遵循 WHATWG UTF-8 解碼器與 RFC 3629，而非寬鬆的位元到碼單元簡化路徑。

前導的 UTF-8 位元組順序標記 EF BB BF 會被標準 TextDecoder 包裝器消耗，因為 ignoreBOM 保持為預設的 false 值。因此 EF BB BF 41 會返回 A。相同位元組在文字中間解碼為實際的 U+FEFF 字元，且不會被移除。單獨的 BOM 是有效的解碼，其可見輸出為空，且介面會說明此結果。位元組 00 也是有效的 UTF-8 資料，轉換為 U+0000；它不會被視為 C 語言字串終止符。僅當解碼文字無碼單元時，複製按鈕才會被關閉。

預算明確且獨立。原始輸入最多可包含 2,000,000 UTF-16 個碼單元。解析輸出最多可包含 1,000,000 個位元組，解碼文字最多可包含 1,000,000 UTF-16 個碼單元。每個精確的限制皆被接受，超出一個單位則被拒絕，並以「未解碼、未返回、未截斷」的說明呈現。解析器在分配輸出陣列前會計算位元組數。它從不切分過大的來源、忽略額外的完整位元、抽樣文字或靜默限制數值。帶字首的表示法每字元包含更多原始字元，因此可能在達到原始輸入預算前就達到位元組預算，此為預期且會被報告。

編輯十六進位輸入、更改任一語法選項或啟動新解碼，將立即清除先前的輸出、錯誤、複製狀態與複製計時器。剪貼簿寫入為非同步操作，因此每次嘗試都會獲得一個產生編號。遲到的權限成功或失敗無法在輸入或選項變更後更新介面，新的複製操作將啟動，或當元件解除安裝時亦不會更新。若剪貼簿存取失敗，有效的解碼文字仍可選擇，並顯示手動複製指示。剪貼簿權限取決於瀏覽器與安全上下文政策。

此工具僅解碼 UTF-8。它不會猜測 Windows-1252、ISO-8859-1、UTF-16、Shift_JIS 或其他傳統編碼，因為靜默猜測會改變位元組意義。它不會解析整數字詞、反轉位元順序、移除空值、處理轉義、解析帶位址的十六進位轉儲、解密資料，或執行解碼文字。對於格式化的記憶體轉儲，應先使用適當的可信工作流程僅提取其位元組欄位。對於二進位而非十六進位輸入，請使用「二進位轉文字」；對於 Base64 通訊資料，請使用 Base64 編碼與解碼。

WHATWG 編碼標準是瀏覽器 UTF-8 解碼器、致命錯誤模式、BOM 包裝器行為與 TextDecoder API 的主要來源。RFC 3629 獨立定義有效的 UTF-8 序列範圍與 Unicode 標量上限。MDN 會交叉驗證瀏覽器中公開的 TextDecoder 建構函式選項。十個可執行的外部標準案例涵蓋 ASCII、多字元字元、補充平面、BOM 位置與 NUL，同時對抗性測試涵蓋語法混合、奇數半字元、Unicode 空白、無效 UTF-8 邊界以及精確預算邊緣。

方法與來源

請先檢查 2,000,000-code-unit 原始預算再進行解析。當偵測到大小寫不敏感的 0x 情況時，啟用字首模式。純模式僅接受偶數長度的十六進位群組，並可選擇性啟用 ASCII HT、LF、FF、CR 或空白字元分隔。字首模式則要求每個標記必須為精確的 0xNN，且禁止混用。在建立 Uint8Array 之前，必須計算並驗證 1,000,000-byte 輸出預算。使用 new TextDecoder('utf-8', { fatal: true }) 來完整解碼陣列，使無效序列不會返回部分或替代文字，並保留預設的首段 BOM 行為。驗證 1,000,000-code-unit 文字預算。在任何編輯或選項變更時，皆需無效化結果、錯誤、複製作業與計時器。並透過產生與存活參考來保護剪貼簿 API 的完成。

常見問題

支援哪些十六進位格式？
純組合必須包含偶數個十六進位數字。當啟用時，ASCII 空白可分隔組合。若使用任何 0x 字首，則每個以空白分隔的標記必須恰好為 0xNN。
當位元組為無效的 UTF-8 時會發生什麼事？
整個解碼過程會失敗。致命 TextDecoder 模式會阻止取代字元的插入，並阻止將有效字首作為部分成功返回。
為何前導的 EF BB BF 消失了？
標準的 UTF-8 TextDecoder 包裝器預設會消耗前導的位元組順序標記。相同 U+FEFF 序列在文字中間會被保留。
我的十六進位或解碼文字會被上傳嗎？
沒有。十六進位解析、位元組分配、致命 UTF-8 解碼、顯示以及剪貼簿準備皆在當前標籤頁的本機/本機狀態中執行。

相關工具

編碼與加密 使用指南

查看全部