ベース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個の値にAZaz0–を使用します9。他のバリエーションでもこの特性は共有されていますが、最後の2つの値に選択される記号が異なります。その一例がUTF-7です。

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

RFC 4648 の Base64 テーブル

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

RFC 4648 で定義されている 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文字のバイト シーケンスとして表されます(改行と空白はどこにでも存在できますが、デコード時には無視されます)。

翻訳:

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

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

ソース文字列⟨Man⟩のBase64エンコード
ソース
ASCIIテキスト
キャラクター 1つの
オクテット 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 あなた
オクテット 84 (0x54) 87 (0x57) 70 (0x46) 117 (0x75)

=最後のエンコードされたブロックに 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 ビット=はゼロになり、デコード時に破棄されます (後続のパディング文字 と共に)。

ソース
ASCIIテキスト
キャラクター 1つの
オクテット 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 =
オクテット 84 (0x54) 87 (0x57) 69 (0x45) 61 (0x3D)

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

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

プレーンテキストからbase64へのエンコードを段階的に視覚化するインタラクティブツールもあります。[7]

出力パディング

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

入力 出力 パディング
文章 長さ 文章 長さ
作業 11 bGlnaHQg d29y ay4= 16 1
作業 10 bGlnaHQg d29y aw== 16 2
作業 9 bGlnaHQg 29年 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 29年 なし 3 作業

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

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

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

長さ エンコード 長さ 解読
2 bGlnaHQg dw 1 ライトw
3 bGlnaHQg d28 2 ライト
4 bGlnaHQg 29年 3 作業

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

実装と歴史

バリアント概要表

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

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

プライバシー強化メール

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

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% ( 43 × 7876 ) ですが、非常に短いメッセージの場合は、ヘッダーのオーバーヘッドによりオーバーヘッドがはるかに高くなる可能性があります。大まかに言うと、Base64 エンコードされたバイナリ データの最終的なサイズは、元のデータ サイズの 1.37 倍 + 814 バイト (ヘッダー用) に等しくなります。デコードされたデータのサイズは、次の式で概算できます。

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

UTF-7

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

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

オープンPGP

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

RFC 3548

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

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

RFC 4648

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

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

URL アプリケーション

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です。[13]一部のバリアントでは、フィールド区切り文字と混同されないようにパディング ' ' 記号を省略することが許可または要求されるか、そのようなパディングはパーセントエンコードされる必要があります。一部のライブラリ[ which? ]は' ' を ' ' にエンコードするため、フォルダー名がユーザー データからエンコードされるときに、アプリケーションが相対パス攻撃にさらされる可能性があります。[引用が必要]+/-_==.

Javascript (DOM Web API)

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

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

Base64でエンコードされたJPEG画像が埋め込まれたSVGファイルの例[15]

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

RFC 4648 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を使用します。[18]
    • bcryptハッシュは従来のcrypt(3)ハッシュと同じように使用できるように設計されていますが、bcryptのアルファベットの順序はcryptのものと異なります。bcryptはアルファベット./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789を使用します。 [19]
    • Xxencoding は、 crypt に似た主に英数字の文字セットを使用しますが、andではなく+and。Xxencoding はアルファベット" "を使用します。-./+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
    • 一部の端末ノードコントローラで使用される6PACKは、0x00から0x3fまでのアルファベットを使用します。[20]
    • BashはBase64の数値リテラルをサポートしています。Bashはアルファベット0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_を使用します。 [21]

参照

参考文献

  1. ^ 「Base64 エンコードとデコード - Web API」。MDN Web Docs。2014 年 11 月 11 日時点のオリジナルよりアーカイブ。
  2. ^ 「画像をbase64でエンコードする場合(およびそうでない場合)」。2011年8月28日。2023年8月29日時点のオリジナルよりアーカイブ。
  3. ^ ab Base16、Base32、および Base64 データエンコーディング。IETF。200610 月。doi : 10.17487 /RFC4648。RFC 4648。2010318 日閲覧
  4. ^ ab インターネット電子メールのプライバシー強化: パート I: メッセージの暗号化と認証手順。IETF。19932月。doi : 10.17487 /RFC1421。RFC 1421。20103月 18 日に取得
  5. ^ ab多目的インターネットメール拡張: (MIME) パート 1 :インターネット メッセージ本文の形式。IETF。199611 月。doi : 10.17487/RFC2045。RFC 2045。20103月 18閲覧
  6. ^ ab Base16、Base32、および Base64 データエンコーディング。IETF。20037 月。doi : 10.17487/RFC3548。RFC 3548。2010318閲覧
  7. ^ 「エンコードを視覚化するインタラクティブツール」。base64decode.tech
  8. ^ Chalkias, Konstantinos; Chatzigiannis, Panagiotis (2022年5月30日). Base64の柔軟性の実践(PDF) . ASIA CCS '22: 2022 ACM on Asia Conference on Computer and Communications Security. pp. 1219–1221. doi :10.1145/3488932.3527284.
  9. ^ インターネット電子メールのプライバシー強化。IETF 1987年2月。doi : 10.17487/RFC0989。RFC 989。20103月18日閲覧
  10. ^ UTF-7 Unicodeのメールセーフ変換フォーマット。IETF。1994年7月。doi : 10.17487/RFC1642。RFC 1642。20103月18閲覧
  11. ^ UTF-7 Unicodeのメールセーフ変換フォーマット。IETF。1997年5月。doi : 10.17487/RFC2152。RFC 2152。20103月18日閲覧
  12. ^ OpenPGP メッセージフォーマット。IETF。2007年 11 月。doi : 10.17487/RFC4880。RFC 4880。20103月 18閲覧
  13. ^ 「YouTube で固有の動画 ID が実質的になくなることがない理由」www.mentalfloss.com 2016 年 3 月 23 日2021 年12 月 27 日閲覧
  14. ^ 「7.3. Base64 ユーティリティメソッド」。HTML 5.2 編集者草案ワールドワイドウェブコンソーシアム。20181 月 2 日閲覧2021-02-01 の変更セット 5814 によって導入されました。
  15. ^ <image xlink:href="data:image/jpeg;base64, JPEG contents encoded in Base64" ... />
  16. ^ 「PDF (Portable Document Format) ファイル (.pdf) を Base64 データにエンコードする」。base64.online。20243 月 21 日閲覧
  17. ^ 「フィドルを編集」. jsfiddle.net .
  18. ^ 「GEDCOM 標準リリース 5.5」。Homepages.rootsweb.ancestry.com。2012年 6 月 21 日閲覧
  19. ^ Provos, Niels (1997-02-13). 「src/lib/libc/crypt/bcrypt.c r1.1」2018年5月18日閲覧。
  20. ^ 「6PACK は PC から TNC への「リアルタイム」プロトコルです」。2012 年 2 月 24 日時点のオリジナルよりアーカイブ。2013 年 5 月 19 日閲覧
  21. ^ 「シェルの算術演算」。Bashリファレンス マニュアル。20204 月 8 日取得それ以外の場合、数値は [base#]n の形式になります。オプションの base は算術基数を表す 2 から 64 までの 10 進数で、n はその基数の数値です。
「https://en.wikipedia.org/w/index.php?title=Base64&oldid=1251168104」から取得