ベース64

コンピュータ プログラミングにおいて、Base64 は、バイナリ データを64 個の一意の文字セットに限定された印刷可能な文字のシーケンスに変換する、バイナリからテキストへのエンコード方式のグループです。具体的には、ソース バイナリ データは一度に 6 ビット取得され、この 6 ビットのグループは 64 個の一意の文字の 1 つにマップされます。

すべてのバイナリからテキストへのエンコード方式と同様に、Base64 は、テキストコンテンツのみを確実にサポートするチャネルを介してバイナリ形式で保存されたデータを伝送するように設計されています。Base64 は、特にWorld Wide Web ^{[1]で普及しており、その用途の 1 つは、} HTMLファイルやCSSファイルなどのテキストアセット内に画像ファイルやその他のバイナリアセットを埋め込む機能です。^[2]

Base64 は電子メールの添付ファイルの送信にも広く使用されています。これは、 SMTP が元々 7 ビット ASCII文字のみ を転送するように設計されていたためです。送信前に添付ファイルを Base64 としてエンコードし、受信時にデコードすることで、古い SMTP サーバーが添付ファイルに干渉することがなくなります。

Base64 エンコーディングでは、元のバイナリ データのサイズに比べて 33～37% のオーバーヘッドが発生します (33% はエンコーディング自体によるもので、挿入された改行によってさらに最大 4% 増加します)。

基数の64桁の値を表すために選択された64文字の特定のセットは、実装によって異なります。一般的な戦略は、ほとんどのエンコーディングに共通で、印刷可能な64文字を選択することです。この組み合わせにより、電子メールなど、従来は8ビットクリーンではなかった情報システムを介して転送中にデータが変更される可能性が低くなります。^[3]たとえば、MIMEのBase64実装では、最初の62個の値にA– Z、a– z、0–を使用します。他のバリエーションでもこの特性は共有されますが、最後の2つの値に選択される記号が異なります。その一例がUTF-79です。

このタイプのエンコードの最も初期の例は、同じOS を実行するシステム間のダイヤルアップ通信用に作成されたものです(たとえば、UNIXのuuencodeやTRS-80 (後にMacintosh用に改良)のBinHex )。そのため、どの文字を安全に使用できるかについてより多くの仮定を立てることができました。たとえば、uuencode は大文字、数字、および多くの句読点を使用しますが、小文字は使用しません。^{[4] [5] [6] [3]}

これは RFC 4648 §4 で定義されている Base64 アルファベットです。§バリアントの概要表も参照してください。

以下の例では、説明を簡単にするためにASCIIテキストを使用していますが、これは一般的な使用例ではありません。Base64 を処理できるすべてのシステム間で既に安全に転送できるためです。より一般的な使用方法は、バイナリ データ(画像など) をエンコードすることです。結果の Base64 データには 64 種類の ASCII 文字のみが含まれ、生のソース バイトが破損する可能性のあるシステム間でも確実に転送できます。

分散コンピューティングのよく知られた慣用句を次に示します。

引用符 (末尾の空白なし) が Base64 にエンコードされると、次のようにMIMEの Base64 スキームでエンコードされた 8 ビット パディングされたASCII文字のバイト シーケンスとして表されます(改行と空白はどこにでも存在できますが、デコード時には無視されます)。

上記の引用では、 Manのエンコードされた値はTWFuです。ASCII でエンコードされた文字M、a、およびn は、8 ビットのバイナリ値77、97、および であるバイト値、 、として保存されます。これらの 3 つの値は 24 ビットの文字列に結合され、 を生成します。6 ビットのグループ (6 ビットには最大 2 ⁶  = 64 の異なるバイナリ値があります)は、最初から最後まで個別の数値に変換され(この場合、24 ビットの文字列には 4 つの数値があります)、次に対応する Base64 文字値に変換されます。 110010011010110000101101110010011010110000101101110

この例が示すように、Base64 エンコードは 3 つのオクテットを4 つのエンコードされた文字に変換します。

=最後のエンコードされたブロックに 4 つの Base64 文字が含まれるように、パディング文字が追加されることがあります。

16進数から 8 進数への変換は、バイナリと Base64 間の変換に役立ちます。このような変換は、高度な計算機とプログラミング言語の両方で利用できます。たとえば、上記の 24 ビットの 16 進数表現は 4D616E です。8 進数表現は 23260556 です。これらの 8 桁の 8 進数はペア ( 23 26 05 56 ) に分割でき、各ペアは 10 進数に変換されて19 22 05 46になります。これらの 4 つの 10 進数を Base64 アルファベットのインデックスとして使用すると、対応する ASCII 文字はTWFuになります。

