Base64

^{6ビットの各入力シーケンス（ 2⁶}  = 64個の値をエンコード可能 ）は、Base64アルファベット文字にマッピングされます。したがって、Base64エンコードでは、3バイトの入力ごとに4文字が生成されます。入力がASCIIまたは類似であると仮定すると、最初の3文字「M」、「a」、「n」のバイトデータは、、、、の値であり77、978110ビットバイナリ表現では01001101、、、、、01100001となります01101110。これらの表現を結合し、6ビットグループに分割すると、次のようになります。

010011 010110 000101 101110 

これは文字列をエンコードしますTWFu（ASCIIまたは類似の方式で）。

次の表は、入力がどのようにエンコードされるかを示しています。たとえば、文字「M」は、77(ASCII などに従って) の値を持ちます。値の最初の 6 ビットは、010011または 19 の 10 進数で、Base64 文字「T」にマッピングされ、その値は84(ASCII などに従って) です。

入力バイト数が3の倍数より2多い場合（例：「M」、「a」）、最後の2バイト（16ビット）は3桁のBase64（18ビット）にエンコードされます。最後のコンテンツを含む6ビットブロックの最下位2ビット=は、エンコード時にはゼロとして扱われ、デコード時には（末尾のパディング文字とともに）破棄されます。

入力バイト数が3の倍数より1多い場合（例：「M」）、最後の8ビットは2桁のBase64（12ビット）で表現されます。最後のコンテンツを含む6ビットブロックの最下位4ビットは、エンコード時にはゼロとして扱われ、デコード時には（末尾の2つのパディング文字とともに）破棄されます=。

デコード時には、エンコードされた4文字のシーケンスごとに3バイトの出力に変換されますが、パディング文字が1文字の場合は最後の4文字は2バイトに、パディング文字が2文字の場合は最後の4文字は1バイトにデコードされます。例：

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

エンコードされたテキストにパディング文字を使用することは、デコードには必須ではありません。欠落バイト数は、エンコードされたテキストの長さから推測できます。一部の方式ではパディング文字が必須ですが、他の方式では使用されません。特に、 Base64でエンコードされた文字列を連結する場合、デコード時の曖昧さを避けるために、エンコード時にパディング文字を使用する必要があります。

パディングなしの場合、エンコードされた4文字のシーケンスをデコードした後、エンコードされた文字が2文字または3文字残る可能性があります。1文字だけが残ることはありません。なぜなら、1つのBase64文字は6ビットしか含まず、1バイトを作成するには8ビットが必要だからです。最初のBase64文字は6ビットを提供し、2番目のBase64文字は最初の2ビットを提供してバイトを埋めます。次の表は、残りの文字が2文字、3文字、または0文字の場合のエンコードされた文字列のデコードを示しています。

パディングなしのデコードはデコーダ間で一貫して実行されません。一部のデコーダはパディングを必要としますが、他のデコーダはエンコードされた入力文字列から適切なパディング量を推測します。^{[ 10 ]}さらに、定義上、パディングなしのデコードを許可すると、特定の順序で書き込まれた文字列のリストが、1つの出力文字列だけでなく、複数の異なる出力文字列にデコードされる可能性があり、予測不可能または予期しないデコードのためセキュリティリスクとなる可能性があります。^{[ 11 ]}

RFC 4648では、Base64を含む様々なエンコーディングについて説明しており、エンコードされたデータにおける改行の使用、パディングの使用、非アルファベット文字の使用、異なるエンコーディングアルファベットの使用、および正規エンコーディングについて論じています。Base 64エンコーディングおよびbase64と呼ばれるバリアントは、汎用を目的としています。 

RFCでは、比較的長い識別情報を表現することを目的とした、Base64エンコーディング（URLおよびファイル名セーフアルファベット付き）と呼ばれる別のBase64エンコーディングも規定しています。たとえば、Javaオブジェクトのデータベース永続化フレームワークでは、Base64エンコーディングを使用して、比較的大きな一意のID（一般的には128ビットのUUID）を文字列としてエンコードし、HTTPフォームのHTTPパラメータまたはHTTP GET URLで使用する場合があります。また、多くのアプリケーションでは、非表示のWebフォームフィールドを含め、URLに含めるのに便利な方法でバイナリデータをエンコードする必要があり、Base64はそれらをコンパクトに表現するのに便利なエンコーディングです。

URLで標準 Base64 を使用すると、文字+、、/および=文字を特別なパーセントエンコードされた16 進数シーケンスとしてエンコードする必要があります (+は%2B、/は、 は%2Fに=なります%3D)。これにより、文字列が長くなり、読みにくくなります。別のアルファベットを使用すると、この追加のマークアップを必要とせずに Base64 としてエンコードできます。通常、+および はそれぞれ/および に置き換えられるため、URL エンコーダー/デコーダーを使用する必要がなくなり、エンコードされた値の長さに影響がなくなり、同じエンコード形式がそのまま残るため、リレーショナル データベース、Web フォーム、および一般的なオブジェクト識別子で使用できます。このようなものを使用する一般的なサイトはYouTubeです。^{[ 13 ]}一部のバリアントでは、フィールド区切り文字と混同されないようにパディング記号を省略したり、そのようなパディングをパーセントエンコードしたりすることを許可または要求します。一部のライブラリはとしてエンコードするため、ユーザー データからフォルダ名がエンコードされている場合、アプリケーションが相対パス攻撃にさらされる可能性があります。-_==.

