把文字轉成二進位代碼的意思，是把字串編碼成它所產生的 UTF-8 位元組的精確序列，然後把每個位元組列印成以零填補為八位元、彼此以一個空白分隔的位元，因此「Hi」會變成 01001000 01101001。「text to binary」這個說法本身其實是有歧義的：同樣的輸入可以對應到許多不同的 0 與 1 字串，端看在用的是哪一種字元編碼、分組規則與位元寬度慣例。一個可靠的轉換必須指明編碼（UTF-8）、把分組固定為每個位元組恰好八個位元，並在位元組之間使用一個普通空白。像「H」這種 ASCII 字母佔一個位元組，像「é」這種帶腔調字母佔兩個位元組，歐元符號「€」佔三個位元組，而像「😀」這種輔助字元則佔四個位元組，因此二進位輸出的長度取決於實際的位元組流，而不是打字的字元數量。這個區別正是一個可驗證的轉換和一個近似轉換之間的分界。
為什麼「文字轉二進位」在沒有規則時是有歧義的
一般搜尋「text to binary」會找到在基本觀念上彼此不一致的工具與教學。有些顯示七個位元而非八個，有些不管字元真正的寬度為何都把它填補到一整個位元組，還有些直接把碼點以變動長度的二進位傾印出來，卻沒有標明是哪一種編碼。每種做法各自內部一致，但它們列印出來的位元組是無法互換的。如果你從一個把每個字元視為一個 8 位元單位的工具複製輸出，再餵給一個期待真正 UTF-8 序列的解碼器，來回轉換就會失敗，或者文字會被悄悄損壞。
根本原因在於「binary（二進位）」描述的是一種數字進位，而不是一種格式。位元可以代表幾乎任何東西：一個碼點、一個字形輪廓、一個 UTF-16 程式碼單位、一個摩斯元素，或一段已編碼文字的位元組。沒有一份明文約定——編碼名稱、分組寬度、分隔符號與拒收規則——同樣一串 0 與 1 在某個工具裡可能解碼成「Hello」，在另一個工具裡卻解碼成亂碼。把這四個細節釘死，就能讓「binary」從一個標籤變成一份規格。
讓二進位輸出沒有歧義的那條規則
有一條規則可以消除歧義：列印 UTF-8 位元組，每次八個位元，以一個普通空白分隔。文字轉二進位轉換器正好遵循這條規則，使用 WHATWG TextEncoder 把輸入字串轉成 UTF-8 位元組流，再把每個位元組序列化成八個以零填補的 base-2 位數。瀏覽器的 TextEncoder 負責執行編碼步驟，這表示輸出會與任何符合標準的編碼器在伺服器上、其他工具中、或寫入磁碟的檔案裡所產生的結果一致。
格式與編碼本身同樣重要。每組恰好八個位元對齊電腦實際定址記憶體的方式。每組之間恰好一個空白則讓解析器能夠正確還原位元組邊界，不必猜測一個位元組在哪裡結束、下一個在哪裡開始。回頭解碼時也沿用同樣嚴格的格式，這正是真正的來回轉換能夠實現的原因。
| 選擇的範圍 | 規則 | 為什麼能消除歧義 |
|---|---|---|
| 編碼 | 僅限 UTF-8 | 符合主流的網路與檔案標準，且對任何 Unicode 純量值都不會遺失。 |
| 分組寬度 | 恰好 8 個位元 | 每一組就是一個位元組；不需要填補或截斷。 |
| 分隔符號 | 恰好一個 ASCII 空白 | 容易還原；不合格式（Tab、多個空白、逗號）會被標記出來。 |
| 驗證 | 解碼時進行嚴格的 UTF-8 檢查 | 格式錯誤的位元組會直接拋出錯誤，而不是被悄悄替換成 U+FFFD。 |
這四條規則加在一起，讓轉換器對每一位使用者的行為都一致，這才是此處「沒有歧義」的真正含義。
三個步驟把文字轉成二進位
這個轉換器強制執行上述規則，並在瀏覽器內跑完整個管線，因此工作流程刻意保持簡短——貼上、點選、驗證、複製。
- 打開工具並選擇方向。選擇「Text to UTF-8 binary」進行編碼，或選擇「UTF-8 binary to text」進行解碼。模式切換會同時控制輸入的預期與轉換後工具顯示的內容。
- 輸入你的內容。編碼時，輸入或貼上任何 Unicode 字串（英文、帶腔調的拉丁字母、CJK、表情符號或混合內容皆可）。解碼時，貼上每組恰好八個 0 與 1、以一個普通空白分隔的群組；不要加「0b」之類的前綴、不要逗號、不要 Tab，也不要開頭或結尾的空白。
- 點選 Convert。在文字轉二進位方向驗證位元組數量，或在另一個方向讀取解碼後的文字，然後只把結果複製到能完整保留空白與換行符號的系統中。
有一些上限值得一開始就注意：編碼最多接受 20,000 個 UTF-16 程式碼單位的輸入，解碼最多接受 180,000 個字元的序列化二進位，輸出緩衝區就只有你在畫面上看到的內容。如果你的輸入超過任一上限，請先修剪內容，不要期待只得到部分輸出。對於更長或更系統性的工作，把文字轉成二進位數字的逐步演練涵蓋了相同的編碼邏輯，並附上你可以親手演算的範例。
位元組寬度如何改變輸出
因為 UTF-8 是變動寬度編碼，同樣數量的輸入字元可能產生差異很大的二進位字串長度。下表整理了 Unicode 標準所定義、並由轉換器的測試案例所確認的官方寬度分類。
| 範例字元 | 範圍或區塊 | UTF-8 位元組 |
|---|---|---|
| A（大寫 A） | 基本拉丁文（ASCII） | 1 個位元組 — 01000001 |
| é（帶尖音符的 e） | Latin-1 補充 | 2 個位元組 — 11000011 10101001 |
| €（歐元符號） | 貨幣符號 | 3 個位元組 — 11100010 10000010 10101100 |
| 中（CJK 表意文字） | CJK 統一表意文字 | 3 個位元組 |
| 😀（露齒笑表情符號） | 輔助平面 | 4 個位元組 — 11110000 10011111 10011000 10000000 |
輸出長度就是這些寬度的總和，因此一串四個表情符號的內容可能佔大約十六個位元組，即便打字時只有四個字元。如果你看到每組八個位元而數量突然暴增，那就是編碼在回報一個更寬的字元，而不是出了 bug。
反向解碼並抓出錯誤
解碼使用相同的格式反過來執行，並套用嚴格的 UTF-8 驗證，這代表結構上分組正確的位元組序列，只要它沒構成一個合法的 UTF-8 字串，仍會解碼失敗。舉例來說，一個開頭位元組預期還會接兩個續接位元組，但後面卻跟著一個 ASCII 字母時，會產生錯誤，而不是被替換成 Unicode 替代字元（U+FFFD）。轉換器會回傳一則清楚的訊息，讓來源位元組字串能夠被定位並修正，這讓反向操作可以作為精確 UTF-8 位元組流的檢查手段。
八個獨立的黃金案例會橫跨整個寬度光譜演練這套來回轉換，涵蓋一個 ASCII 字元、一整個英文單字、一個兩位元組帶腔調字母、三位元組的歐元符號、一個四位元組輔助表情符號、一段 CJK 序列、一個換行控制位元組，以及一段混合寬度字串。每一個案例都各自獨立寫出預期的位元組，與實作無關，測試集涵蓋最大輸入預算、無效分組、重複空白、不完整的 UTF-8，以及位元組數量。
複製時最容易出錯的地方在於組與組之間的空白。聊天軟體和所見即所得編輯器可能會把連續空白壓縮掉，或插入換行。這會把一段合法的位元流變成嚴格正規表達式會拒絕的內容，導致轉換失敗，即便位元組本身其實是正確的。要避免這種情況，請從純文字來源貼到工具中，或把結果存放在能完整保留空白的檔案裡。
當你需要不同的工具
這個轉換器把一件事做好，並拒絕假冒其他格式。它不會解析機器指令、檔案、影像、Base64、十六進位、摩斯碼，或任何自訂的舊式字元集，也不會同時充當加密工具。二進位是一種可逆的表示法，與原始文字包含相同的資訊；任何拿到位元組的人都能解碼，因此它不提供機密性、完整性或認證。如果目的是雜湊、金鑰產生、加密或壓縮，請改用合適的工具。
有一些表面上像文字轉二進位的情境，實際上需要不同的工具：
- 十六進位輸出：當下游系統接受以兩位數十六進位而非八位元二進位群組表示位元組時，請使用文字轉 HEX 編碼器。
- Base64 傳輸：對於無法承載任意位元組的通道，請使用 Base64 Encode / Decode；它比以單一空白分隔的 8 位元二進位更為密集。
- 視覺呈現：如果目的是顯示而非資料交換，那麼一套字型或一份逐字元的碼點對照表，會比二進位更合適。
- 編碼整個檔案：若是整個檔案，請先取出原始的 UTF-8 位元組，再依通道需求執行對應的編碼步驟，不要把檔案貼進這個工具。
在協定、原始碼或鑑識工作中，請把這個轉換器當作驗證輔助，而非最終依據。在信任一個來回轉換之前，請把它產生的輸出與相關規格以及目的端系統上的實際位元組序列進行比對。
想進一步了解，請參閱 Text to Hex Bulk：安全地對大型 UTF-8 文字進行批次編碼。