重要な入力オクテットが 2 つしかない場合 (例: 'Ma')、または最後の入力グループに 2 つのオクテットしか含まれていない場合、16 ビットすべてが最初の 3 つの Base64 桁 (18 ビット) にキャプチャされます。最後のコンテンツを含む 6 ビット ブロックの最下位 2 ビット=はゼロになり、デコード時に破棄されます (後続のパディング文字 と共に)。

重要な入力オクテットが 1 つだけの場合 (例: 'M')、または最後の入力グループに 1 つのオクテットのみが含まれている場合、8 ビットすべてが最初の 2 つの Base64 桁 (12 ビット) にキャプチャされます。最後のコンテンツを含む 6 ビット ブロックの最下位 4 ビットはゼロになり、デコード時に破棄されます (後続の 2 つのパディング文字と共に=)。

Base64 は 6 ビットのエンコードであり、デコードされた値は 8 ビットのオクテットに分割されるため、Base64 でエンコードされたテキストの 4 文字 (4 つのセクステット = 4 × 6 = 24 ビット) ごとに、エンコードされていないテキストまたはデータの 3 つのオクテット (3 つのオクテット = 3 × 8 = 24 ビット) を表します。つまり、エンコードされていない入力の長さが 3 の倍数でない場合は、エンコードされた出力の長さが 4 の倍数になるようにパディングを追加する必要があります。パディング文字は で=、入力を完全にエンコードするためにそれ以上のビットは必要ないことを示します (これは、残りのビットがすべてゼロであることを意味する とは異なりますA)。次の例は、上記の引用の入力を切り捨てると出力のパディングがどのように変化するかを示しています。

パディング文字はデコードに必須ではありません。欠落しているバイト数はエンコードされたテキストの長さから推測できるからです。実装によってはパディング文字が必須ですが、その他の実装では使用されません。パディング文字が必要となる例外は、複数の Base64 エンコード ファイルが連結されている場合です。

Base64 テキストをデコードする場合、通常は 4 文字が 3 バイトに変換されます。唯一の例外は、パディング文字が存在する場合です。 は=4 文字が 2 バイトにのみデコードされることを示し、 は==4 文字が 1 バイトにのみデコードされることを示します。例:

パディング文字を解釈する別の方法は、 が見つかるたびにビット文字列から末尾の 2 ビットを破棄する命令として考えることです=。たとえば、 ` bGlnaHQg dw== ` をデコードする場合、各文字 ( の末尾の出現を除く) を対応する 6 ビット表現に変換し、最初の の末尾の 2 ビットと他の の末尾の別の 2 ビットを破棄します。この例では、 から 6 ビット、 から別の 6 ビットを取得して長さ 12 のビット文字列を生成しますが、 ごとに 2 ビット(合計 4 ビット) を削除するため、をデコードすると 8 ビット (1 バイト) が生成されます。 ===dw=dw==

パディングがない場合、4 文字を 3 バイトに通常どおりデコードすると、エンコードされた文字が 4 文字未満になることがあります。この状況では、2 文字または 3 文字しか残りません。1 つの Base64 文字には 6 ビットしか含まれず、1 バイトを作成するには 8 ビットが必要なため、エンコードされた文字を 1 つだけ残すことはできません。したがって、最低でも 2 つの Base64 文字が必要です。最初の文字は 6 ビットを提供し、2 番目の文字は最初の 2 ビットを提供します。例:

パディングなしのデコードはデコーダー間で一貫して実行されません。さらに、定義上、パディングなしのデコードを許可すると、複数の文字列を同じバイトセットにデコードできるため、セキュリティ上のリスクが生じる可能性があります。^[7]

実装によっては、一部のビット パターンを表すために使用されるアルファベットに制約がある場合があります。これは特に、アルファベットの位置 62 と 63 で使用される最後の 2 つの文字と、パディングに使用される文字 (一部のプロトコルでは必須、他のプロトコルでは削除される場合があります) に関係します。以下の表は、これらの既知のバリアントをまとめたものであり、以下のサブセクションへのリンクを示しています。

現在MIME Base64と呼ばれるエンコーディングの最初の標準化された使用は、 1987年にRFC 989で提案されたPrivacy-enhanced Electronic Mail (PEM)プロトコルでした。PEMは、Base64エンコーディングを使用して任意のオクテット シーケンスをSMTPなどの転送プロトコルで要求される6ビット文字の短い行で表現できる形式に変換する「印刷可能なエンコーディング」スキームを定義します。^[8]

