仕様書

構文

[2] 旧来の Macintosh のファイル・システムでは、 ファイルは、他の多くのファイル・システムにおけるファイルに相当する部分と、 そのファイルに関するメタ情報の部分で構成されます。 そのファイルの情報交換の際には、 どの程度他の環境との相互運用性に配慮するかで、 幾つかの方法が考慮されました。その方法の一つが AppleDouble で、 AppleDouble を MIME で使用するための媒体型が multipart/appledouble です。

AppleDouble 第2版 [APPL90] では、データは頭部 (header) とデータ・フォーク (data fork) の2つで 構成されています。 multipart/appledouble は他の multipart/* 媒体型群と同じ構造で、 最初の部分に頭部を application/applefile として, 2番目の部分にデータ・フォークをその実媒体型 (text/plain, image/jpeg など) にします。

[APPL90]

AppleSingle/AppleDouble Formats for Foreign Files Developer's Note, Apple Computer, Inc., 1990

AppleDouble 形式については RFC 1740 に説明があります。

[3] IANAREG は未だに RFC 1740 の原案を参照しています >>9。 しかし multipart/appledouble に関しては、 幸い大して違いはありません。

引数

[4]

[5] name 引数は、 application/octet-stream などでも規定されていますが、 Content-Disposition の filename 引数が定義されてからはそちらを使うことが望ましいとされています。 multipart/appledouble でもそうでしょう。

[6] x-mac-creator, x-mac-type 両引数については、 application/applefile 媒体型の説明を参照。

例

[7] >>11

Content-Type: multipart/appledouble; boundary=mac-part

--mac-part
Content-Type: application/applefile; name="My-new-car"

[The AppleDouble header goes here]

--mac-part
Content-Type: image/png;

[The data fork goes here]

--mac-part--

[8] name パラメーターは application/applefile ではなく multipart/appledouble につけたほうが適当ではないでしょうか。

実装を見てると、 appledouble と実際の body にファイル名をつけて、 applefile にはつけないのが流行ってるみたい。新しい実装も それに倣うのが良いでしょう。 (ファイル名は CT: の name パラメーターと、 CD: の filename パラメーターの両者につける。 でも今時 CD: に対応していない UA ってあるのかな?)

もち、name パラメーターが定義されていない媒体型の CT: にむやみに name パラメーターを書くべきじゃありませぬ。

メモ

[10] application/applefile は後に回した方が、 MIME 未対応の UA でも読めないデータを見せられる確率が下がると思うのですが・・・。 (MIME の開発の時にはそういうことをよく気にしていたはずだったのでは。)