本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。
(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)
[7] AppleSingle 第2版 [APPL90] は、そのものを application/applefile (最初の4オクテットは 00, 05, 16, 00 になる。) にします。
AppleDouble 第2版 [APPL90] では、データは頭 header とデータ・フォーク data fork の2つで 構成されてます。このうち頭を application/applefile (最初の4オクテットは 00, 05, 16, 07 になる。), データ・フォークをその実媒体型にします。 で、その2つを multipart/appledouble で包みます。
形式については RFC 1740 に説明があります。
| name | mime.value | ファイル名。 |
| type | mime.value | 内容の型の説明。 (人間可読文) |
| x-mac-creator | 8HEXDIGIT | creator |
| x-mac-type | 8HEXDIGIT | 型 |
AppleSingle にはファイル名も型も含まれていますが、 受信者の便宜のためにパラメーターで指定できます。 RFC 1740 で定義しているのは name のみですが、 その原案では type も定義されていました。 現在の IANA 登録簿は未だにその原案を参照しています。
便宜上、 Macintosh file type と creator を取り出して、 それぞれ各オクテットを大文字16進数にしてそのままの順で 並べているようです。 x-mac-type="54455854" みたいに。
multipart/appledouble では、 appledouble とその内部の application/applefile の双方にこれらのパラメーターを つけるよーです。
上手く取得できなかったときに "00000000" にする UA があるみたい。
これは意外と結構使われているらしい。
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--
application/applefile って使われてるのは全く見かけませんね。まあ確かに、一般の情報交換では決して使用するべき型ではないですねapplication/x-macbinary って媒体型を使う人がいるらしいけど、これの中身は application/applefile と同じと考えていいんだろうか?