Base64

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

コンピュータプログラミングではBase64は、 4つの6ビットBase64桁で表すことができる24ビットのシーケンスで バイナリデータ(より具体的には、8ビットバイトのシーケンス)を表すバイナリからテキストへのエンコーディングスキームのグループです。

すべてのバイナリからテキストへのエンコードスキームに共通するBase64は、テキストコンテンツのみを確実にサポートするチャネル間でバイナリ形式で保存されたデータを伝送するように設計されています。Base64は、ワールドワイドウェブ[1]で特に普及しており、その用途の1つは、 HTMLCSSファイルなどのテキストアセット内に画像ファイルやその他のバイナリアセットを埋め込む機能です。[2]

Base64は、電子メールの添付ファイルの送信にも広く使用されています。SMTPは、元の形式では7ビットASCII文字のみを転送するように設計されているため、これが必要です。このエンコーディングにより、33〜36%のオーバーヘッドが発生します(エンコーディング自体で33%、挿入された改行によって最大3%多くなります)。

デザイン

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

このタイプのエンコーディングの初期のインスタンスは、同じOSを実行しているシステム間のダイヤルアップ通信用に作成されました。たとえば、UNIXの場合はuuencodeTRS-80の場合はBinHex(後でMacintoshに適合)などです。どの文字を安全に使用できるか。たとえば、uuencodeは大文字、数字、および多くの句読文字を使用しますが、小文字は使用しません。[4] [5] [6] [3]

RFC4648のBase64テーブル

これは、 RFC4648§4で定義されているBase64アルファベットです。バリアントの概要(下記) も参照してください。

索引 バイナリ チャー 索引 バイナリ チャー 索引 バイナリ チャー 索引 バイナリ チャー
0 000000 A 16 010000 Q 32 100000 g 48 110000 w
1 000001 B 17 010001 R 33 100001 h 49 110001 x
2 000010 C 18 010010 S 34 100010 i 50 110010 y
3 000011 D 19 010011 T 35 100011 j 51 110011 z
4 000100 E 20 010100 U 36 100100 k 52 110100 0
5 000101 F 21 010101 V 37 100101 l 53 110101 1
6 000110 G 22 010110 W 38 100110 m 54 110110 2
7 000111 H 23 010111 X 39 100111 n 55 110111 3
8 001000 I 24 011000 Y 40 101000 o 56 111000 4
9 001001 J 25 011001 Z 41 101001 p 57 111001 5
10 001010 K 26 011010 a 42 101010 q 58 111010 6
11 001011 L 27 011011 b 43 101011 r 59 111011 7
12 001100 M 28 011100 c 44 101100 s 60 111100 8
13 001101 N 29 011101 d 45 101101 t 61 111101 9
14 001110 O 30 011110 e 46 101110 u 62 111110 +
15 001111 P 31 011111 f 47 101111 v 63 111111 /
パディング =

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

分散コンピューティングのよく知られたイディオムは次のとおりです。

多くの手が軽い仕事をします。

引用符がBase64にエンコードされると、次のようにMIMEのBase64スキームでエンコードされた8ビットが埋め込まれたASCII文字のバイトシーケンスとして表されます(改行と空白はどこにでも存在する可能性がありますが、デコード時には無視されます)。

TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

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

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

ソース テキスト(ASCII) M a n
オクテット 77(0x4d) 97(0x61) 110(0x6e)
ビット 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0
Base64
でエンコード
セクステット 19 22 5 46
キャラクター T W F u
オクテット 84(0x54) 87(0x57) 70(0x46) 117(0x75)

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

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

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

ソース テキスト(ASCII) M a
オクテット 77(0x4d) 97(0x61)
ビット 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 0
Base64
でエンコード
セクステット 19 22 4 パディング
キャラクター T W E =
オクテット 84(0x54) 87(0x57) 69(0x45) 61(0x3D)

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

