將文字轉換成二進位檔案，意思是將代表每個字元的確切位元組（而非抽象的 Unicode 碼點）寫入一連串 8 位元的群組中。像 Text to Binary Converter 這類位元組精確的轉換器，會使用 WHATWG UTF-8 編碼器，根據 Unicode 範圍將每個字元序列化為 1 到 4 個位元組，然後將每個位元組列印為以單一空格分隔的八位元零填充位元。像是 A 這樣的 ASCII 字母會變成一個位元組，像是 é 這類帶有腔調的拉丁字母會佔用兩個位元組，歐元符號使用三個位元組，而像是 😀 這樣的輔助平面表情符號則會佔用四個位元組。因此輸出是明確且可複製的位元組串流，而不是 JavaScript 的 UTF-16 碼元、字形像素，或是每個純量值的二進位表示。無論最終目的地是儲存二進位數字的 .txt 文字檔、嵌入原始碼中的字串字面值，還是由另一支程式寫入的真正 .bin 檔，編碼後的位元組都完全相同。這款轉換器會將輸入與輸出保留在當前的瀏覽器分頁中，絕不上傳任何資料，並在反向路徑上以明確的致命錯誤拒絕無效的位元組群組。
「將文字轉換為二進位檔案」實際上的意義
「二進位檔案」這個詞組可能代表兩種截然不同的意義，而明確的答案取決於問題實際上是在詢問哪一種。在某種意義上，二進位檔案是指儲存在磁碟上的任何非純文字檔案——例如 .bin、.png、.zip 或編譯後的程式——其位元組並非供人類直接閱讀。在另一種意義上，當有人詢問如何將文字轉換為二進位檔案時，他們通常是指一份純文字文件，其中包含代表原始文字每個位元組的可列印字元 '0' 與 '1'，每個位元組一組。
真正的二進位檔案會在磁碟上儲存原始位元組。包含「二進位」內容的文字檔則將同樣的位元組以 ASCII 字元 '0' 與 '1' 的形式儲存，並以空格或換行分隔。兩者的資訊完全相同，但磁碟上的編碼方式不同。Text to Binary Converter 產生的是第二種：一串可複製、以空格分隔的 8 位元位元組群組，你可以將其貼入原始碼、記錄檔、設定值或聊天訊息中。如果你的最終目標是真正的 .bin 檔，這些以空格分隔的群組就會成為另一支程式解析並寫入磁碟的中繼形式。
這個區別很重要，因為這個術語本身具有歧義。位元組精確的工具應始終告知它所使用的字元編碼以及位元的分組方式。這款轉換器承諾採用 UTF-8 編碼，並使用恰好以一個普通空格分隔的八位元群組，讓格式完全可逆，無需猜測填補、修剪或對齊方式。
為何 UTF-8 位元組寬度從 1 到 4 不等
UTF-8 是一種可變寬度的標準。單一字元依其落在 Unicode 的哪個範圍，可能佔用 1、2、3 或 4 個位元組，如 WHATWG Encoding Standard 和 Unicode Conformance 規格所定義。下表概述了編碼器所使用的官方位元組寬度。
| Unicode 範圍 (十六進位) | 位元組寬度 | 範例字元 |
|---|---|---|
| 0000–007F | 1 位元組 | ASCII 字母、數字、基本標點符號、控制碼 |
| 0080–07FF | 2 位元組 | 帶腔調的拉丁字母、希臘文、西里爾文、阿拉伯文、常見符號 |
| 0800–FFFF | 3 位元組 | CJK 字元、歐元符號 €、大部分數學符號 |
| 10000–10FFFF | 4 位元組 | 輔助平面表情符號 😀、歷史文字、罕見符號 |
ASCII 的「A」是一個位元組：01000001。帶腔調的字母「é」佔用兩個位元組。舉一個算出的範例：é (Unicode U+00E9) 在 UTF-8 中編碼為兩個位元組 0xC3 0xA9，以 8 位元二進位表示即為 11000011 10101001。歐元符號「€」佔用三個位元組：11100010 10000010 10101100。表情符號「😀」佔用四個位元組：11110000 10011111 10011000 10000000。這就是為什麼任何聲稱「一字元一個位元組」的工具，對於幾乎所有現代文字而言都是錯誤的。
這款轉換器的輸出是編碼後的位元組串流，而非 Unicode 碼點的二進位表示。若將碼點直接視為位元組值，對於基本多語言平面中的每個字元都會產生四個位元組，這在 UTF-8 下並不正確，也無法完整還原回原始文字。根據 TextEncoder 的 MDN 文件，瀏覽器中基於標準的編碼器才是這些位元組序列的正確來源。
逐步將文字轉換為二進位位元組
從輸入的文字到一串可複製的 8 位元位元組群組，最快的路徑是在轉換器中進行六個動作。每個步驟都會保留嚴格的格式，以便位元組群組能夠被精確地還原。
- 在目前的瀏覽器分頁中開啟 Text to Binary Converter。
- 在方向選擇器中選擇「Text to UTF-8 binary」模式。
- 在輸入框中輸入或貼上你的 Unicode 文字——帶腔調的字母、CJK 字元和表情符號都可以接受作為輸入。
- 按下 Convert 按鈕，針對輸入執行基於標準的 TextEncoder。
- 確認顯示在輸出下方的位元組數量，這正是你輸入內容中 UTF-8 位元組的確切數量。
- 從輸出面板複製以空格分隔的 8 位元位元組群組，並貼入原始碼、記錄檔或獨立的檔案寫入程式中。
若要走反向路徑，請將方向選擇器切換為「UTF-8 binary to text」，貼上以一個普通空格分隔的精確 8 位元群組，然後選擇 Convert。解碼後的文字必須與編碼器的位元組數量相符；若不相符，解碼器會以明確的錯誤訊息拒絕輸入，而不會產生誤導性的結果。相同的轉換過程也可透過 Binary To Text 工具來執行，該工具為已經擁有位元組群組並需要解碼的讀者提供了相同的 UTF-8 契約。
將二進位解碼回文字的嚴格格式規則
解碼器接受嚴格的正規語言：恰好由八個字元組成的群組，每個字元只能是 0 或 1，並以恰好一個 ASCII 空格分隔。它會拒絕諸如「0b」這類前綴、逗號、Tab 鍵、多個連續空格、七位元群組、九位元群組、前後空白，以及 0 或 1 以外的任何字元。數值絕不會被填補、修剪、猜測或靜默丟棄。
這種嚴格性是刻意的。結構上分組良好的位元組序列仍然可能是無效的 UTF-8——例如缺少前導位元組的孤立續接位元組、過長編碼，或是 UTF-16 代理半字。採用致命錯誤設定的解碼器會以明確的錯誤呈現這些情況，而不是以 Unicode 替換字元替代，否則將讓錯誤輸入看起來像是有效的輸出。TextDecoder 的 MDN 參考文件記載了用來強制執行此行為的 fatal 選項。
對於通訊協定、原始碼或鑑識工作而言，這讓反向操作可以充當驗證步驟，而非靜默的近似處理。編碼器最多接受 20,000 個 UTF-16 碼元的輸入。解碼器最多接受 180,000 個輸入字元。超出這些上限的輸入會在轉換之前失敗。在複製編碼後的群組時，只有能夠精確保留普通空格與換行內容的系統才適合接收；聊天程式和所見即所得編輯器可能會折疊空格或插入換行符，這會導致嚴格解碼拒絕結果。
當你需要真正的二進位檔案而非二進位位元組時
如果你的目標是磁碟上真正的 .bin 檔，以空格分隔的 8 位元群組就是一種中繼形式。將其貼入一支小型的程式——例如 Python、Node.js 或 shell 腳本——該程式會使用 int(group, 2) 將每個八位元群組解析為一個位元組，並將這些位元組寫入磁碟。轉換器是該工作流程的編碼半部；檔案寫入程式則是另一半。
這款轉換器在設計上是有所取捨的。它不會解析數值型二進位值、機器指令、影像或壓縮檔、Base64、十六進位、摩斯密碼或自訂的舊式字元集。下表顯示了這款工具在同類工具中的定位。
| 目標 | 合適的工具 |
|---|---|
| 將文字編碼為 UTF-8 8 位元二進位位元組 | Text to Binary Converter |
| 將文字編碼為 UTF-8 十六進位位元組（連續、帶空格或 0x 前綴） | Text to HEX |
| 將文字編碼為支援完整 UTF-8 的標準 RFC 4648 Base64 | Base64 Encode / Decode |
| 將同樣的位元組群組解碼回 Unicode 文字 | Binary To Text |
| 將本機的 UTF-8、UTF-16 或 Windows-1252 檔案轉換為經驗證的 UTF-8 位元組 | UTF-8 Converter |
| 將文字翻譯為摩斯密碼並可選擇播放音訊 | Morse Code Translator |
二進位輸出並非加密。編碼後的位元組包含與原始文字相同的資訊，並不提供機密性、驗證、完整性、壓縮或密碼保護；任何持有位元組群組的人都能將其解碼。在通訊協定、原始碼或鑑識工作中，請依據相關規格和目的地系統來驗證實際的位元組序列，而不是依賴字型如何繪製二進位輸出，因為字型呈現可能會誤導讀者對字形位元組寬度的判讀。
若要深入了解，請參閱 Text to Hex Cheat Sheet: UTF-8 Values and Format Reference。
若要深入了解，請參閱 How to Change UTF-8 in Windows for Text Files。