Binary to text Cryptii 是經典 Cryptii 管道的簡稱，它會把一段字串轉成以空格分隔的 8 位元二進位，或把同樣嚴格的格式解碼回 Unicode 文字，且不會把輸入送到伺服器。一個值得收藏的現代替代工具是 Text to Binary Converter，它使用瀏覽器中基於標準的 TextEncoder，將任何 Unicode 字串編碼，並把每個 UTF-8 位元組精準地以八位補零的位元顯示，位元之間以一個普通空格分隔。解碼只接受正規語言 [01]{8}( [01]{8})*，並使用嚴格的 UTF-8 TextDecoder，因此結構上分組正確但無效的位元組序列會以明確的錯誤訊息失敗，而不是被悄悄替換成 Unicode 替換字元。由於整個操作完全在本地端進行，您可以掌握確切的位元組內容，並在結果對網路堆疊、檔案格式或下游解碼器真正重要時，依據 WHATWG Encoding Standard 或 Unicode 核心規格驗證來回轉換是否正確。

binary to text cryptii
Binary to Text Cryptii: A Local UTF-8 Byte Converter

為什麼人們搜尋 "Binary to Text Cryptii"

Cryptii 讓「視覺化小型積木管道」——一個編碼器餵資料給檢視器——的概念廣為人知，可用於 Base64、Caesar、Vigenère、十六進位，以及二進位 ⇄ 文字。搜尋「binary to text Cryptii」的人通常想要的是同樣的體驗：貼上一段字串，得到帶空格的 0 與 1；貼上 0 與 1，得到可閱讀的文字。Text to Binary Converter 正好提供這個流程，而且有兩項原本那塊積木並未承諾的升級。第一，它為解碼鎖定了嚴格的輸入語法——每組恰好八個二進位數字，以單個普通空格分隔，別無其他。第二，它把輸出視為 UTF-8 位元組，而非含糊的「每個字元的二進位」，這在文字包含 ASCII 字母與數字以外的內容時立刻產生影響。

這第二點正是大多數隨意編輯器會出錯的地方。一個天真的編輯器會樂於把字母「A」呈現為 01000001，並把歐元符號「€」呈現為一長串從某個 UTF-16 程式碼單位一次取兩個位元出來的位元，即使「€」真正的 UTF-8 編碼恰好是三個位元組。輸出看起來像二進位，在產生它的工具中可以解碼回字串，但一旦離開該工具，只要內容超出基本多語言平面，就會悄悄損壞。這裡這個 Cryptii 風格的工具透過一律走 UTF-8 位元組來避開這個陷阱，所以您複製走的輸出，與網路堆疊、檔案或其他解碼器在線上看到的位元組序列完全相同。

在瀏覽器中將文字轉換為 UTF-8 二進位

編碼方向是整個工作流程中最簡單的部分，如果您要用已知字串測試這個工具，這也是一個很好的起點。

  1. 在瀏覽器分頁中開啟 Text to Binary Converter。
  2. 選擇「Text to UTF-8 binary」作為作用中的方向。
  3. 輸入或貼上您想要編碼的 Unicode 字串。
  4. 選擇 Convert。
  5. 讀取輸出下方的位元組數，並確認它符合您對該文字預期的寬度——舉例來說，兩個 ASCII 字母應產生兩組八位元，而「é」則應為其第二個位元組多增加一組。
  6. 將結果複製到能精確保留普通空格的目的地：純文字編輯器、程式碼檔案或終端機緩衝區。

這個實作將輸入上限設為 20,000 個 UTF-16 程式碼單位，透過 WHATWG UTF-8 TextEncoder 進行編碼，並以一個 ASCII 空格連接每個位元組。WHATWG Encoding Standard 定義了不同寬度的字元所產生的精確位元組模式，而 MDN TextEncoder 參考文件 記錄了提供這些位元組的瀏覽器 API。

將嚴格的 8 位元二進位解碼回文字

解碼方向是 Cryptii 風格積木通常開始出現粗糙邊緣的地方，因為同一個概念在紙面上有許多寫法。這個工具刻意保持嚴格的語法。

  1. 開啟 Text to Binary Converter，並將方向切換到「UTF-8 binary to text」。
  2. 以恰好八個二進位數字為一組、以單個普通空格分隔的方式貼上位元組。
  3. 選擇 Convert。
  4. 讀取結果字串以及其下方的位元組計數。
  5. 如果解碼失敗，請修正分組：移除 0b 這類前置字串，把逗號或 Tab 換成單個普通空格，把多個連續空格壓縮為一個，並去除頭尾的空白字元。

