バイナリからテキストへのエンコード
バイナリデータのテキストとしての表現

バイナリからテキストへのエンコードは、バイナリデータをプレーンテキストとして表現するデータ エンコード方式です。通常、バイナリデータは任意の8ビットバイト（オクテット）値のシーケンスで構成され、テキストはASCIIなどの一般的に使用される文字エンコードの印刷可能な文字コードに制限されます。一般的に、任意のバイナリデータには印刷可能な文字コードではない値が含まれるため、テキストのみを処理するように設計されたソフトウェアは、そのようなデータを処理できません。バイナリデータをテキストとしてエンコードすると、本来テキストとして保存されない情報を、そうでなければ任意のバイナリデータを処理できないソフトウェアで処理できるようになります。ソフトウェアは情報を解釈することはできませんが、転送や保存などのデータに対する有用な操作を実行 できます

PGPドキュメント ( RFC 9580) では、 Base64 を参照するときに、バイナリからテキストへのエンコードに「ASCII アーマー」という用語を使用しています。

概念的には、バイナリからテキストへのエンコードは、数値の基数 ( radix ) の表現とは異なります。たとえば、10 進数は値を 10 進数で表す方式ですが、バイナリからテキストへのエンコードではありません。エンコードされたデータに 10 進数表現を使用するバイナリからテキストへのエンコードも考えられますが、そのようなシステムでは 4 ビットのエンコード シーケンスのうち 10 個の値しか使用されず、残りの 6 個の値は使用されません。より効率的なエンコードでは 16 個の値すべてを使用します。これが Base16 で、各 4 ビット シーケンスのエンコードに16進数を使用します。特に、16 は2 の累乗であるため、Base16 と 16 進数は概念的には異なりますが、実際には区別がつきません。

パーセントエンコーディングやquoted-printableなどのエスケープエンコーディングも、任意のバイナリデータをテキストとして表現することを可能にしますが、その方法は大きく異なります。バイナリからテキストへのエンコーディングでは入力シーケンス全体をエンコードしますが、エスケープエンコーディングでは、既にテキストであるデータにバイナリデータを埋め込むことができます。

使用

バイナリデータをテキストとして送信する

バイナリからテキストへのエンコードにより、任意のバイナリデータ（電子メールやNNTPなど）を許可しない通信チャネル、または8ビットクリーンではない通信チャネルでデータを送信できます。このエンコードにより、人間が読める（つまり英語）テキストを伝送するように設計された通信プロトコルを介してバイナリデータを送信できます。多くの場合、このようなプロトコルは7ビットの文字値のみをサポートし（その中で特定の制御コードは回避されます）、一定の最大間隔で改行が必要になる場合があり、空白が維持されない場合があります。したがって、データの伝送に安全に使用できるのは、 印刷可能な94文字のASCII文字のみです

ASCIIテキストエンコード規格では、7ビットを使用して文字をエンコードします。これにより、英語で一般的に使用されるアルファベット、数字、句読点、および一部の非印刷制御文字を表すために、128（つまり2の7乗）の一意の値（0～127）をエンコードすることが可能です。例えば、大文字のAは65（41の16乗、100の0001の2乗）、数字の2は50（32の16乗、011の0010の2乗）、右中括弧}は125（7Dの16乗、111の1101の2乗）、復帰制御文字CRは13（0Dの16乗、000の1101の2乗）で表されます。

対照的に、ほとんどのコンピュータは、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コンポーネントは、区切り文字の衝突を回避するために、HTTP POST経由でテキストを安全に送信するためにBase64エンコードを使用しています。

例

以下の表は、バイナリからテキストへの主要なエンコードについて説明しています。記載されている効率は、入力のビット数とエンコードされた出力のビット数の比です

