RFC2045 Base64 で使用する文字の種類

バイナリデータをテキストデータ化する時によく使われる Base64 についてのメモ。

- Base64 で使用する文字の種類

大文字と小文字の両方のアルファベットと、0から9までのアラビア数字、/ スラッシュと + プラス記号を主に使う。 = イコールは一行の文字数が足りないときのパディング(詰め物)として使う。

以下、使用する文字。

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/+=

種類は (26 * 2) + 10 + 2 = 64。
あ、64種類だから Base64 なのか。= を入れたら 65種類だけど。

- Base64 エンコード後のサイズ

英数字と記号だけで表現しようとするため、Base64エンコード後のデータのサイズは、エンコード前のデータに比べて 3分の4倍、すなわち 約133%に増大する。

- Base64 についての RFC

Base64 について言及した RFC は、RFC 3548が最新の模様。

RFC 3548
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?RFC%203548
一部日本語訳がある。

今となっては RFC 3548を参照する方が良いと思うけど、メモ。

RFC 2045 の 6.8 Base64 Content-Transfer-Encoding
http://www.akanko.net/marimo/data/rfc/rfc2045-jp.txt

6.8.  Base64 Content-Transfer-Encoding

    Base64 Content-Transfer-Encoding は、人間的に読みやすい必要のない
  フォームにおいてオクテットの任意のシーケンスを表すように設計されてい
  る。符号化と解読のアルゴリズムは簡単である。しかし符号化されたデータ
  は符号化されないデータよりほんの僅か、約33%大きくなる。RFC 1421 にお
  いて定義されたように、この符号化は、実質的に Privacy Enhanced Mail
  (PEM) アプリケーションに使われるものと同じである。

    US-ASCII のサブセットの 65文字を使い、6ビットが印刷できるキャラク
  タとして表すことを可能とする（余分の第65のキャラクタ "=" は、特別な
  機能処理を意味するために使われる）。

    注意事項:
      このサブセットは、それが全く同じに ISO 646 (US-ASCII を含む)
  の全てのバージョンの代表を務める重要なプロパティを持っており、そして
  サブセットにおける全てのキャラクタは、 EBCDIC の全てのバージョンにお
  いても全く同じく表される。マッキントッシュ binhex 4.0 [RFC-1741] 、
  及び base85 符号化は、Level 2 ポストスクリプトの一部として、
  エンコーディングのような他のポピュラーな符号化が uuencode ユーティリ
  ティによって使用したことを指定した。これらの資産を分配しないこと。そ
  して、メールのためのバイナリトランスポート符号化処理が満たさなければ
  ならないような可搬性の要求を満たしてはならない。

    符号化プロセスは、４つの符号化された出力文字列が、入力ビットの２４
  ビットグループを表現している。左から右へ処理し２４ビットの入力グルー
  プは、３つの８ビット入力グループのシーケンスにより形成される。

    これらの 24ビットは、4つの連結された 6ビットグループ (各々がbase64
  アルファベットにおける 1桁の数字に変換される) のように、その時扱われ
  る。base64 符号化を経たビットストリームを符号化する時には、ビットの
  ストリームは、最初、最も多く重要なビットによって命じられると推定され
  なければなりません。すなわち、流れの最初のビットは、高いオーダービッ
  トの最初の8ビットバイトであり、8番目のビットは、低いオーダービットの
  最初の8ビットバイトなどである。

    各 6ビットグループは、一連の 64個の印刷可能な文字へのインデックス
  として使われる。インデックスによって参照を付けられた文字は、出力文字
  列に配置される。下記表１に示したこれらの文字は、一般的に再提供可能な
  ように選択されて、セットは、特有の意味によって、RFC 2046において定義
  されたSMTP（例えば、"."、CR、LF）およびマルチパートの境界デリミタの
  文字を遮断する（例えば "-"）。


                    表１: Base64 アルファベット

        値 符号化      値 符号化      値 符号化      値 符号化
        0 A            17 R            34 i            51 z
        1 B            18 S            35 j            52 0
        2 C            19 T            36 k            53 1
        3 D            20 U            37 l            54 2
        4 E            21 V            38 m            55 3
        5 F            22 W            39 n            56 4
        6 G            23 X            40 o            57 5
        7 H            24 Y            41 p            58 6
        8 I            25 Z            42 q            59 7
        9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w      (穴埋め) =
        15 P            32 g            49 x
        16 Q            33 h            50 y


    符号化された出力ストリームは、わずか 76文字しかない行で表されなけ
  ればならない。すべての改行、または表１に発見されなかった他の文字は、
  ソフトウェアで解読する際に無視されなければならない。base64 において、
  データ、表１以外のキャラクタ、改行、及び、他の空白文字は、おそらく伝
  送エラー(警告メッセージ、またはメッセージ拒絶さえも、いくらかの情況
  下に於いては適切だろう)を示す。

    もし最大 24ビットで符号化されたデータの終りに利用可能であるなら、
  特別な処理が行われる。完全なエンコーディング量は、ボディの終りで常に
  完成される。最大 24 入力ビットが入力グループにおいて利用可能であると
  き、ゼロのビットは、必須の数の 6 ビットグループを形成するために加え
  られる(右に)。データの終りのパディング(穴埋め)は、"=" 文字を用いて行
  われる。全ての base64 入力が必須の数のオクテットであるので、次の場合
  のみが起こるかもしれない: (1)入力を符号化することの最終の量は、24ビ
  ットの必須の倍数である; ここで、符号化された出力の最終のユニットは、
  "=" パディングなしの 4文字の必須の倍数であろう。(2)入力を符号化する
  ことの最終の量は、ちょうど 8ビットである; ここで、符号化された出力の
  最終ユニットは、2個の "=" パディング文字が続いている 2文字であろう。
  もしくは (3)入力を符号化することの最終の量は、ちょうど 16ビットであ
  る; ここで、符号化された出力の最終のユニットは、1個の "=" パディング
  文字が続いている 3文字であろう。

    それがデータの終りの穴埋めにのみ使われるので、あらゆる "=" キャラ
  クタの発生は、データの終りに到達した (通過における切頭なしで) という
  証拠として考えられるだろう。しかし、違う。送られたオクテット数が 3の
  倍数であり、どの "=" 文字も無い時には、そのような保証が可能である。

    base64 アルファベット以外のあらゆる文字は、base64 符号化されたデー
  タにおいては無視されねばならない。

    base64 符号化が直接正規のフォームに変換されなかったテクスト材料に
  適用されるならば、改行に適したオクテットを使うために注意が行われなけ
  ればならない。特に、テクスト改行は、base64 符号化の前に CRLF シーケ
  ンスに変換されていなければならない。重要な注意点として、これがいくら
  かの実装(インプリメント)における前の正規化ステップにおいてより、むし
  ろ直接符号化処理(エンコーダ)によって行われるかもしれないことである。

  注意事項:
    base64 符号化の時にハイフン文字は全く使われないので、マルチパート
  なエンティティ内の base64符号化ボディ中の潜在的な境界デリミタについ
  て悩む必要はない。