Loading article…
バイナリからテキストへのエンコードは、プレーンテキストでのデータのエンコードです。より正確には、印刷可能な文字のシーケンスでのバイナリデータのエンコードです。これらのエンコードは、通信チャネルがバイナリデータを許可しない場合（電子メールやNNTPなど）、または8ビットクリーンでない場合のデータ送信に必要です。PGPドキュメント（RFC 4880）では、Base64を指すバイナリからテキストへのエンコードに「 ASCIIアーマー」 という用語を使用しています。
概要
バイナリからテキストへのエンコードの基本的な必要性は、英語の人間が読めるテキストのみを伝送するように設計された既存の通信プロトコルを介して任意のバイナリ データを通信する必要性から生じます。これらの通信プロトコルは 7 ビット セーフのみ (およびその範囲内で特定の ASCII 制御コードを避ける) であり、特定の最大間隔で改行が必要であり、空白が維持されない場合があります。したがって、データの伝送に「安全」に使用できるのは、 印刷可能な94 のASCII 文字のみです。
説明
ASCIIテキストエンコード規格では、文字をエンコードするために 7 ビットを使用します。これにより、英語で一般的に使用されるアルファベット、数字、句読点、および印刷可能な文字を表さない制御文字を表すために、128 (つまり 2 7 )個の一意の値 (0～127) をエンコードすることが可能です。たとえば、大文字のAは 7 ビットで 100 0001 2、0x41 (101 8 )と表され、数字の2は 011 0010 2 0x32 (62 8 ) 、文字}は 111 1101 2 0x7D (175 8 ) 、制御文字RETURNは 000 1101 2 0x0D (15 8 ) です。
対照的に、ほとんどのコンピュータは、8 ビットバイトで編成されたメモリにデータを保存します。マシン実行可能コードと非テキスト データを含むファイルには、通常、256 個の 8 ビット バイト値がすべて含まれています。多くのコンピュータ プログラムは、7 ビットテキストと 8 ビットバイナリデータのこの区別に依存するようになり、ASCII テキストのみを含むことが予想されるデータに非 ASCII 文字が現れると、正しく機能しなくなりました。たとえば、8 番目のビットの値が保持されない場合、プログラムは 127 を超えるバイト値を、何らかの機能を実行するように指示するフラグとして解釈する可能性があります。
しかし、電子メール メッセージに画像ファイルを添付する場合など、テキスト以外のデータをテキストベースのシステムで送信できることが望ましい場合がよくあります。これを実現するには、8 ビットのデータを 7 ビットの ASCII 文字 (通常は英数字と句読点のみ、つまり ASCII 印刷可能文字) にエンコードするなど、何らかの方法でデータをエンコードします。送信先に安全に到着すると、8 ビット形式にデコードされます。このプロセスは、バイナリからテキストへのエンコードと呼ばれます。PGPやGNU Privacy Guardなど、多くのプログラムが、データ転送を可能にするためにこの変換を実行します。
プレーンテキストのエンコード
バイナリからテキストへのエンコード方式は、プレーンテキストをエンコードするメカニズムとしても使用されます。例:
- 一部のシステムでは、処理できる文字セットがより制限されており、 8 ビット クリーンではないだけでなく、印刷可能なすべての ASCII 文字を処理できないシステムもあります。
- 他のシステムでは、 RFC 2821で許可されている一部のSimple Mail Transfer Protocolソフトウェアの「1 行あたり 1000 文字」の制限など、改行間に表示される文字数に制限があります。
- さらに、テキストにヘッダーやトレーラーを追加する人もいます。
- あまり評価されていないが、現在も使用されているプロトコルの中には、インバンド シグナリングを使用するものがあり、メッセージに特定のパターンが出現すると混乱を招きます。最もよく知られているのは、行の先頭にある文字列「From」（末尾のスペースを含む）で、mboxファイル形式でメール メッセージを区切るために使用されます。
すでにプレーン テキストであるメッセージにバイナリからテキストへのエンコードを使用し、反対側でデコードすることで、このようなシステムを完全に透過的に見せることができます。これは、「ASCII アーマー」と呼ばれることもあります。たとえば、ASP.NETの ViewState コンポーネントは、区切り文字の衝突を回避するために、base64エンコードを使用してHTTP POST 経由でテキストを安全に送信します。
エンコーディング標準
以下の表は、バイナリからテキストへのエンコードの最もよく使用される形式を比較したものです。記載されている効率は、入力のビット数とエンコードされた出力のビット数の比率です。
32 から 126 までの95 個のisprintコードがASCII 印刷可能文字として知られています。
古くて現在では一般的ではない形式としては、BOO、BTOA、USR エンコーディングなどがあります。
これらのエンコーディングのほとんどは、すべてのASCII印刷可能文字のサブセットのみを含むテキストを生成します。たとえば、base64エンコーディングは、大文字と小文字 (A～Z、a～z)、数字 (0～9)、および「+」、「/」、「=」記号のみを含むテキストを生成します。
これらのエンコードの一部 (quoted-printable およびパーセントエンコード) は、許可された文字のセットと 1 つのエスケープ文字に基づいています。許可された文字は変更されず、他のすべての文字はエスケープ文字で始まる文字列に変換されます。この種の変換により、文字と数字が許可された文字の一部であるためエンコードされたテキストにそのまま残されるため、結果のテキストはほぼ判読可能になります。これらのエンコードは、ほとんどが印刷可能な ASCII である入力に対して、最も短いプレーン ASCII 出力を生成します。
その他のエンコーディング ( base64、uuencoding ) は、6ビットの可能なすべてのシーケンスをさまざまな印刷可能な文字にマッピングすることに基づいています。印刷可能な文字は 2 6 = 64 個以上あるため 、これは可能です。特定のバイト シーケンスは、ビット ストリームとして表示され、このストリームが 6 ビットのチャンクに分割され、対応する文字のシーケンスが生成されます。異なるエンコーディングは、ビット シーケンスと文字のマッピングと、結果のテキストのフォーマット方法が異なります。
一部のエンコード ( BinHex のオリジナル バージョンとCipherSaberの推奨エンコード) では、6 ビットではなく 4 ビットを使用し、4 ビットのすべての可能なシーケンスを 16 の標準16 進数字にマッピングします。エンコードされた文字ごとに 4 ビットを使用すると、出力が base64 よりも 50% 長くなりますが、エンコードとデコードが簡素化されます。ソース内の各バイトを独立して 2 つのエンコード バイトに拡張する方が、base64 で 3 つのソース バイトを 4 つのエンコード バイトに拡張するよりも簡単です。
PETSCIIの最初の192のコードのうち、164は引用時に目に見える表現を持ちます：5（白）、17〜20と28〜31（色とカーソルコントロール）、32〜90（ASCII相当）、91〜127（グラフィックス）、129（オレンジ）、133〜140（ファンクションキー）、144〜159（色とカーソルコントロール）、および160〜192（グラフィックス）。 [13]これにより、理論的にはPETSCIIを話すマシン間でbase128などのエンコードが可能になります。
参照
注記
- ^ QR コード生成のエンコードでは、入力文字セットに合わせてエンコードが自動的に選択され、2 つの英数字が 11 ビットでエンコードされ、Base45 では 16 ビットが 3 つのそのような文字にエンコードされます。したがって、32 ビットのバイナリ データが 33 ビットでエンコードされ、効率は 97% になります。
- ^ 任意のデータの場合、予約されていない 189 文字すべてを 3 バイトでエンコードし、残りの 66 文字を 1 バイトでエンコードします。
- ^ テキストの場合、18 個の予約文字のみをエンコードします。
- ^ 1 バイトは =XX として保存されます。必要のない 94 文字 (スペースとタブを含む) を除くすべての文字がエンコードされます。
参考文献
- ^ Fältström, Patrik; Ljunggren, Freik; Gulik, Dirk-Willem van (2022-08-11). 「Base45 データ エンコーディング」。
バイト モードでも、一般的な QR コード リーダーはバイト シーケンスを UTF-8 または ISO/IEC 8859-1 でエンコードされたテキストとして解釈しようとします。... このようなデータは、そのテキストを QR コードとしてエンコードする前に適切なテキストに変換する必要があります。... Base45 ... は、よりコンパクトな QR コード エンコーディングを提供します。
- ^ Duggan, Ross (2009 年 8 月 18 日)。「PHP での Base-56 整数エンコーディング」。
- ^ 岳彼;ユ・ソン;ジェン・ジア;シウイン・ユー。魏国。魏和;チャオ・チー。ルー・シアンフイ。 「Base85/64 – Base91の代替案」（PDF）。国際情報学システム研究所。
- ^ 「バイナリから ASCIIテキストへのエンコーディング」。basE91。SourceForge 。2023年3月20日閲覧。
- ^ 「バイナリデータを最も低いオーバーヘッドでテキストに変換する」Voraklのメモ。2020年4月18日。
- ^ Albertson, Kevin (2016年11月26日). 「Base-122エンコーディング」.
- ^ 「BaseXML - XML1.0+用」。GitHub。2019年3月16日。
- ^ "ビットコイン/bips". GitHub。 2021年12月8日。
- ^ Rusty Russell他 (2020-10-15). 「Lightning RFC リポジトリでの支払いエンコーディング」. GitHub .
- ^ 「v1+ 監視アドレス用の Bech32m 形式」。GitHub。2021年12 月 5 日。
- ^ ab RFC 1760「S/KEY ワンタイムパスワードシステム」。
- ^ RFC 1751「人間が読める 128 ビット キーの規約」
- ^ 「Commodore 64 PETSCII コード」。sta.c64.org。