エンコーディング 効率 プログラミング言語の実装 コメント
Ascii85 80% awk 2014年12月29日アーカイブ、Wayback Machine、C、C (2)、C#、F#、Go、Java、Perl、Python、Python (2) このエンコーディングには、Base85、btoaなど、 いくつかのバリエーションが存在します。
Base16 50% ほとんどの言語 16進数に基づいているため、大文字、小文字、または両方のバリエーションがあります
Base32 62.5% ANSI C、Delphi、Go、Java、C#、F#、Python  
Base36 約64% bash、C、C++、C#、Java、Perl、PHP、Python、Visual Basic、Swift、その他多数 数字（0～9）と小文字（a～z）のみを使用します。TinyURLやSnipURL /SniprなどのURLリダイレクトシステムでは、コンパクトな英数字識別子としてよく使用されます。
45進数 約67% (97% [a] ) Go、Python IETF仕様RFC9285で定義されており、QRコードにバイナリデータをコンパクトに含めることができます。[1]
Base56 — PHP、Python、Go Base58に似ていますが、詐欺や人的エラーのリスクを最小限に抑えるために、文字1と小文字のO（ ）をさらに除外します。 [2]o
Base58 約73% C、C++、Python、C#、Java Base64に似ていますが、英数字以外の文字（+と/）と、レンダリング時に曖昧に見えることが多い文字のペア（ゼロ（0）と大文字のO（O）、大文字のI（I）と小文字のL（ ））を除外します。Base58はビットコインlアドレスを表すために使用されます。[要出典] SegWitでは、Bech32に置き換えられました
オリジナルのビットコインソースコードのBase58
Base62 約74% Rust、Python Base64に似ていますが、英数字のみを含みます
Base64 75% awk 2014年12月29日アーカイブ、Wayback Machine、C、C (2)、Delphi、Go、Python、その他多数 1987年にRFC  989 の一部として初めて指定された、初期の、そして今でも人気のあるエンコーディング。
Base85 80% C、Python、Python (2) Ascii85の改訂版
Base91 [3] 81% C# F# 定数幅バリアント
basE91 [4] 81% C、Java、PHP、8086アセンブリ、AWK、C#、F#、Rust 可変幅バリアント
Base94 [5] 82% Python、C、Rust  
Base122 [6] 87.5% JavaScript、Python、Java、Base125 PythonとJavascript、Go、C  
BaseXML [7] 83.5% C Python JavaScript  
Bech32 62.5% + 少なくとも8文字（ラベル、セパレーター、6文字のECC） C、C++、JavaScript、Go、Python、Haskell、Ruby、Rust 仕様。[8]ビットコインとライトニングネットワークで使用されています。[9]データ部分はBase32のようにエンコードされており、末尾の6文字のBCHコードを使用して最大6文字までの誤入力をチェック・修正できます。このコードにより、人間が読める部分もチェック・修正されます。Bech32mバリアントには微妙な変更が加えられており、長さの変化に対する耐性が高まっています。[10]
BinHex 75% Perl、C、C (2) macOS Classic
Intel HEX 約50% Cライブラリ、C++ 通常、EPROM、NORフラッシュメモリチップ のプログラムに使用されます。
MIME Quoted-printableとBase64を参照 Quoted-printableとBase64を参照 電子メールのようなフォーマットのためのエンコードコンテナ
Sレコード（モトローラ16進数） 49.6% Cライブラリ、C++ 通常、 EPROM、NORフラッシュメモリチップのプログラムに使用されます。49.6%は、レコードあたり255バイナリバイトを想定しています
テクトロニクス16進数 通常、EPROM、NORフラッシュメモリチップの プログラムに使用されます
TxMS TypeScript、CLI、Dart TxMSは、バイナリからテキストへのエンコードを使用してバイナリデータを読み取り可能なテキスト形式に圧縮し、16進数への可逆的な変換を可能にします
Uuエンコーディング 約60%（最大70%） Perl、C、Delphi、Java、Python、その他多数 1980年にUnix-to-Unixコピー用に開発された初期のエンコーディング。MIMEとyEncに大部分が置き換えられた。
Xxエンコーディング 約75%（Uuencodingと同様） C、Delphi ASCII と EBCDIC システム間の文字セット変換の問題を回避するために Uuencoding の代替として提案され (時々使用される)、Uuencoding データが破損する可能性がある。
z85 (ZeroMQ仕様:32/Z85) 80% (Ascii85/Base85と同様) C (オリジナル)、C#、Dart、Erlang、Go、Lua、Ruby、Rust など Ascii85に類似した ASCII のサブセットを指定します。ただし、プログラムのバグを引き起こす可能性のある文字 ( ` \ " ' _ , ;) は省略されます。この形式は ZeroMQ spec:32/Z85 に準拠しています。
RFC  1751 ( S/KEY [11] ) 33% C、Python

