バイナリからテキストへのエンコード

バイナリからテキストへのエンコーディングは、プレーンテキストでのデータのエンコーディングです。より正確には、一連の印刷可能な文字のバイナリデータのエンコードです。これらのエンコードは、チャネルでバイナリデータ（電子メールやNNTPなど）が許可されていない場合、または8ビットクリーンでない場合にデータを送信するために必要です。 PGPのドキュメント（RFC 4880）では、Base64を指す場合、バイナリからテキストへのエンコードにASCIIアーマーという用語を使用しています。

説明

ASCIIテキストエンコーディング標準では、128個の一意の値（0〜127）を使用して、英語で一般的に使用されるアルファベット、数字、および句読点文字に加えて、印刷可能な文字を表さない制御コードを選択します。たとえば、大文字AはASCII文字65、数字2はASCII 50、文字}はASCII 125、メタ文字のキャリッジリターンはASCII 13です。ASCIIベースのシステムは、これらの値をデジタルで表すために7ビットを使用します。

対照的に、ほとんどのコンピューターは、8ビットバイトで編成されたメモリにデータを保存します。マシンで実行可能なコードと非テキストデータを含むファイルには、通常、256個の可能な8ビットバイト値がすべて含まれています。多くのコンピュータープログラムは、7ビットテキストと8ビットバイナリデータのこの区別に依存するようになり、ASCIIテキストのみを含むと予想されるデータに非ASCII文字が含まれていると、正しく機能しません。たとえば、8番目のビットの値が保持されない場合、プログラムは127を超えるバイト値を、何らかの機能を実行するよう指示するフラグとして解釈する場合があります。

ただし、画像ファイルを電子メールメッセージに添付する場合など、テキストベースのシステムを介して非テキストデータを送信できることが望ましい場合がよくあります。これを実現するために、データは何らかの方法でエンコードされ、8ビットデータは7ビットASCII文字にエンコードされます（通常は英数字と句読文字（ASCII印刷可能文字）のみを使用）。宛先に無事到着すると、8ビット形式にデコードされます。このプロセスは、バイナリからテキストへのエンコーディングと呼ばれます。 PGPやGNU Privacy Guard（GPG）など、多くのプログラムがこの変換を実行してデータ転送を可能にします。

プレーンテキストのエンコード

バイナリからテキストへのエンコード方法は、プレーンテキストをエンコードするためのメカニズムとしても使用されます。例えば：

• 一部のシステムでは、処理できる文字セットがより制限されています。 8ビットクリーンでないだけでなく、すべての印刷可能なASCII文字を処理できないものもあります。
• 他のシステムでは、RFC 2821で許可されているように、一部のSMTPソフトウェアの「1行あたり1000文字」の制限など、改行間に表示される文字数に制限があります。
• さらに、ヘッダーまたはトレーラーをテキストに追加するものもあります。
• いくつかのよく知られていないがまだ使用されているプロトコルはインバンドシグナリングを使用し、特定のパターンがメッセージに表示されると混乱を引き起こします。最もよく知られているのは、mboxファイル形式のメールメッセージを区切るために使用される行の先頭の文字列 "From"（末尾のスペースを含む）です。

すでにプレーンテキストであるメッセージに対してバイナリからテキストへのエンコードを使用し、もう一方の側でデコードすることにより、そのようなシステムを完全に透過的に見せることができます。これは、「ASCIIアーマー」と呼ばれることもあります。たとえば、ASP.NETのViewStateコンポーネントは、区切り文字の衝突を回避するために、base64エンコードを使用してHTTP POSTを介してテキストを安全に送信します。

エンコーディング標準

次の表は、バイナリからテキストへのエンコーディングの最も使用されている形式を比較しています。リストされている効率は、入力のビット数とエンコードされた出力のビット数の比率です。

95のisprintコード32〜126は、ASCII印刷可能文字として知られています。

いくつかの古い、そして今日では珍しい形式には、BOO、BTOA、およびUSRエンコーディングが含まれます。

これらのエンコーディングのほとんどは、すべてのASCII印刷可能文字のサブセットのみを含むテキストを生成します。たとえば、base64エンコーディングは、大文字と小文字（A〜Z、a〜z）、数字（0〜9）のみを含むテキストを生成します、および「+」、「/」、および「=」記号。

これらのエンコーディングの一部（quoted-printableおよびパーセントエンコーディング）は、許可される文字のセットと単一のエスケープ文字に基づいています。許可される文字は変更されずに残りますが、他のすべての文字はエスケープ文字で始まる文字列に変換されます。この種の変換により、文字と数字は許可された文字の一部であり、エンコードされたテキストのままであるため、結果のテキストはほとんど読みやすくなります。これらのエンコードは、ほとんどが印刷可能なASCIIである入力に対して、最短のプレーンASCII出力を生成します。

いくつかの他のエンコーディング（base64、uuencoding）は、6ビットのすべての可能なシーケンスを異なる印刷可能文字にマッピングすることに基づいています。 26 = 64を超える印刷可能な文字があるため、これは可能です。指定されたバイトシーケンスは、ビットストリームとして表示し、このストリームを6ビットのチャンクに分割して、対応する文字のシーケンスを生成することにより変換されます。エンコードの違いは、ビットと文字のシーケンス間のマッピングと、結果のテキストのフォーマット方法が異なります。

一部のエンコード（BinHexのオリジナルバージョンとCipherSaberの推奨エンコード）は、6ビットではなく4ビットを使用し、4ビットのすべての可能なシーケンスを16の標準16進数にマッピングします。エンコードされた文字ごとに4ビットを使用すると、base64よりも50％長い出力が得られますが、エンコードとデコードは簡略化されます。

PETSCIIの最初の192個のコードのうち、164個は引用時に5（白）、17〜20および28〜31（色とカーソルコントロール）、32〜90（ascii相当）、91〜127（グラフィック）、129（オレンジ）、133〜140（ファンクションキー）、144〜159（色とカーソルコントロール）、および160〜192（グラフィック）。これにより、理論的には、PETSCIIを話すマシン間でbase128などのエンコードが可能になります。

ノート