將純文字轉換為二進位表示，將 Unicode 字串通過 UTF-8 編碼器處理，然後將每一個產生的位元組以恰好八位零填補的位元形式印出，並以一個普通空格分隔。由於現代文字採用 Unicode，編碼器可能會根據輸入中出現的代碼點，每個可見字元產生一個、兩個、三個或四個位元組。因此，可見輸出是一序列的位元組群組，而不是一對一的「字元代碼」序列；每當有人試圖將結果解碼回原始字串時，這個區別就很重要。編碼本身由瀏覽器基於標準的 WHATWG TextEncoder 處理，因此當每個現代應用程式將相同字串寫入磁碟或透過網路傳送時，所產生的位元組是相符的。一個可靠的轉換工具會明確且可驗證地呈現這種位元組表示，而不是讓讀者去猜測「A」是否為一個位元組、「é」是一個還是兩個位元組，或者「😀」是否根本不應該出現。這種可驗證的、逐位元組的檢視，正是 文字轉二進位轉換器 所產出的結果，無需上傳步驟，也無需猜測實際使用的是哪一種編碼。
編碼內部：位元組群組的意義
現代意義上的純文字就是 Unicode 字串。當工具將該字串轉換為二進位時，必須預先做出兩個決定：使用哪一種編碼，以及如何將產生的位元分組。這兩個決定都會逐位元組地影響輸出。
UTF-8 是開放網路及瀏覽器內部的首選編碼，這就是為何遵循 WHATWG 標準的編碼器所產生的位元組序列，會與作業系統、資料庫和通訊協定實際發出的位元組一致。此處使用的分組規則為「每個位元組恰好八個位元，以一個普通空格分隔」，這個格式嚴格到可以無歧義地解碼，又寬鬆到可以當作普通文字閱讀。MDN 關於 TextEncoder 的參考文件記錄了轉換器所依賴的確切行為。
一個遵守這些決定的工具，會將大寫字母「A」(U+0041) 編碼為單一位元組 01000001。它會將「é」(U+00E9) 編碼為兩個位元組 11000011 10101001。它會將「€」(U+20AC) 編碼為 11100010 10000010 10101100。它也會將笑臉表情符號 😀 (U+1F600) 編碼為 11110000 10011111 10011000 10000000——四個位元組，沒有一個是 ASCII 可列印字元。文字轉二進位轉換器在本地端執行這項工作，因此輸入與輸出都保留在當前的分頁中，不會傳輸到任何地方。
在瀏覽器中將純文字轉換為二進位
基於瀏覽器的工作流程讓您無需安裝函式庫、執行腳本，或將字串複製到遠端服務。使用文字轉二進位轉換器，請依照下列步驟操作：
- 開啟文字轉二進位轉換器，並從模式選擇器中選擇文字轉 UTF-8 二進位。如果您想將二進位轉回文字，請改選UTF-8 二進位轉文字。
- 在輸入區域中輸入或貼上您的純文字。對於編碼器而言，普通文字——包括帶有變音符號的字母、貨幣符號、CJK 字元和表情符號——都可以接受，只要輸入不超過 20,000 個 UTF-16 代碼單位預算。對於解碼器，序列化輸入的上限為 180,000 個字元，由嚴格的八位元群組以一個普通空格分隔所組成。
- 點擊轉換。工具會執行編碼器，每個位元組印出一個八位元群組並以單一空格分隔，並回報總位元組數，讓您能根據輸入驗證結果是否合理。
- 檢視輸出。如果某一行的寬度超出預期，或某個字元似乎遺失，最常見的原因是有格式的文字在貼上時已經合併了空格；請改以純文字形式重新貼上。
- 將二進位字串複製到能夠完整保留普通空格和換行符的目的地。純文字編輯器、程式碼區塊和終端機緩衝區都是安全的；聊天用戶端和有格式的文字編輯器通常則不安全。
至於反向操作，請貼上恰好由八個 0 和 1 組成、以一個普通空格分隔的群組——除此之外不要包含任何內容，因為解碼器會拒絕逗號、「0b」前綴、分頁符號、多重空格、前後空白字元，以及 0 或 1 以外的任何字元——然後點擊轉換。解碼器使用嚴格的 UTF-8 驗證，因此即使一個結構上良好分組的序列若包含無效位元組，也會明確地回傳錯誤，而不會靜默地替換為 Unicode 替換字元。
位元組寬度依字元而異
一個常見的混淆來源，是假設一個字元對應一個位元組。在 UTF-8 下，位元組數取決於字元的 Unicode 代碼點範圍，而轉換器會在輸出中直接反映這一點。下表總結了四種可能的寬度，並為每種寬度提供一個代表範例。
| 字元類型 | 位元組數 | 範例 | UTF-8 位元組序列 |
|---|---|---|---|
| 標準 ASCII 字母與數字 | 1 個位元組 | A | 01000001 |
| 帶變音符號的拉丁字母 (U+0080 至 U+07FF) | 2 個位元組 | é | 11000011 10101001 |
| 常用符號及大多數 CJK 字元 (U+0800 至 U+FFFF) | 3 個位元組 | € | 11100010 10000010 10101100 |
| 輔助平面的表情符號及罕見文字 (U+10000 以上) | 4 個位元組 | 😀 | 11110000 10011111 10011000 10000000 |
這就是為什麼一個包含一個表情符號和一個帶變音符號字母的 10 個字元字串，會產生 14 個位元組群組而不是 10 個。任何需要知道「這個字串有多少位元組？」的人，都可以直接在轉換器的輸出中計算群組數，而不是根據可見字元數進行估計。每種寬度的參考模式已彙整於二進位轉文字速查表中，該表將常見的位元模式與其 ASCII 對應字元配對列出。
為何解碼有時會失敗
嚴格的八位元分組規則並非風格上的選擇。解碼器以位元組為單位進行操作，因此每個群組必須恰好包含八個二進位數字。任何其他情況——七位元群組、九位元群組、前導空白字元、「0b」前綴、逗號、分頁符號，或群組之間的多重空格——都會被直接拒絕。正是這種嚴格性讓來回轉換具有可預測性。
有兩個實際的陷阱值得注意。首先，有格式的文字貼上會破壞間距。聊天用戶端、文字處理器及許多網頁表單會合併連續空格或插入軟換行符，而對已被此類貼上行為破壞的字串進行解碼時，會因分組錯誤而失敗。解決方法是從保留空白字元的來源複製，或使用純文字中介工具。其次，分組正確的位元組仍可能是無效的文字。UTF-8 擁有超出位元組寬度之外的結構性規則：沒有正確連續位元組的前導位元組、過長的序列、未配對的代理半形，或超出有效範圍的代碼點，都會導致解碼器失敗。文字轉二進位轉換器使用 WHATWG TextDecoder 的嚴格模式（MDN 上有文件說明），因此格式錯誤的輸入會產生明確的錯誤，而不是靜默的替換字元。這在通訊協定、原始程式碼和鑑識工作中很重要，在這些場景下，虛假的來回轉換比誠實的失敗更糟糕。
純文字轉二進位不是什麼
此轉換的輸出與原始字串包含完全相同的資訊——沒有壓縮、沒有保密、沒有完整性檢查、沒有密碼保護。任何擁有該位元組序列和 UTF-8 解碼器的人都可以還原出原始文字，這就是為什麼二進位有時會被誤認為加密，儘管它並不具備加密所隱含的任何機密性特性。
同樣值得了解的是，該工具刻意不做的事，因為某些相鄰的任務看起來相似，但需要不同的機制。它不會呈現數值型二進位數值、機器指令或原始檔案內容。它不會解析十六進位、Base64、摩斯密碼或任何自訂的舊式字元集。它不會將輔助字元拆分為 JavaScript UTF-16 代碼單位，也不會將每個 Unicode 純量值詮釋為永遠只有一個位元組。
對於這些任務，相鄰的編碼工具才是正確的去處：用於傳輸安全 ASCII 表示的 Base64 編碼／解碼工具、用於十六進位位元組字串的十六進位轉文字轉換器，以及用於音訊或訊號用途的摩斯密碼翻譯器。文字轉二進位轉換器則專注於產生和消耗明確的八位元 UTF-8 位元組群組，讓原始字串中的每個位元組都是可見的、被命名的，並可根據 TextDecoder 規範進行驗證，而不是依據字型恰好如何繪製輸出。
如需深入了解，請參閱在 IntelliJ IDEA 中更改 UTF-8 並驗證原始檔案。