バイナリ出力は1文字ちょうど1バイトですか?

コードポイントが 255 以下の文字なら、そうです。コードポイントを 2 進数で書き、先頭の 0 で 8 ビットに補完するため、ちょうど 1 バイトになります。コードポイント 65 の文字 A は 01000001、コードポイント 32 のスペースは 00100000 になります。255 を超える文字、たとえばコードポイント 128512 のスマイル顔絵文字はより長いグループを生成し、その場合は 17 ビットです。そのためテキストがクラシックな範囲を超えると、出力は 8 ビットグループと長いグループが混在します。

バイナリを文字列に戻すにはどうすればよいですか?

コンバータをバイナリ → テキストのモードに切り替え、スペースや改行で区切ったグループを貼り付けます。ツールは各グループを 2 進数として読んで文字にマッピングするため、01001000 01101001 は Hi に戻ります。グループが 0 でも 1 でもない文字で始まると、ツールは推測する代わりに無効なバイナリと報告して停止し、1 つのタイプミスでその後の全文字がずれることを防ぎます。

なぜ一部のグループは 8 ビットを超えるのですか?

グループの長さが固定のバイトサイズではなくコードポイントに追随するからです。コードポイント 0 から 255 は 8 ビットに収まり、クラシックな ASCII テキストは一律の 8 ビットグループを生成します。スマイル顔絵文字のコードポイントは 128512 で 17 ビット、すなわち 11111011000000000 が必要で、コンバータは切り詰めずに全长を出力します。そのため絵文字入りの英語など混在テキストは短いグループと長いグループの混合を生成し、復元側が期待しているのはまさにそれです。

これは ASCII と同じものですか?

最初の 128 文字では同じです。ASCII のコードポイントと Unicode のコードポイントは一致するため、A は両方のシステムで 65、すなわち 01000001 です。128 から 255 のクラシックな拡張範囲も 1 つの 8 ビットグループに収まります。255 を超えるとコンバータは Unicode のコードポイントに従うため、絵文字や CJK テキストを扱えるのです。厳密な ASCII ツールなら 127 で止まります。コードポイント表示ではなく送受信形式を見たい場合は、16 進や UTF-8 バイトのコンバータが実際に格納されるバイトを見せます。

同じ考え方の他のエンコーディングには何がありますか?

一族全体です。Base64 は 3 バイトを 4 文字にパックしてメールや JSON での送受信を可能にし、URL エンコーディングは URL が保持できないバイトだけを書き換え、文字列のエスケープはコード中の引用符やバックスラッシュを守り、モールス符号は文字を点と横棒に写します。バイナリはこの中で最も直接的で、数字自体がデータです。それが、他の包装形式を選ぶ前の正しい出発点となる理由です。

テキスト ⇄ バイナリ変換の使い方:A=65が01000001、Hiが01001000 01101001、空白=32が00100000、絵文字128512は17桁、バイナリから文字への逆変換も算出

テキストはシステムの内部では文字のままではなく、1文字ごとに数字として扱われています。テキスト ⇄ バイナリ変換はその事実をそのまま見せるツールです。テキストを入力すると、コンピュータが実際に扱う 0 と 1 のグループ列を返し、そのグループ列を元に戻して読みやすい文字列にもします。このガイドでは実例で変換の一連の流れを追跡し、出力を 8 ビットずつ読む方法、一部の文字が 8 ビット以上を必要とする理由、そして同一ファミリーの他のエンコーディングとの比較を説明します。

記事の構成は次の通りです。A・H・i を中心にコードポイントから 8 ビットグループへの変換の仕組みを追い、01001000 01101001 を Hi に読み戻し、スマイル顔絵文字が 8 ビットではなく 17 ビットを必要とする理由、逆方向変換とその唯一の失敗モード、そしてモールス符号・Base64・URL エンコーディング・文字列のエスケープに対してバイナリがどの位置に置かれるかを解説します。

テキストがバイナリになる仕組み:コードポイントと 8 ビットグループ