ソース テキスト(ASCII) M
オクテット 77(0x4d)
ビット 0 1 0 0 1 1 0 1 0 0 0 0
Base64
でエンコード
セクステット 19 16 パディング パディング
キャラクター T Q = =
オクテット 84(0x54) 81(0x51) 61(0x3D) 61(0x3D)

出力パディング

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

入力 出力 パディング
文章 長さ 文章 長さ
軽い仕事k。 11 bGlnaHQg d29y ay4 = 16 1
ライトワーク_ 10 bGlnaHQg d29y aw == 16 2
軽いワー 9 bGlnaHQg d29y 12 0
ライトヲ_ 8 bGlnaHQg d28 = 12 1
軽いw 7 bGlnaHQg dw == 12 2

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

パディングを使用したBase64のデコード

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

エンコードされた パディング 長さ デコード
bGlnaHQg dw == == 1 軽いw
bGlnaHQg d28 = = 2 ライトヲ_
bGlnaHQg d29y なし 3 軽いワー

パディングなしでBase64をデコードする

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

長さ エンコードされた 長さ デコード
2 bGlnaHQg dw 1 軽いw
3 bGlnaHQg d28 2 ライトヲ_
4 bGlnaHQg d29y 3 軽いワー

実装と履歴

バリアントサマリーテーブル

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

エンコーディング 文字のエンコード 行の個別のエンコーディング 非エンコード文字のデコード
62位 63位 パッド セパレーター 長さ チェックサム
RFC 1421 :プライバシー強化メール用のBase64(非推奨) + / =必須 CR + LF 最後の行は64以下 番号 番号
RFC 2045 : MIMEのBase64転送エンコーディング + / =必須 CR + LF 最大76 番号 破棄
RFC 2152 : UTF-7のBase64 + / 番号 番号 番号
RFC 3501:IMAPメールボックス名のBase64エンコーディング + , 番号 番号 番号
RFC4648§4:base64(標準) [a] + / =オプション 番号 番号
RFC4648§5:base64url(URLおよびファイル名に安全な標準) [a] - _ =オプション 番号 番号
RFC 4880 : OpenPGP用のRadix-64 + / =必須 CR + LF 最大76 Radix-64でエンコードされた24ビットCRC 番号
その他のバリエーション RFC-4648 Base64と互換性のないアプリケーション(下記) を参照してください。
  1. ^ a b このバリアントは、実装によって特殊化されることが望ましくない共通の機能を提供することを目的としており、堅牢なエンジニアリングを保証することに注意することが重要です。これは特に、以前の標準が他の場所で使用するために採用された場合には考慮されていなかった、個別のラインエンコーディングと制限に照らして行われます。したがって、ここに示されている機能はオーバーライドされる可能性があります。

プライバシー強化メール

現在MIMEBase64と呼ばれているエンコーディングの最初の既知の標準化された使用法は、1987年にRFC989によって提案されたPrivacy - enhancedElectronic Mail(PEM)プロトコルでした。PEMは、Base64エンコーディングを使用してSMTPなどの転送プロトコルで必要とされる6ビット文字の短い行で表現できる形式へのオクテット[7] 

PEMの現在のバージョン(RFC 1421で指定)は、大文字と小文字のローマ字)、数字()、および記号で構成される64文字のアルファベットを使用します。記号は、パディング接尾辞としても使用されます。[4]元の仕様であるRFC989は、出力ストリーム内のエンコードされているが暗号化されていないデータを区切るためにシンボルを 追加で使用していました。 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

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

MIMEは、Base64でエンコードされた行の固定長を指定しませんが、最大行長76文字を指定します。さらに、ほとんどの実装ではCR / LF改行ペアを使用してエンコードされた行を区切り ますが、アルファベット以外の文字は準拠デコーダーで無視する必要があることを指定しています。

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

バイト=(string_length(encoded_string)-814)/ 1.37

UTF-7

