將文字轉換為二進位數字的意思，是將 Unicode 字串中的每個字元轉成一串位元組，然後將每個位元組寫成由空格分隔的八個二進位數字。在網路上使用的標準文字編碼 UTF-8 中，ASCII 字母會變成一個位元組，帶有變音符號的拉丁字母變成兩個位元組，歐元符號以及大多數 CJK 字元變成三個位元組，而輔助平面的字元（例如表情符號）則變成四個位元組。文字轉二進位轉換器使用 WHATWG 的 TextEncoder，在您的瀏覽器中本機執行該對應，並將每個位元組列印為八位元、以零填補的位元，絕不會合併、修剪或猜測任何值。如果您貼上 "Hi"，工具會輸出 01001000 01101001 — 兩個位元組，共十六個位元 — 因為字母 H 是 ASCII 72（二進位 01001000），而字母 i 是 ASCII 105（二進位 01101001）。同一套邏輯也適用於更長的字串：位元組數會隨著編碼後的字元增加，而不是隨著可見字母的數量增加，這就是在您信任任何二進位輸出之前，必須先了解 UTF-8 寬度的原因。
"文字轉二進位數字" 真正的含義
這個說法聽起來很簡單，但實際上隱含了兩個獨立的步驟。首先，每個字元會透過字元編碼對應到一個數字代碼；在現代系統中，這個編碼幾乎都是 UTF-8，也就是 HTML、JSON、原始檔以及網路通訊協定所使用的同一種位元組格式。其次，每個位元組（介於 0 到 255 之間的數字）會以二進位寫成八個由 0 與 1 組成的數字，左側以零填補，使每組長度一致。因此您看到的輸出，並非每個字元對應一個整數，而是一串位元組值的串流，每個字元所佔的位元組數會有所不同。
一個常見的誤解是：一個字元等於八個位元。這個規則僅適用於 ASCII 範圍（碼位 0 到 127）。在 ASCII 範圍之外，UTF-8 會使用續接位元組來表示更大的碼位，因此單一字元可能佔用兩個、三個或四個位元組。文字轉二進位轉換器所列印的是編碼後的位元組，而非 JavaScript 的 UTF-16 碼元、字形像素、未分組的抽象位元，或是每個 Unicode 純量值的二進位呈現。當您比較兩個工具的輸出時，這個區別就很重要：若某個工具聲稱將「字元」轉換為二進位，卻為表情符號產生了單一八位元的群組，那它執行的就不是位元組精確的 UTF-8。
UTF-8 位元組寬度一覽
下表列出四種 UTF-8 位元組寬度以及每種的代表字元。這些寬度是由 UTF-8 標準本身所定義，而非由任何特定工具所決定。
| 字元類型 | UTF-8 位元組 | 範例 | 位元組序列（十六進位） |
|---|---|---|---|
| ASCII 字母或數字 | 1 | A (U+0041) | 41 |
| 帶有變音符號的拉丁字母 | 2 | é (U+00E9) | C3 A9 |
| 貨幣符號、CJK、BMP 符號 | 3 | € (U+20AC) | E2 82 AC |
| 輔助平面的表情符號或符號 | 4 | 😀 (U+1F600) | F0 9F 98 80 |
讓我們用最簡單的情況做個驗算：字母 A 的 ASCII 十進位代碼為 65。將 65 轉換為二進位並以零填補至八位數，會得到 01000001 — 這與數值為 0x41 的 ASCII 位元組以二進位表示時的結果相同。正是這個單位元組規則，讓早期的教學能夠順利運作，但一旦離開 ASCII 範圍，這個規則就不再成立了。
三個步驟將文字轉換為二進位數字
從字串到乾淨的位元組串流，最快的做法是使用線上工具，而不是自己寫腳本。以下步驟與轉換器經過驗證的操作程序相符。
- 選擇模式。當您要編碼字元時，請選擇文字轉 UTF-8 二進位；當您要將現有的二進位字串解碼回字元時，請選擇UTF-8 二進位轉文字。
- 輸入內容。在編碼模式下，輸入或貼上任何 Unicode 文字。在解碼模式下，請貼上以單個一般空格分隔的精確 8 位元位元組群組；不可包含逗號、Tab 鍵、前綴或多餘的空白字元。
- 選擇轉換並進行驗證。查看輸出旁顯示的位元組計數或解碼後的文字，確認它符合您的預期，然後再將結果複製到需要它的系統中。
所有處理都在目前的瀏覽器分頁中完成。您的輸入和輸出並不會上傳到任何伺服器；當文字較為敏感時這點很方便，但即使您只是想在開發過程中快速來回轉換，這項特性也很有價值。
讀取輸出並計算位元組數
編碼後的輸出是一行以空格分隔的位元組群組，每個群組對應一個位元組。計算群組的數量即可得到該字串的編碼後位元組數；這個數字是您在配置緩衝區、比較檔案大小，或是對應通訊協定規格時所需要的數字。包含 n 個 ASCII 字元的字串會恰好產生 n 個群組；若字串中包含一個表情符號，則會產生 n 加 4 個群組，因為該表情符號佔用了 4 個位元組 — 一個前導位元組加上三個續接位元組。
轉換器會將每個群組一律填補至八位數。這種填補並非裝飾性質 — 它正是讓解碼器能夠毫無歧義地將每個群組視為位元組的關鍵。如果您曾看過某個工具產生 7 位元群組、9 位元群組，或是長度不一的未填補群組，請將該輸出視為不同的格式，切勿將其餵入嚴格的 8 位元解碼器。若想深入了解反方向的概念，以淺顯易懂的方式說明二進位轉文字的運作原理這篇指南從另一個角度探討了相同的位元組串流邏輯。
為何嚴格的八位元分組如此重要
二進位文字若未同時標明編碼方式與分組規則，就會產生歧義。一組八個位元可以代表一個位元組（0–255），但七個位元一組則是 ASCII 的傳統；此外，JavaScript 字串內部其實是 UTF-16 碼元（0–65535），而非位元組。文字轉二進位轉換器選擇使用位元組，並拒絕在靜默中重新解讀您的輸入：它會拒絕 0b 之類的前綴、逗號、Tab 鍵、多重空格、七位元或九位元群組、前後端空白字元，以及任何 0 與 1 之外的字元。它絕不會對數值進行填補、修剪、猜測或刪除。
解碼端同樣十分嚴格。它採用強制性的 UTF-8 驗證，意即一個結構上分組正確的位元組序列，仍然可能屬於無效文字 — 例如，一個前導位元組缺少其對應的續接位元組。在這種情況下，工具並不會替換成 Unicode 替換字元（U+FFFD）後繼續執行，而是會回報一個明確的錯誤。這種行為能夠在通訊協定、原始碼鑑識等需要來回轉換完整性的工作流程中發揮保護作用，因為靜默的替換動作會破壞位元組串流的語義。
限制、錯誤以及本工具不會執行的事
此轉換器在編碼端最多接受 20,000 個 UTF-16 碼元；在解碼端則最多接受 180,000 個輸入字元。超過這些上限的輸入會在執行任何轉換之前就被拒絕。無效的分組、重複的空格、不完整的 UTF-8 序列，以及超出範圍或代理項的值，也會以明確的錯誤訊息失敗，而不是被替換成其他字形。
值得釐清的是本工具「不是」什麼。它並非加密工具：其二進位輸出所包含的資訊與原始文字相同，並不提供機密性、驗證、完整性、壓縮或密碼保護功能。它也不會剖析數值型二進位、機器指令、檔案、影像、Base64、十六進位、摩斯密碼或自訂的舊式字元集；若您的真正目的是這些，請使用針對該格式的鄰近工具。最後，請僅在能夠精確保留一般空格與行內容的系統中複製或儲存結果；聊天用戶端與富文字編輯器可能會合併空格或插入換行符號，即使位元組本身正確無誤，也會導致嚴格的解碼失敗。
如果您正在權衡各種選擇，文字轉十六進位詳解：UTF-8 位元組如何變成十六進位配對對此有詳細說明。