跳至主要內容
Lizely

文字轉為十六進位

將文字編碼為精確的 UTF-8 十六進位字串，支援連續、間隔或 0x 預設輸出格式，並明確顯示 Unicode 替換警告。

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

使用方式

  1. 1.輸入文字，包含任何 Unicode、空白字元或 NUL 資料，只要瀏覽器欄位能容納。
  2. 2.選擇連續、空格分隔或以 0x 開頭的輸出，以及小寫或大寫的十六進位數字。
  3. 3.點選編碼、檢視位元組與替換數量，然後複製完整的十六進位輸出。

關於文字轉為十六進位

文字轉為十六進位會將瀏覽器文字轉為其 UTF-8 位元組的十六進位表示。輸入文字，選擇連續對應的字元（例如 4869）、空格分隔的位元組（例如 48 69）或以 0x 開頭的單字元（例如 0x48 0x69），並選擇小寫或大寫的十六進位數字。完整結果包含其 UTF-8 位元組數量與格式化輸出長度，可複製，且不會上傳任何內容至 Lizely。

轉碼使用瀏覽器 TextEncoder API，產生 UTF-8。ASCII 字元佔用一個位元組，許多拉丁文字佔用兩個，大多 BMP 字元佔用三個，補充的 Unicode 取樣佔用四個。每個位元組的十六進位永遠使用兩位數，因此 U+0041 會變成 41，U+00E9 會變成 c3a9，U+4F60 會變成 e4bda0，U+1F600 會變成 f09f9880。大寫模式僅改變 a 到 f 的字母；位元組值與 0x 字首保持不變。

這三種格式僅是呈現方式的選擇，實際的位元組內容完全相同。純文字格式每字元兩位數連線；空格分隔格式在每對位元組之間插入一個 ASCII 空格；字首格式則將每個位元組寫成 0xNN，並以一個 ASCII 空格分隔。第一個與最後一個 token 前後均不加分隔符。改變格式或字母大小寫不會改變實際的編碼 UTF-8 位元組，但會改變格式化輸出的長度。

TextEncoder並沒有預備 UTF-8 字型序號.普通輸入從第一字元的字型開始. 如果輸入本身包含 U+FEFF,那個實際字元會被編碼為 EF BB BF,因為它是資料,而不是因為編碼器新增了後設資料.。

JavaScript 字串是 UTF-16。一個有效的高-低代理對代表一個補充 Unicode 核子，TextEncoder 會正常編碼它。單獨的高或低代理並不是 Unicode 核子。標準化轉換會在 UTF-8 編碼前，將每個單獨代理碼元取代為 U+FFFD，產生 EF BF BD。結果面板會計算並視覺警告這些取代，因為解碼位元組無法重建原始單獨碼元。精確的字元至十六進位至字元迴圈需要良好的 Unicode，加上上述前導 U+FEFF 的注意事項。

其他資料不會被標準化或視為終止符。NUL U+0000 會轉為位元組 00。歸位字元、換行、製表符和空白字元會按輸入順序編碼。組合序列會保持分解狀態，除非輸入原本已組合；例如 e 加上 U+0301 會變成 65 CC 81，而不是轉為 U+00E9。該工具不會應用 Unicode 標準化、換行轉換、修剪、大小寫轉換、轉義解析或地區感知的重寫。

預算明確。輸入最多包含 1,000,000 UTF-16 碼元。格式化輸出最多包含 4,999,999 UTF-16 碼元。精確的輸出邊界被接受：一百萬 ASCII 輸入字元以 0x 預設格式產生正好 4,999,999 輸出碼元。輸入或輸出碼元超過對應驗證器將會被明確拒絕並顯示訊息。多位元 Unicode 在詳細格式中可能在輸入預算前達到輸出預算，工具會報告此失敗而非切換格式、切片位元、刪除字尾或取樣內容。

整個文字會先被編碼，再進行格式化，輸出長度會根據位元組數量與選擇的語法計算。在大格式化字串建立前會先檢查限制。格式化會以有界位元組區塊進行，並將每個區塊合併，此舉可減少暫時分配的波動，同時不改變或限制輸出。最終字串長度會與驗證預測值對比，作為防禦性不變數。

編輯文字、改變格式或大小寫，或開始新的編碼，都會清除先前的輸出、錯誤、位元組統計、替換警告、複製狀態與複製計時器。複製操作會使用產生、掛載狀態與計時器識別碼作為保護。較晚的許可請求失敗或成功無法恢復先前的狀態，即使在編輯、新的編碼、另一次複製嘗試或解除安裝後。若複製權限被拒絕，完整的只讀結果仍可手動選擇。

此工具僅處理 UTF-8 位元組；不會使用 UTF-16 碼元值、ASCII 位元組的備用方案、Windows-1252、地區碼頁或任意數值字元程式碼。十六進位僅為顯示編碼，並非加密、雜湊、壓縮或秘密保護。只要擁有這些位元組與 UTF-8 的規則，任何人都可以恢復正確的文字內容，但需符合選擇解碼器的前導 BOM 行為。

WHATWG 編碼標準定義了 UTF-8 編碼器與 TextEncoder 轉換為標量值字串的行為。MDN 也獨立說明瀏覽器 API 與 Uint8Array 輸出。十個可執行的外部金標準案例涵蓋 ASCII、兩、三、四位元組標量，U+10FFFF、NUL、明確的 U+FEFF、組合標記與行結束符。額外測試涵蓋所有格式與情境、孤立代理的替換計數、精確的輸入與輸出限制、無效選項，以及正確的 Unicode 往返轉換。

方法與來源

拒絕空值輸入，並在編碼前檢查是否超過 1,000,000 UTF-16 字元單位。針對孤立的補位字元單位，以帶對應關係的 UTF-16 掃描進行計數，然後使用 TextEncoder.encode 進行標準化標量值轉換與 UTF-8 位元組輸出。計算格式化長度為：純文字為 2n，帶空格為 3n−1，帶 0x 字首為 5n−1；若值超過 4,999,999 則拒絕輸出。以限制範圍內的區塊格式化每個位元組，使用小寫或大寫數字，並確認實際長度與預測值相符。記錄位元組數與孤立補位字元的替換數量。編輯選項會使結果無效且剪貼簿狀態失效；剪貼簿完成則使用產生、掛載狀態與計時器識別碼作為保護機制。TextEncoder 不會加入 BOM，但明確的 U+FEFF 會作為資料內容。

常見問題

TextEncoder 會加入 UTF-8 的 BOM 嗎？
不會。它不會加入 BOM。如果輸入實際以 U+FEFF 開始，這些字元的位元組會以資料形式編碼；搭配的解碼器會根據其文件政策消耗前導的 BOM。
孤立的 UTF-16 代理會怎麼處理？
標準的 TextEncoder 轉換會將每個孤立的 surrogate code unit 替換為 U+FFFD，其 UTF-8 位元組為 EF BF BD。結果會顯示一個可視的取代數量。
這三種輸出格式會改變位元組嗎？
不會。它們僅是呈現相同 UTF-8 位元組，以連續對、空格分隔對或 0xNN 空格分隔的 token 形式顯示。僅字母大小寫的改變會影響 A–F 的大寫小寫。
我的文字或十六進位會上傳嗎？
輸入內容不得超過 N。文字編碼、尺寸設定、格式化、顯示以及剪貼簿準備皆在當前瀏覽器標籤頁執行，全程本機處理。

相關工具

編碼與加密 使用指南

查看全部