「人間が読める128ビット鍵のための規約」。短い英語の単語の列は、10進数やその他のバイナリからテキストへのエンコードシステムよりも、人間にとって読みやすく、記憶しやすく、入力しやすい。 [12] 64ビットの数値はそれぞれ、公開されている2048語の辞書から、1～4文字の6つの短い単語にマッピングされる。[11]

古くて現在では一般的ではない形式としては、BOO、BTOA、USR エンコードなどがあります。

Base64（uuencodingを含む多くのバリエーション）は、6ビットのシーケンスを印刷可能な文字にマッピングします。印刷可能な文字数は2の6乗 =64文字以上あるため、これは可能です。与えられたバイトシーケンスは、ビットストリームとして解釈され、このストリームを6ビットのチャンクに分割し、対応する文字シーケンスを生成します。異なるエンコーディングは、ビットシーケンスと文字のマッピング方法と、結果のテキストのフォーマット方法が異なります。

一部のエンコーディング（BinHexのオリジナルバージョンとCipherSaberの推奨エンコーディング）では、6ビットではなく4ビットを使用し、4ビットのあらゆるシーケンスを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などのエンコードが可能になります。

参照

注記

  1. ^ QRコード生成のエンコードは、入力文字セットに合わせて自動的にエンコードを選択し、英数字2文字を11ビットでエンコードします。Base45は16ビットを3文字にエンコードします。したがって、32ビットのバイナリデータを33ビットでエンコードする効率は97%です

参考文献

  1. ^ Fältström, Patrik; Ljunggren, Freik; Gulik, Dirk-Willem van (2022-08-11). 「Base45データエンコーディング」。バイトモードであっても、一般的なQRコードリーダーはバイトシーケンスをUTF-8またはISO/IEC 8859-1でエンコードされたテキストとして解釈しようとします。…このようなデータは、QRコードとしてエンコードする前に適切なテキストに変換する必要があります。…Base45は…よりコンパクトなQRコードエンコーディングを提供します
  2. ^ Duggan, Ross (2009年8月18日). 「PHPにおけるBase-56整数エンコーディング」
  3. ^ 岳彼;ユ・ソン;ジェン・ジア;シウイン・ユー。魏国。魏和;チャオ・チー。ルー・シアンフイ。 「Base85/64 – Base91の代替案」（PDF）。国際情報学システム研究所。
  4. ^ 「バイナリからASCIIテキストへのエンコーディング」basE91 . SourceForge . 2023年3月20日閲覧。
  5. ^ 「バイナリデータを最も低いオーバーヘッドでテキストに変換する」Voraklのメモ。2020年4月18日。
  6. ^ Albertson, Kevin (2016年11月26日). 「Base-122エンコーディング」
  7. ^ “BaseXML - XML1.0+向け”. GitHub . 2019年3月16日.
  8. ^ "ビットコイン/bips". GitHub。 2021年12月8日。
  9. ^ Rusty Russell他 (2020-10-15). 「Lightning RFC リポジトリにおける支払いエンコーディング」. GitHub .
  10. ^ 「v1+ witnessアドレス用のBech32mフォーマット」GitHub。2021年12月5日。
  11. ^ ab RFC  1760「S/KEY ワンタイムパスワードシステム」。
  12. ^ RFC  1751「人間が読める128ビット鍵の規約」
  13. ^ 「Commodore 64 PETSCIIコード」。sta.c64.org。
「https://en.wikipedia.org/w/index.php?title=Binary-to-text_encoding&oldid=1321497871#ASCII_armor」より取得