各文字は Unicode が割り当てた整数、コードポイントに対応します。変換はその整数を 2 進数で書き、先頭の 0 で 8 ビットに補完します。文字 A のコードポイントは 65 で、01000001 になります。H は 72 で 01001000、i は 105 で 01101001 なので、Hi はグループ間のスペース 1 つで 01001000 01101001 に変換されます。スペース自体のコードポイントは 32 で 00100000 になり、そのため原文とバイナリ出力は文字ごとに位置合わせられます。各文字が独立して 1 グループを生成するため、出力を 2 進数のリストと見ることもできます。他の進数との変換を頻繁に行う場合は、基数変換が同じ考え方を 8 進、16 進、2 から 36 までの任意の基数に広げます。

出力を 1 バイトずつ読んで復元する

結果を読み戻すには、スペースで区切って各 8 ビットグループを数値に戻します。01000001 は 65、01001000 は 72、01101001 は 105 で、コード表を引くと A、H、i が得られ、先頭の文字を飛ばせば Hi です。テキストが長くなると手作業ではミスが入りやすいため、まずグループ数を数えましょう。グループ数は入力文字数(スペースを含む)と一致しなければなりません。文字カウントはちょうどその件数、スペース込みで報告するため、手で復元を始める前の簡単なクロスチェックになります。

8 ビットを超える Unicode コードポイント

8 ビットへの補完がカバーするのは 0 から 255 のクラシックな範囲で、Unicode はそれよりはるかに広いです。スマイル顔絵文字のコードポイントは 128512 で、バイナリ形式は 11111011000000000 の 17 ビット文字列で、1 バイトでは収まりません。変換は切り詰めもラップもしません。グループはコードポイントが要求する長さまで伸び、復元も同じ手順で読み戻します。プレーン ASCII と絵文字や CJK 文字が混ざったテキストでは、8 ビットグループと長いグループが混在します。コードポイント表示ではなくバイト単位の表示が必要なら、Hex/UTF-8/Base64変換が各文字が UTF-8 バイトとしてどう格納されるかをそのまま見せてくれます。これは多くのプロトコルが実際に送信するレイヤーです。

バイナリからテキストへの変換

ツールをバイナリ → テキストのモードに切り替えてグループ列を貼り付けます。変換は空白で分割し、各グループを 2 進数として読んで文字にマッピングするため、01001000 01101001 は Hi に戻ります。複数行にまたがる貼り付けも問題ありません。スペースや改行の連続はすべて区切りとして扱われます。失敗モードは単純です。0 か 1 で始まらないグループは 2 進数としてパースできず、ツールは推測する代わりに「無効なバイナリ」エラーで止まります。これにより長い貼り付け中の 1 つのタイプミスが、その後の全文字を静かにずらすことを防げます。

バイナリが他のエンコーディングの中で占める位置

バイナリはこのファミリーの中で最も直接的なエンコーディングで、数字自体がデータです。他のエンコーディングは同じ情報を別の文字表に包みます。モールス符号エンコーダ/デコーダは文字を点と横棒に写像し、各文字の記号価値のデモには適していますが、大文字小文字や多くの句読点を落としてしまうという別の意味で情報を持たない形式です。Base64 エンコーダ/デコーダは 3 バイトを 4 文字にパックするため、メールや JSON を安全に通過できますが、結果は元の文字と 1 対 1 で対応しません。URLエンコーダ/デコーダは URL が保持できないバイト(スペースや記号など)だけを書き換え、その他はそのまま残します。エスケープ/アンエスケープはコード中のテキストを扱い、引用符やバックスラッシュを引用符コンテキストでも無傷で残る系列に変えます。どの形式が合うかを判断することこそ、バイナリ出力が手伝う本題であることが多いです。

よくあるミスと回避法

復元失敗のほぼすべては 3 つのミスに集約されます。第一に、出力全体を 1 つの長い数ではなくグループのリストとして扱わないこと。01000001 01001000 は 2 文字で、16 ビットの値ではありません。第二に、手動編集で先頭の 0 を落とすこと。数値が変われば復元される文字も変わります。第三に、全グループが 8 ビットだと決めつけること。255 を超えるコードポイントを持つ絵文字などの文字は長いグループを生成し、復元側が期待するのはエンコード側が書いた通りの長さです。スペース、先頭の 0、グループ境界を残せば、両方向ともきれいに往復します。