Python 字串並沒有單一二進位表示法——每個字元會編碼為 1 到 4 個 UTF-8 位元組，因此 Python 的文字轉二進位程式必須決定要輸出 Unicode 碼點、UTF-16 程式碼單位，還是實際的 UTF-8 位元組，以及是否要對位元群組進行填補或截斷。Python 中大多數快速的寫法會使用 format(ord(c), 'b') 或 bin(ord(c))，它們會回傳 Unicode 純量值的位元樣式並去掉前置零，因此結果很少是每個字元八位元，也很少能夠完整還原回原始字串。更忠實的做法是先以 UTF-8 編碼字串，再將每個位元組格式化為八位元且前置補零；這與網路通訊端、檔案控制代碼或 HTTP 主體實際承載的位元組流相同，也是大多數文字轉二進位工具實際列印的形式。了解自己需要哪一種，才能在把輸出複製到其他程式時避免靜默的損毀。

how to convert text to binary in python
Python 文字轉二進位：實務上的位元組精確 UTF-8

為何 Python 內建工具會給你寬度不一的輸出

Python 讓你可以輕鬆寫出一行看似二進位輸出的程式，但最常見的模式會回傳不一致的寬度，與其他系統預期的位元組流並不相符。

最快的寫法 " ".join(format(ord(c), "b") for c in s) 完全去掉了前置零。"Hi" 這個字串會變成 1001000 1101001，也就是兩組各七位元，而不是八位元。下游解碼器無法判斷 1001000 代表的是七位元值 72，還是八位元值 01001000，因此結果若無額外中繼資料就無法往返還原。

改用 format(ord(c), "08b") 會將每組填補到八位元，這雖然解決了寬度問題，卻引入了另一個問題。Python 字串是 Unicode 碼點的序列，而非 UTF-8 位元組，因此字串 "é" (U+00E9) 會被視為單一的 16 位元值，並列印為 11101001——這是一個八位元的群組，其位元來自 Unicode 純量值 233，而非實際的 UTF-8 編碼 11000011 10101001。這同樣適用於基本多語言平面以外的所有字元：例如表情符號 "" 會因其純量值 128512 而被列印為一組 17 位元字串，而不是四個 UTF-8 位元組。

與檔案、通訊端或 HTTP 主體實際承載內容相符的模式，是先編碼字串，再格式化每個位元組：

" ".join(f"{b:08b}" for b in s.encode("utf-8"))

這個版本簡短、忠實，也正是 文字轉二進位轉換器 使用瀏覽器標準化 TextEncoder 所實作的內容。若想並排比較這些寫法以及它們所輸出的位元組，請參閱位元組精確指南 將文字轉換為二進位碼：位元組精確 UTF-8。

常見字元的位元組精確 UTF-8 樣貌

四種 UTF-8 寬度對應到前導位元組的高位元，無論編碼是在 Python、JavaScript 還是瀏覽器型工具中執行，適用的位元組計數都相同。

字元UTF-8 位元組數位元組樣式
ASCII 字母 (A)101000001
帶腔調的拉丁字母 (é)211000011 10101001
貨幣符號 (€)311100010 10000010 10101100
輔助平面表情符號 ()411110000 10011111 10011000 10000000

你可以在 Python 中確認每一列：len("A".encode("utf-8")) 會回傳 1，len("é".encode("utf-8")) 會回傳 2，len("€".encode("utf-8")) 會回傳 3，len("😀".encode("utf-8")) 會回傳 4。如果某個二進位轉換器所回報的位元組數與這些數字不一致，代表它編碼的是碼點而非位元組，其結果將與任何現代通訊協定所傳輸的位元組流不相符。

使用文字轉二進位轉換器將文字轉為二進位