PEMの現在のバージョン（RFC  1421で指定）では、大文字と小文字のローマ字（- 、- ）、数字（- ）、記号と記号で構成される64文字のアルファベットが使用されています。記号はパディングサフィックスとしても使用されます。^[4]元の仕様であるRFC  989では、出力ストリーム内のエンコードされたが暗号化されていないデータを区切るためにも記号が使用されていました。 AZaz09+/=*

データを PEM 印刷可能エンコーディングに変換するには、最初のバイトを24 ビットバッファの最上位8 ビットに配置し、次のバイトを中間の 8 ビットに配置し、3 番目のバイトを最下位の8 ビットに配置します。エンコードするバイトが 3 バイト未満 (または合計) の場合、残りのバッファ ビットはゼロになります。次に、バッファは、最上位から順に 6 ビットずつ、文字列 " " のインデックスとして使用され、指定された文字が出力されます。 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

残りのオクテットが 4 未満になるまで、残りのデータに対してこのプロセスが繰り返されます。 3 オクテットが残っている場合は、通常どおり処理されます。 エンコードする残りのオクテットが 3 未満 (24 ビット) の場合、入力データは 6 ビットの整数倍になるように右側にゼロ ビットが埋め込まれます。

パディングされていないデータをエンコードした後、24 ビット バッファの 2 つのオクテットがパディングされたゼロである場合、=出力に 2 つの文字が追加されます。24 ビット バッファの 1 つのオクテットがパディングされたゼロで埋められている場合は、1 つの=文字が追加されます。これは、パディングによって追加されたゼロ ビットを再構築されたデータから除外する必要があることをデコーダに通知します。これにより、エンコードされた出力の長さが 4 バイトの倍数になることも保証されます。

PEM では、最後の行を除いて、エンコードされたすべての行が正確に 64 個の印刷可能な文字で構成されている必要があります。最後の行には、印刷可能な文字が少なくてもかまいません。行は、ローカル (プラットフォーム固有) の規則に従って、空白文字で区切られます。

MIME (Multipurpose Internet Mail Extensions) 仕様では、Base64 は 2 つのバイナリからテキストへのエンコード方式の 1 つとして挙げられています (もう 1 つはquoted-printableです)。^[5] MIMEの Base64 エンコードは、PEM のRFC 1421 バージョンのエンコードに基づいています 。PEM と同じ 64 文字のアルファベットとエンコード メカニズムを使用し、RFC  2045 で説明されているように、出力パディングに同じ方法でシンボルを使用します。=

MIME では、Base64 でエンコードされた行の固定長は指定されていませんが、行の最大長は 76 文字と指定されています。また、ほとんどの実装では CR/LF 改行ペアを使用してエンコードされた行を区切っていますが、64 のエンコード文字の標準セット外の文字 (CRLF シーケンスなど) は準拠デコーダーによって無視される必要があると指定されています。

したがって、MIME 準拠の Base64 エンコードされたバイナリ データの実際の長さは、通常、元のデータ長の約 137% ( 4 ⁄ 3 × 78 ⁄ 76 ) ですが、非常に短いメッセージの場合は、ヘッダーのオーバーヘッドによりオーバーヘッドがはるかに高くなる可能性があります。大まかに言うと、Base64 エンコードされたバイナリ データの最終的なサイズは、元のデータ サイズの 1.37 倍 + 814 バイト (ヘッダー用) に等しくなります。デコードされたデータのサイズは、次の式で概算できます。

バイト = (文字列の長さ(エンコードされた文字列) − 814) / 1.37

UTF-7は、 RFC 1642で最初に説明され、後にRFC 2152 に置き換えられましたが、修正Base64 と呼ばれるシステムを導入しました。このデータエンコード方式は、 UTF-16をASCII文字としてエンコードし、SMTPなどの7ビットトランスポートで使用するために使用されます。これは、MIMEで使用されるBase64エンコードのバリエーションです。^{[9] [10]}

「修正 Base64」アルファベットは MIME Base64 アルファベットから構成されますが、「=」パディング文字は使用されません。UTF-7 はメール ヘッダー ( RFC  2047 で定義) で使用するためのもので、「」文字は「quoted-printable」エンコードのエスケープ文字としてそのコンテキストで予約されています。修正 Base64 はパディングを省略し、最後の Base64 桁の直後に終了し、最後の Base64 桁には最大 3 つの未使用ビットが残ります。 =