最初にRFC1642で説明されたUTF-7は、後にRFC 2152に取って代わられ、変更されたBase64と呼ばれるシステムを導入しましこのデータエンコード方式は、 SMTPなどの7ビットトランスポートで使用するASCII文字としてUTF-16をエンコードするために使用されます。これは、MIMEで使用されるBase64エンコーディングのバリアントです。[8] [9]  

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

OpenPGP

RFC 4880説明されているOpenPGPは、「 ASCIIアーマー」としても知られるRadix-64エンコーディングについて説明していますRadix-64は、オプションの24ビットCRCが追加されている点を除いて、MIMEで説明されている「Base64」エンコーディングと同じですチェックサムは、エンコード前に入力データに対して計算されます。次に、チェックサムは同じBase64アルゴリズムでエンコードされ、区切り文字として「」記号がプレフィックスとして付けられ、エンコードされた出力データに追加されます。[10] =

RFC 3548

 「 Base16 、Base32、およびBase64データエンコーディング」というタイトルのRFC 3548、Base64エンコーディング、代替アルファベットエンコーディング、およびBase32(めったにない)のRFC1421およびRFC2045仕様統一しよとする情報(非規範的)メモです。使用)およびBase16エンコーディング。   

実装がRFC3548を参照する仕様に記述されており、特に別の方法が必要な場合を除き、 RFC 3548は、実装がエンコードアルファベット外またはパディングなしの文字を含むメッセージを生成することを禁止し、デコーダー実装がエンコード外の文字を含むデータを拒否する必要があることも宣言します。アルファベット。[6] 

RFC 4648

このRFCはRFC3548を廃止し、Base64 / 32/16に焦点を当てています。

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

URLアプリケーション

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

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

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

HTML

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

その他のアプリケーション

Base64でエンコードされた埋め込みJPEG画像を含むSVGの例[13]

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

  • Base64を使用して、区切り文字の衝突を引き起こす可能性のあるテキストを送信および保存できます
  • スパマーはBase64を使用して、基本的なスパム対策ツールを回避します。このツールは、Base64をデコードしないことが多いため、エンコードされたメッセージ内のキーワードを検出できません。
  • Base64は、 LDIFファイルの文字列をエンコードするために使用されます
  • Base64は、Firefoxのエクスポートされたファビコンなどの構文を使用して、バイナリデータをXMLファイルに埋め込むためによく使用されます<data encoding="base64">…</data>bookmarks.html
  • Base64は、外部ファイルへの依存を避けるために、スクリプト内の画像などのバイナリファイルをエンコードするために使用されます。
  • データURIスキームでは、Base64を使用してファイルの内容を表すことができます。たとえば、背景画像とフォントは、個別のファイルで提供されるのではなく、URIとしてCSSスタイルシートファイルで指定できます。data:
  • FreeSWAN IPSec実装は、Base64文字列の前0sに。があるため、テキストまたは16進文字列と区別できます。[要出典]
  • SVGの公式仕様の一部ではありませんが、一部のビューアは、SVG内の画像などの埋め込み要素に使用すると、Base64を解釈できます。[14]