為了快速驗證、撰寫文件或進行目視檢查，在瀏覽器中執行轉換可以避免在 REPL 中反覆調整格式字串的試錯循環：

  1. 開啟文字轉二進位轉換器，並選擇「文字轉 UTF-8 二進位」模式。
  2. 貼上或輸入你想要編碼的文字，總計最多 20,000 個 UTF-16 程式碼單位。
  3. 選擇「轉換」，並讀取輸出下方位元組計數，確認是否與你預期的大小一致。
  4. 在 Python 中以 len(text.encode("utf-8")) 交叉核對位元組計數；若數字相同，即代表該工具輸出的是位元組而非碼點。
  5. 將以空格分隔的二進位複製到能保留一般空格與換行內容的目的地——純文字檔、原始碼、終端機緩衝區或 Markdown 區塊皆符合資格。

當你需要一份清晰的視覺紀錄，記錄 Python 字串在線路上傳輸時的樣貌，或想在不撰寫測試程式碼的情況下驗證手動格式化的位元字串時，這個工作流程最為有用。

以嚴格驗證將二進位解碼回文字

反向操作與正向操作同樣容易出錯，而一個寬鬆的解碼器隱藏的 bug 多過它抓到的 bug。文字轉二進位轉換器只接受恰好由一個一般 ASCII 空格分隔、各八個二進位數字所組成的群組，因此諸如 0b 前綴、逗號、Tab、多個空格、七位元或九位元群組，以及任何前置或尾端空白，都會導致解碼失敗。這種嚴格性正是重點所在：當下游工具消費的是一段精確的 UTF-8 位元組字串時，一個會靜默修剪或填補群組的剖析器會把不一致的問題隱藏起來。

若要往返還原一個值：

  1. 將工具切換到「UTF-8 二進位轉文字」模式。
  2. 貼上位元組群組，確認群組之間恰好只有一個空格，且行首行尾沒有任何空白。
  3. 選擇「轉換」。若位元組序列在結構上分組良好卻是無效的 UTF-8——例如孤立的前導位元組缺少其接續位元組、過長編碼，或代理值——該工具會回傳清楚的錯誤，而不是 Unicode 替換字元。
  4. 在 Python 中使用 original == decoded_text 比較解碼後的字串與原始字串，以確認往返乾淨無誤。

底層的 Web API 在 MDN 上對雙向都有文件說明；TextEncoder 與 TextDecoder fatal 選項 說明了嚴格的解碼器如何在不使用替代字元的情況下拒絕格式錯誤的序列。

複製輸出時的限制、錯誤與陷阱

有兩項硬性上限規範了工具所能接受的內容。編碼上限為 20,000 個 UTF-16 程式碼單位，因此一個輔助平面表情符號在該處算兩個程式碼單位，但在輸出中卻是四個 UTF-8 位元組。解碼上限為 180,000 個輸入字元，在每組皆使用標準八位元數字加空格的模式時，約略等於 20,000 個位元組。

有幾個陷阱特別容易困住 Python 開發者：

  • 聊天客戶端與所見即所得編輯器會折疊空格。Slack、Teams、Word 與 Google Docs 可能會將位元組群組之間的單一空格轉為無空格、多個空格或換行，進而導致嚴格解碼失敗。請改將二進位儲存於純文字檔、原始碼或終端機緩衝區中。
  • 尾端的換行字元會改變位元組計數。貼上的段落若以 \n 結尾，會多編碼一個位元組 (00001010)。若不想讓它出現在二進位結果中，請在 Python 中使用 s.rstrip("\n") 去除空白。
  • 二進位並非加密。輸出所包含的資訊與輸入相同，只是格式較為繁瑣。任何擁有相同工具或任何 UTF-8 解碼器的人都能讀取。若需保密，請使用 AES 或基於密碼的機制，而非二進位表示法。
  • 控制位元組是真實的位元組。位元組 00001010 是換行字元，會被忠實編碼；位元組 00000000 是 NUL；位元組 00010001 是裝置控制 1。若下游剖析器拒絕控制位元組，請在 Python 中於編碼前先行過濾，而不是責怪轉換器。

當兩個二進位字串可能不同時，請使用該工具將兩者解碼，並比較所得到的 Unicode 文字；相同的位元組會產生相同的字元，而 fatal 解碼器會以具體錯誤而非靜默的替代字元來呈現任何差異。

相關閱讀：文字轉十六進位：命令列與線上工具比較。