RFC  4880で説明されているOpenPGP は、 Radix-64エンコード (別名「ASCII アーマー」) について説明しています。Radix-64 は、MIME で説明されている「Base64」エンコードと同じですが、オプションで 24 ビットCRCが追加されています。エンコード前に入力データに対してチェックサムが計算されます。チェックサムは同じ Base64 アルゴリズムでエンコードされ、区切り記号として「 」記号が前に付けられて、エンコードされた出力データに追加されます。^[11]=

RFC  3548 は、「Base16、Base32、および Base64 データ エンコーディング」というタイトルで、Base64 エンコーディング、代替アルファベット エンコーディング、および Base32 (ほとんど使用されない) と Base16 エンコーディングのRFC  1421 およびRFC 2045 仕様を統一しようとする 情報 (非規範的) メモです。

実装がRFC 3548を参照する仕様に従って書かれ 、特に別の要求がない限り、RFC 3548は、実装がエンコーディングアルファベット外の文字を含むメッセージやパディングなしのメッセージを生成することを禁止し、デコーダー実装はエンコーディングアルファベット外の文字を含むデータを拒否しなければならないことも宣言しています。^[6]

RFC  4648 はRFC  3548 を廃止し、Base64/32/16 に重点を置いています。

このドキュメントでは、一般的に使用される Base64、Base32、および Base16 エンコード スキームについて説明します。また、エンコードされたデータでの改行の使用、エンコードされたデータでのパディングの使用、エンコードされたデータでのアルファベット以外の文字の使用、さまざまなエンコード アルファベットの使用、および標準エンコードについても説明します。

Base64 エンコーディングは、HTTP 環境でかなり長い識別情報を使用する場合に役立ちます。たとえば、Javaオブジェクトのデータベース永続化フレームワークでは、Base64 エンコーディングを使用して、比較的大きな一意の ID (通常は 128 ビットのUUID ) を文字列にエンコードし、HTTP フォームまたは HTTP GET URLの HTTP パラメータとして使用します。また、多くのアプリケーションでは、非表示の Web フォーム フィールドを含む URL に含めるのに便利な方法でバイナリ データをエンコードする必要があり、Base64 はそれらをコンパクトにレンダリングするのに便利なエンコーディングです。

URLで標準の Base64 を使用するには、 ' +'、' ' 、/および ' =' 文字を特別なパーセントエンコードされた16 進シーケンスにエンコードする必要があります (' +' は ' ' になり、' ' は ' ' になり、' ' は ' ' になります)。これにより、文字列が不必要に長くなります。 %2B/%2F=%3D

このため、URL バリアント用の修正 Base64が存在し ( RFC 4648のbase64urlなど  )、標準 Base64 の' ' と ' ' 文字がそれぞれ ' ' と ' ' に置き換えられているため、URL エンコーダー/デコーダーを使用する必要がなくなり、エンコードされた値の長さにも影響がなくなり、リレーショナル データベース、Web フォーム、および一般的なオブジェクト識別子で同じエンコード形式をそのまま使用できます。このようなものを利用する人気のサイトはYouTubeです。^[12]一部のバリアントでは、フィールド区切り文字と混同されないようにパディング ' ' 記号を省略することが許可または要求されるか、そのようなパディングはパーセントエンコードする必要があります。一部のライブラリ^{[ which? ]}は ' ' を ' ' にエンコードするため、フォルダー名がユーザー データからエンコードされるときに、アプリケーションが相対パス攻撃にさらされる可能性があります。^{[引用が必要]}+/-_==.

HTML5ドラフト仕様^[13]atob()で定義されているJavaScriptメソッドとメソッドは、 WebページにBase64エンコードおよびデコード機能を提供します。メソッドはパディング文字を出力しますが、これはメソッドの入力ではオプションです。 btoa()btoa()atob()

Base64 はさまざまなコンテキストで使用できます。