RFC-4648Base64と互換性のないアプリケーション

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

  • Uuencodingアルファベットには小文字が含まれず、代わりにASCII 32( " "(スペース))から95( "_")までが連続して使用されます。Uuencodingはアルファベット"  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_"を使用します。多くの古いプリンタは大文字しか印刷しないため、すべて小文字を避けることは役に立ちました。連続するASCII文字を使用すると、ルックアップを実行せずに32を追加するだけでよいため、計算能力が節約されました。ほとんどの句読文字とスペース文字を使用すると、その有用性が制限されます。[要出典]
  • 従来のMacOS内で使用されていたBinHex4(HQX)は7 ''、 'O'、 ''、 'g'などの視覚的に混乱する文字を除外しoます。アルファベットには追加の句読文字が含まれています。アルファベット!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqrを使用しています。
  • 他のいくつかのアプリケーションは、一般的なバリエーションに似ていますが、順序が異なるアルファベットを使用します。
    • Unixは、暗号化で計算されたパスワードハッシュをB64と呼ばれるエンコーディングを使用して/etc/passwdファイルに保存します。cryptのアルファベットは、英数字の前に句読点を置きます。cryptはアルファベット " "を使用します。パディングは使用しません。././0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
    • 系図データ交換のGEDCOM5.5標準は、マルチメディアファイルをテキスト行の階層ファイル形式でエンコードします。GEDCOMは、cryptと同じアルファベットである" ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"を使用します。[15]
    • bcryptハッシュは、従来のcrypt(3)ハッシュと同じように使用するように設計されていますが、bcryptのアルファベットはcryptのアルファベットとは異なる順序になっています。bcryptはアルファベット" ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"を使用します。[16]
    • Xxencodingは、cryptに似たほとんど英数字の文字セットを使用しますが、+and-ではなく.and/ます。Xxencodingはアルファベット" +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"を使用します。
    • 一部のターミナルノードコントローラーで使用される6PACKは、0x00から0x3fまでのアルファベットを使用します。[17]
    • Bashは、Base64で数値リテラルをサポートしています。Bashはアルファベット" 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_"を使用します。[18]

も参照してください

参考文献

  1. ^ 「Base64のエンコードとデコード-WebAPI | MDN」
  2. ^ 「画像をbase64エンコードする場合(およびしない場合)」2011年8月28日。
  3. ^ a b Base16、Base32、およびBase64データエンコーディングIETF2006年10月。doi10.17487 / RFC4648RFC4648 _ 2010年3月18日取得
  4. ^ a b InternetElectronic Mailのプライバシー強化:パートI:メッセージの暗号化と認証の手順IETF1993年2月。doi10.17487 / RFC1421RFC1421 _ 2010年3月18日取得
  5. ^ a b 多目的インターネットメール拡張機能:(MIME)パート1:インターネットメッセージ本文の形式IETF1996年11月。doi10.17487 / RFC2045RFC2045 _ 2010年3月18日取得
  6. ^ a b Base16、Base32、およびBase64データエンコーディングIETF2003年7月。doi10.17487 / RFC3548RFC3548 _ 2010年3月18日取得
  7. ^ インターネット電子メールのプライバシー強化IETF1987年2月。doi10.17487 / RFC0989RFC989 _ 2010年3月18日取得
  8. ^ UTF-7Unicodeのメールセーフ変換形式IETF1994年7月。doi10.17487 / RFC1642RFC1642 _ 2010年3月18日取得
  9. ^ UTF-7Unicodeのメールセーフ変換形式IETF1997年5月。doi10.17487 / RFC2152RFC2152 _ 2010年3月18日取得
  10. ^ OpenPGPメッセージフォーマットIETF2007年11月。doi10.17487 / RFC4880RFC4880 _ 2010年3月18日取得
  11. ^ 「YouTubeが実際に一意のビデオIDを使い果たすことがない理由はここにあります」www.mentalfloss.com2016年3月23日2021年12月27日取得
  12. ^ 「7.3。Base64ユーティリティメソッド」HTML5.2編集者のドラフトWorld WideWebコンソーシアム2018年1月2日取得チェンジセット5814、2021-02-01によって導入されました。
  13. ^ <image xlink:href = "data:image / jpeg; base64、JPEG contents encoded in Base64" ... />
  14. ^ 「フィドルの編集」jsfiddle.net
  15. ^ 「GEDCOM標準リリース5.5」Homepages.rootsweb.ancestry.com 2012年6月21日取得
  16. ^ Provos、Niels(1997-02-13)。"src / lib / libc / crypt / bcrypt.cr1.1" 2018年5月18日取得
  17. ^ 「6PACK「リアルタイム」PCからTNCプロトコル」2013年5月19日取得
  18. ^ 「シェル算術」Bashリファレンスマニュアル2020年4月8日取得それ以外の場合、数値は[base#] nの形式になります。ここで、オプションの基数は算術基数を表す2〜64の10進数であり、nはその基数の数値です。