解碼器將序列化輸入限制為 180,000 個程式碼單位，將每組解析為恰好一個位元組，並執行嚴格的 UTF-8 TextDecoder，使格式錯誤的序列以明確方式失敗。看起來分組正確的位元組序列仍可能不是有效的文字——例如缺少後續位元組的孤立前導位元組、過長的編碼形式、代理的一半——而這個工具會將其以錯誤形式呈現，而不是悄悄塞入一個替換字元。如需更深入地逐步說明這種嚴格格式以及如何從常見的分組錯誤中恢復，binary-to-text decode guide 以逐步形式涵蓋了相同的規則集。MDN TextDecoder fatal 選項參考文件 則說明了背後的瀏覽器行為。

為什麼 UTF-8 位元組不一定是一個字元寬

閱讀 0/1 輸出時最常見的誤解，就是假設一個可列印字元等於一個位元組。在 ASCII 中這個假設成立：「A」確實是一個位元組，也就是 01000001。一旦文字包含任何帶腔調字元、貨幣符號或拉丁字母以外的內容，這個假設就瓦解了。UTF-8 是可變寬度編碼，而這個工具會精準地印出規格定義的位元組，而不是以每字元 16 位元的方式傾印。下表列出標準的寬度；任何其他字元您看到的位元組，都遵循相同的規則。

CharacterKindBytes in UTF-8
AASCII letter1
éTwo-byte Latin2
€Three-byte currency sign3
😀Four-byte supplementary emoji4

從這個表可以得出兩個實際的結論。第一，當您計算輸出中的分組數時，那個數字是位元組數，而不是您輸入的字元數。第二，如果下游系統告訴您的字元數與位元組數不一致，那就是 UTF-8 來回轉換的信號，而不是 bug——why-one-character-isn't-always-8-bits guide 透過幾個真實的字串，把這個模式講得清清楚楚。

限制與界線——這個工具不會做的事

這是一個編碼工具，不是加密，也不是通用的二進位轉換器。輸出所包含的資訊與輸入完全相同，只是以不同的進位方式呈現。任何擁有相容解碼器的人都可以把它讀回去。沒有密碼、沒有金鑰、沒有完整性標籤、沒有壓縮——若需要這些功能，請改用其他工具，例如 AES Encryption Online 進行已驗證的加密，或使用 Gzip Compress & Decompress 進行壓縮。

這個轉換器也不會假裝去執行屬於其他工具的工作。它不會把數字二進位解析為機器指令。它不解碼Base64、十六進位、莫斯電碼、ROT13、Caesar 移位、Vigenère 或任何自訂的舊式字元集。它不開啟檔案或圖片，也不會把某個 Unicode 碼點的二進位呈現為彷彿每個字元都是一個位元組或一個 16 位元單位。當真正的需求是上述其中之一，請改用專屬的工具：Base64 Encode / Decode、Hex to Text Converter、Morse Code Translator、ROT13 Encoder Decoder、Caesar Cipher Decoder，或 Vigenere Cipher Decoder。一開始就選對工具，能避免在例如把十六進位字串貼到二進位解碼器看看會發生什麼這類情境中，出現悄悄損壞的失敗模式。

在不破壞空格的情況下傳輸輸出

由於編碼是位元組精確的，解碼語法又是嚴格的，任何在貼上目的地的過程中改變普通空格的因素，都會破壞來回轉換。八個獨立的黃金案例涵蓋了 ASCII、一個英文單字、兩個位元組的拉丁文字、一個三位元組的貨幣符號、一個四位元組的表情符號、CJK 文字、一個換行控制位元組，以及一個混合寬度的字串，預期的位元組會獨立於實作而被記錄下來——但這些測試只有在空格完整無缺地抵達時才會成立。

純文字編輯器、終端機緩衝區、原始碼檔案以及協定層級的紀錄檔，都能可靠地保留普通空格。聊天程式和所見即所得編輯器則常常無法做到：它們可能會把多個空格壓縮、插入零寬度字元，或在不方便的位置把過長的行換行。當目的地屬於這類情況，請將結果以附件形式傳送，而不是直接內嵌貼上。在涉及協定、原始碼或鑑識工作的情境中，請勿相信 0 與 1 的視覺呈現；請依據 WHATWG Encoding Standard 和目的系統本身驗證實際的位元組序列，因為字型可能會把數字 0 與數字 1 畫在看似正確但實際上編碼完全不是那回事的位置。