RFC

RFC2046 には External-Body という形式がある。添付ファイルを別の場所に分離して保存する方法を規定したものだ。

- RFC2046の External-Body

とあるプログラムを作成中。このプログラムは、データを MIME 互換形式で保存する。データには添付ファイルのようなものも含まれる。個数は可変。MIME の multipart/mixed を使えば添付ファイルのデータをメインのデータに含めることができるが、それはしたくない。添付ファイルのデータは別のファイルに保存したい。

自分でそういったフォーマットを作っても良いけど、可能な限り標準に準拠した形式にしておきたい。確か、私のやりたいことに適合した MIME タイプがあったはず。探してみよう。

rfc2046(jp) Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types メディアタイプ
http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc2046j.ht ...

あった。RFC 2046 の 5.2.3. 外部ボディ（External-Body）サブタイプだ。これを使えばいいのか。

- RFC2046の External-Body のサンプル

RFC2046を読みながらサンプルを書いた。Content-Type が二回出てくるのが新鮮な感じ。

RFC2046にはオリジナルのファイル名を記述するフィールドを規定していないようだ。そこで、X-Original-File-Name というヘッダを付け、Base64 でエンコードしたオリジナルのファイル名を記述するようにした。

Content-Type の name は相対パスで記述。良くないかもしれないけど。あと、システムは Windows なのでディレクトリ区切り文字は \ を使った。これも微妙かも。

--------------050807090903030402050103
Content-Type: message/external-body;
              access-type=local-file;
              name="attachment\00080386.dat";
              size=80386

Content-Type: application/octet-stream
Content-ID: BAa2YGktNCKZnJlLHg0NKlpaU9ov
X-Original-File-Name: Base64_ENCODED_FILE_NAME


--------------050807090903030402050103

このようにして、attachment\00080386.dat に添付ファイルのデータを保存していることを表現できる。

バイナリデータをテキストデータ化する時によく使われる 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符号化ボディ中の潜在的な境界デリミタについ
  て悩む必要はない。

http://www.aurora.dti.ne.jp/~zom/mng/mng_spec.html より。
〜が期待される EXPECTED
〜が推奨される RECOMMENDED
〜かもしれない MIGHT, MAY(稀)
〜してはならない MUST NOT, CANNOT
〜しても良い CAN, MAY(稀)
〜すべきである SHOULD
〜すべきでない SHOULD NOT
〜せねばならない MUST
〜できる CAN
付随的な・任意の・オプションの OPTIONAL
〜求められる・〜要求される REQUIRED
〜許されない NOT ALLOWED, NOT PERMITTED
〜許される ALLOWED, PERMITTED