RFC2046 には External-Body という形式がある。添付ファイルを別の場所に分離して保存する方法を規定したものだ。
自分でそういったフォーマットを作っても良いけど、可能な限り標準に準拠した形式にしておきたい。確か、私のやりたいことに適合した 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にはオリジナルのファイル名を記述するフィールドを規定していないようだ。そこで、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 に添付ファイルのデータを保存していることを表現できる。
- 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 についてのメモ。
以下、使用する文字。 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/+=
種類は (26 * 2) + 10 + 2 = 64。 あ、64種類だから Base64 なのか。= を入れたら65種類だけど。
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 ユーティリ ティによって使用したことを指定した。これらの資産を分配しないこと。そ して、メールのためのバイナリトランスポート符号化処理が満たさなければ ならないような可搬性の要求を満たしてはならない。
符号化プロセスは、4つの符号化された出力文字列が、入力ビットの24 ビットグループを表現している。左から右へ処理し24ビットの入力グルー プは、3つの8ビット入力グループのシーケンスにより形成される。
これらの24ビットは、4つの連結された6ビットグループ (各々がbase64 アルファベットにおける1桁の数字に変換される) のように、その時扱われ る。base64 符号化を経たビットストリームを符号化する時には、ビットの ストリームは、最初、最も多く重要なビットによって命じられると推定され なければなりません。すなわち、流れの最初のビットは、高いオーダービッ トの最初の8ビットバイトであり、8番目のビットは、低いオーダービットの 最初の8ビットバイトなどである。
各6ビットグループは、一連の64個の印刷可能な文字へのインデックス として使われる。インデックスによって参照を付けられた文字は、出力文字 列に配置される。下記表1に示したこれらの文字は、一般的に再提供可能な ように選択されて、セットは、特有の意味によって、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文字しかない行で表されなけ ればならない。すべての改行、または表1に発見されなかった他の文字は、 ソフトウェアで解読する際に無視されなければならない。base64 において、 データ、表1以外のキャラクタ、改行、及び、他の空白文字は、おそらく伝 送エラー(警告メッセージ、またはメッセージ拒絶さえも、いくらかの情況 下に於いては適切だろう)を示す。
もし最大24ビットで符号化されたデータの終りに利用可能であるなら、 特別な処理が行われる。完全なエンコーディング量は、ボディの終りで常に 完成される。最大24入力ビットが入力グループにおいて利用可能であると き、ゼロのビットは、必須の数の6ビットグループを形成するために加え られる(右に)。データの終りのパディング(穴埋め)は、"=" 文字を用いて行 われる。全ての base64 入力が必須の数のオクテットであるので、次の場合 のみが起こるかもしれない: (1)入力を符号化することの最終の量は、24ビ ットの必須の倍数である; ここで、符号化された出力の最終のユニットは、 "=" パディングなしの4文字の必須の倍数であろう。(2)入力を符号化する ことの最終の量は、ちょうど8ビットである; ここで、符号化された出力の 最終ユニットは、2個の "=" パディング文字が続いている2文字であろう。 もしくは (3)入力を符号化することの最終の量は、ちょうど16ビットであ る; ここで、符号化された出力の最終のユニットは、1個の "=" パディング 文字が続いている3文字であろう。
それがデータの終りの穴埋めにのみ使われるので、あらゆる "=" キャラ クタの発生は、データの終りに到達した (通過における切頭なしで) という 証拠として考えられるだろう。しかし、違う。送られたオクテット数が3の 倍数であり、どの "=" 文字も無い時には、そのような保証が可能である。
base64 アルファベット以外のあらゆる文字は、base64 符号化されたデー タにおいては無視されねばならない。
base64 符号化が直接正規のフォームに変換されなかったテクスト材料に 適用されるならば、改行に適したオクテットを使うために注意が行われなけ ればならない。特に、テクスト改行は、base64 符号化の前に CRLF シーケ ンスに変換されていなければならない。重要な注意点として、これがいくら かの実装(インプリメント)における前の正規化ステップにおいてより、むし ろ直接符号化処理(エンコーダ)によって行われるかもしれないことである。
注意事項: 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 ユーティリ ティによって使用したことを指定した。これらの資産を分配しないこと。そ して、メールのためのバイナリトランスポート符号化処理が満たさなければ ならないような可搬性の要求を満たしてはならない。
符号化プロセスは、4つの符号化された出力文字列が、入力ビットの24 ビットグループを表現している。左から右へ処理し24ビットの入力グルー プは、3つの8ビット入力グループのシーケンスにより形成される。
これらの24ビットは、4つの連結された6ビットグループ (各々がbase64 アルファベットにおける1桁の数字に変換される) のように、その時扱われ る。base64 符号化を経たビットストリームを符号化する時には、ビットの ストリームは、最初、最も多く重要なビットによって命じられると推定され なければなりません。すなわち、流れの最初のビットは、高いオーダービッ トの最初の8ビットバイトであり、8番目のビットは、低いオーダービットの 最初の8ビットバイトなどである。
各6ビットグループは、一連の64個の印刷可能な文字へのインデックス として使われる。インデックスによって参照を付けられた文字は、出力文字 列に配置される。下記表1に示したこれらの文字は、一般的に再提供可能な ように選択されて、セットは、特有の意味によって、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文字しかない行で表されなけ ればならない。すべての改行、または表1に発見されなかった他の文字は、 ソフトウェアで解読する際に無視されなければならない。base64 において、 データ、表1以外のキャラクタ、改行、及び、他の空白文字は、おそらく伝 送エラー(警告メッセージ、またはメッセージ拒絶さえも、いくらかの情況 下に於いては適切だろう)を示す。
もし最大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
〜が期待される EXPECTED
〜が推奨される RECOMMENDED
〜かもしれない MIGHT, MAY(稀)
〜してはならない MUST NOT, CANNOT
〜しても良い CAN, MAY(稀)
〜すべきである SHOULD
〜すべきでない SHOULD NOT
〜せねばならない MUST
〜できる CAN
付随的な・任意の・オプションの OPTIONAL
〜求められる・〜要求される REQUIRED
〜許されない NOT ALLOWED, NOT PERMITTED
〜許される ALLOWED, PERMITTED