RFC 3548 「Base16、Base32、およびBase64データエンコーディング」は、情報提供を目的とした（規範的ではない）メモであり、Base64エンコーディング、代替アルファベットエンコーディング、および（ほとんど使用されていない）Base32エンコーディングとBase16エンコーディングに関するRFC 1421とRFC 2045の仕様を統一しようとするものです。RFC 4648はRFC 3548を廃止します。   

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

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

MIMEはBase64エンコードされた行の固定長を規定していませんが、最大行長を7​​6文字と規定しています。さらに、標準の64文字のエンコード文字セットに含まれない文字（例えばCRLFシーケンス）は、準拠デコーダによって無視されなければならないと規定していますが、ほとんどの実装ではエンコードされた行を区切るためにCR/LF改行文字ペアを使用しています。

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

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

現在MIME Base64と呼ばれるエンコーディングの最初の標準的な使用例は、1987年にRFC 989で提案されたプライバシー強化メール（PEM）プロトコルです。PEMは、任意のバイト列をSMTPなどの転送プロトコルで要求される6ビット文字の短い行で表現できる形式に変換するためにBase64エンコーディングを使用する「印刷可能なエンコーディング」スキームを定義しています。^{[ 14 ]} 

PEM の現行バージョン ( RFC 1421で規定) では、大文字と小文字のローマ字( – 、– )、数字 ( – )、および記号と で構成される 64 文字のアルファベットを使用しています。記号 はパディング接尾辞としても使用されます。^{[ 2 ]}元の仕様である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文字の印刷可能な文字で構成されている必要があります。ただし、最後の行はそれより少ない文字数でも構いません。行は、ローカル（プラットフォーム固有の）規則に従って空白文字で区切られます。

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

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

RFC 9580で説明されているOpenPGP は、「ASCII アーマー」を規定しており、これはオプションの 24 ビットCRCを追加した MIME で説明されている「Base64」エンコーディングと同一です。チェックサムはエンコード前に入力データに対して計算され、その後、同じ Base64 アルゴリズムでエンコードされ、区切り文字として「 」記号を先頭に付けてエンコードされた出力データに追加されます。^{[ 17 ]} =

HTML5 ドラフト仕様で定義されている JavaScript メソッド [ 18 ] [ 19 ] は、atob()Web^{ページにBase64エンコードおよびデコード}機能を提供します。メソッドはパディング文字を出力しますが、メソッドの入力ではこれらの文字はオプションです。 例: GIF ファイルの先頭のエンコード: ↦ .btoa()btoa()atob()btoa("GIF89a")"R0lGODlh"

いくつかの異体字は、一般的な異体字と似たアルファベットを使用するが、順序が異なる。

Unixパスワード

Unix は、 cryptで計算されたパスワード ハッシュを、B64と呼ばれるエンコーディングを使用して/etc/passwdファイルに保存します。crypt のアルファベットは、句読点とを英数字の前に配置します。crypt は、パディングなしでアルファベット " " を使用します。RFC 4648 に対する利点は、エンコードされた ASCII データをソートすると、プレーン ASCII データをソートした場合と同じ順序になることです。././0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

GEDCOM

系図データ交換のためのGEDCOM 5.5 標準は、マルチメディア ファイルをテキスト行階層ファイル形式でエンコードします。GEDCOM は、crypt と同じアルファベットである" ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"を使用します。^{[ 20 ]}

bcrypt

bcryptハッシュは、従来の crypt(3) ハッシュと同じように使用できるように設計されていますが、bcrypt のアルファベットは crypt のアルファベットとは異なる順序になっています。bcrypt はアルファベット" ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"を使用します。 ^{[ 21 ]}

Xxencoding

Xxencoding は、crypt と同様に主に英数字の文字セットを使用しますが、との代わりに+と。Xxencoding はアルファベット" "を使用します。-./+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

6個パック

一部のターミナルノードコントローラで使用され、0x00から0x3fまでのアルファベットを使用します。^{[ 22 ]}

バッシュ

Bash はBase64 形式の数値リテラルをサポートしています。Bash はアルファベット" 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_"を使用します。 ^{[ 23 ]}

一部のバリアントでは、最も一般的なBase64バリアント（RFC 4648など）で使用されるアルファベットとは大きく異なるBase64アルファベットが使用されます。

Uuencoding

Uuencodingアルファベットには小文字は含まれておらず、代わりに ASCII コード 32 ("  " (スペース)) から 95 (" _") までを連続して使用します。Uuencoding はアルファベット"  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_"を使用します。小文字をすべて避けることは、多くの古いプリンタが大文字しか印刷しなかったため、役立ちました。連続する ASCII 文字を使用することで、ルックアップ テーブルを必要とせずに 32 を追加するだけで済むため、計算能力が節約されました。ほとんどの句読点文字とスペース文字を使用しているため、これらの文字を構文として使用するアプリケーションなど、一部のアプリケーションでは有用性が制限される可能性があります。

ビンヘックス

従来の Mac OSで使用されていたBinHex 4 (HQX) は、7'、'O'、'g'、'などの視覚的に紛らわしい文字を除外していますo。そのアルファベットには追加の句読点文字が含まれています。アルファベットは" !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr"です。

UTF-8

UTF -8環境では、非同期継続バイトを base64: として使用できます。UTF -8#Self-synchronization を参照してください。0b10xxxxxx