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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

バイナリからテキストへのエンコーディングプレーンテキストでのデータのエンコーディングです。より正確には、印刷可能な文字のシーケンスでのバイナリデータのエンコードです。これらのエンコーディングは、チャネルがバイナリデータ(電子メール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ビット形式にデコードされます。このプロセスは、バイナリからテキストへのエンコーディングと呼ばれます。PGPGNUPrivacyGuard(GPG) など、多くのプログラムがこの変換を実行してデータ転送を可能にします。

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

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

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

エンコーディング標準

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

エンコーディング データ・タイプ 効率 プログラミング言語の実装 コメントコメント
ASCII [a] 任意 87.5% ほとんどの言語 これは、8ビットバイナリから7ビットデータへのビットシフトについて話しているため、7バイトのバイナリデータは8バイトの7ビットデータを占有します。これは、すべての可能な制御コードを含むASCIIを表します。このスキームは実際にはめったに使用されません。
Ascii85 任意 80% awkCC(2)C#F#GoJava PerlPythonPython(2) このエンコーディングには、Base85btoaなどのいくつかのバリエーションがあります。
Base32 任意 62.5% ANSI CDelphiGoJavaPython  
Base36 整数 〜64% bashCC ++C#JavaPerlPHPPythonVisual BasicSwift、その他多数 アラビア数字の0〜9とラテン文字のA〜Z(ISO基本ラテンアルファベットを使用します。TinyURLやSnipURL/Snipr などのURLリダイレクトシステムで、コンパクトな英数字の識別子として一般的に使用されます。
Base45 任意 〜67% 行け IETF仕様のドラフト[1]
Base58 整数 〜73% C ++Python Base64に似ていますが、英数字以外の文字(+および/)と、印刷時にあいまいに見える可能性のある文字(0 –ゼロ、I –大文字i、O –大文字oおよびl –小文字L)の両方を回避するように変更されています。Base58はビットコインアドレスを表すために使用されます。[2]一部のメッセージングおよびソーシャルメディアシステムは、英数字以外の文字列でを引きます。これは、+などのURI予約文字を使用しないことで回避されます。segwitについては、Bech32に置き換えられました。以下を参照してください。
元のビットコインソースコードのBase58
Base62 Base64に似ていますが、英数字のみが含まれています。
Base64 任意 75% awkCC(2)DelphiGoPython、その他多数  
Base85RFC 1924  任意 80% CPython Python(2) Ascii85の改訂版
Base91 [3] 任意 81% C#F# 一定幅のバリエーション
basE91 [4] 任意 81% C、Java、PHP、8086アセンブリ、AWK C#F# 可変幅バリアント
Base94 [5] 任意 82% Python C  
Base122 [6] 任意 87.5% JavaScript Python  
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つのタイプミスの文字をチェックおよび修正できます。これにより、HRP(Human Readable Part)もチェック/修正されます。Bech32mバリアントには微妙な変更があり、長さの変更に対してより弾力性があります。[10]
BinHex 任意 75% PerlCC(2) MacOSクラシック
10進数 整数 〜42% ほとんどの言語 通常、人間から/への入力/出力のデフォルト表現。
16進数(Base16) 任意 50% ほとんどの言語 大文字小文字のバリエーション で存在します
Intel HEX 任意 ≲50% CライブラリC ++ 通常、 EPROMNOR-フラッシュメモリチップ のプログラムに使用されます
MIME 任意 Quoted-printableおよびBase64を参照してください Quoted-printableおよびBase64を参照してください 電子メールのようなフォーマット用のエンコーディングコンテナ
MOSテクノロジーファイル形式 任意 通常、 EPROMNOR-フラッシュメモリチップのプログラムに使用されます。
パーセントエンコーディング テキスト(URI)、任意(RFC1738 〜40%[b](33–70%[c] CPython、おそらく他の多くの  
Quoted-printable 文章 〜33–100%[d] おそらく多く 改行を保持します。76文字で行をカットします
Sレコード(モトローラヘックス) 任意 49.6% CライブラリC ++ 通常、 EPROMNOR-フラッシュメモリチップのプログラムに使用されます。49.6%は、レコードあたり255バイナリバイトを想定しています。
Tektronix hex 任意 通常、 EPROMNOR-フラッシュメモリチップのプログラムに使用されます。
Uuencoding 任意 〜60%(最大70% PerlCDelphiJavaPython、おそらく他の多くの 主にMIMEとyEncに置き換えられました
Xxencoding 任意 〜75%(Uuencodingと同様) Cデルファイ Uuencodeデータを破損する可能性のあるASCIIとEBCDICシステム間の文字セット変換の問題を回避するために、Uuencodingの代わりとして提案されました(場合によっては使用されます)。
yEnc [a] 任意の、ほとんどが非テキスト 〜98% C JavaScript JavaScript(2) CRCチェックサムが含まれています
RFC  1751S / KEY 任意 33% C、[11] Python、..。

「人間が読める128ビットキーの規則」。一連の小さな英語の単語は、10進数やその他のバイナリからテキストへのエンコードシステムよりも、人間が読み、覚え、入力するのが簡単です。[12]各64ビットの数値は、公開されている2048ワードの辞書から、それぞれ1〜4文字の6つの短いワードにマップされます。[11]

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

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

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

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

他のいくつかのエンコーディング(base64uuencoding )は、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などのエンコードが可能になります。

も参照してください

メモ

  1. ^ a b 出力には印刷できない文字が含まれるため、厳密にはテキストエンコーディングではありません
  2. ^ 任意のデータの場合; 189個の予約されていない文字すべてを3バイトでエンコードし、残りの66文字を1バイトでエンコードします。
  3. ^ テキスト用; 18個の予約文字のそれぞれをエンコードするだけです。
  4. ^ =XXとして格納された1バイト。それを必要としない94文字を除くすべてをエンコードします(スペースとタブを含む)。

参照