• Base64は、区切り文字の衝突を引き起こす可能性のあるテキストの送信と保存に使用できます。
• Base64はLDAPデータ交換フォーマットファイル内の文字列をエンコードするために使用されます。
• Base64 は、たとえばFirefoxのエクスポートされたのfaviconsに似た構文を使用して、XMLファイルにバイナリ データを埋め込むためによく使用されます。<data encoding="base64">…</data>bookmarks.html
• Base64 は、外部ファイルに依存しないように、スクリプト内の画像などのバイナリ ファイルをエンコードするために使用されます。
• Base64はHTMLページにPDFファイルを埋め込むために使用できます。 ^[15]
• データURI スキームでは、 Base64 を使用してファイルの内容を表すことができます。たとえば、背景画像とフォントは、別々のファイルで指定するのではなく、 CSSスタイルシート ファイルで URI として指定できますdata:。
• SVG形式の公式仕様には含まれていませんが、一部のビューアでは、SVGファイル内のラスター画像などの埋め込み要素に使用される場合、Base64を解釈できます。^[16]
• Base64 は、比較的少量のバイナリ データをコンピューターのテキストクリップボード機能を介して保存/送信するために使用できます。特に、情報を永続的に保存する必要がない場合や、互換性がない可能性のあるさまざまなプログラム間で情報をすばやく送信する必要がある場合に使用できます。例としては、暗号通貨の受信者の公開鍵を Base64 でエンコードされたテキスト文字列として表現することが挙げられます。このテキスト文字列は、ユーザーのウォレット ソフトウェアに簡単にコピーして貼り付けることができます。
• ファイルのチェックサムやキー フィンガープリントなど、安全メカニズムとして人間が迅速に検証する必要があるバイナリ データは、簡単にチェックできるように Base64 で表現されることが多く、 PGPキー フィンガープリントの表現で 4 文字の各グループをスペースで区切るなどの追加の書式が使用されることもあります。
• バイナリ データを含むQR コードは、すべての QR コード リーダーがテキストを正確にデコードするという保証がより強く、また一部のデバイスでは潜在的に悪意のあるバイナリ データよりも QR コードからのテキストの方が保存しやすいため、生のバイナリ データを単純に保存するのではなく、Base64 でエンコードして保存することがあります。

一部のアプリケーションでは、最も一般的な Base64 バリアントで使用されるアルファベットとは大きく異なる Base64 アルファベットが使用されます (上記のバリアントの概要表を参照)。

• Uuencoding のアルファベットには小文字は含まれず、代わりに ASCII コード 32 ("  " (スペース)) から 95 (" _") までが連続して使用されます。Uuencoding ではアルファベット"  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_"が使用されます。多くの古いプリンタは大文字しか印刷しないため、小文字をすべて避けるのは便利です。連続した ASCII 文字を使用すると、ルックアップ テーブルを必要とせずに 32 を加算するだけで済むため、計算能力を節約できます。ほとんどの句読点文字とスペース文字を使用するため、これらの文字を構文として使用するアプリケーションなど、一部のアプリケーションでは有用性が制限される可能性があります。^{[引用が必要]}
• 従来の Mac OSで使用されていたBinHex 47 (HQX) では、「 」、「O」、「g」、および「などの視覚的に紛らわしい文字が除外されていますo。そのアルファベットには追加の句読点文字が含まれています。アルファベット「!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr」を使用します。
• UTF -8環境では、非同期継続バイトを base64: として使用できます。UTF -8#自己同期を参照してください。0b10xxxxxx
• 他のいくつかのアプリケーションでは、一般的なバリエーションに似たアルファベットが使用されていますが、順序が異なります。
  • Unix は、 B64と呼ばれるエンコードを使用して、 cryptで計算されたパスワード ハッシュを/etc/passwdファイルに保存します。crypt のアルファベットは、英数字の前に句読点とを配置します。crypt は、アルファベット " " をパディングなしで使用します。RFC 4648 よりも優れている点は、エンコードされた ASCII データをソートすると、プレーンな ASCII データをソートした場合と同じ順序になることです。././0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
  • 系図データ交換のためのGEDCOM 5.5標準は、マルチメディアファイルをテキスト行階層ファイル形式でエンコードします。GEDCOMはcryptと同じアルファベット「./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz」を使用します。^[17]
  • bcryptハッシュは従来のcrypt(3)ハッシュと同じように使用できるように設計されていますが、bcryptのアルファベットの順序はcryptのものと異なります。bcryptはアルファベット「./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789」を使用します。 ^[18]
  • Xxencoding は、 crypt に似た主に英数字の文字セットを使用しますが、andではなく+and。Xxencoding はアルファベット" "を使用します。-./+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
  • 一部の端末ノードコントローラで使用される6PACKは、0x00から0x3fまでのアルファベットを使用します。^[19]
  • BashはBase64の数値リテラルをサポートしています。Bashはアルファベット「0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_」を使用します。 ^[20]

• 8ビット
• Ascii85 (Base85 とも呼ばれる)
• 16進数
• ベース32
• ベース36
• ベース62
• さまざまなエンコードアルゴリズムを比較するためのバイナリからテキストへのエンコード
• 2進数
• メールアドレス