974.txt

[1] [CODE[multipart/*]] [[媒体型]]は、 [[MIME]] が汎用的に定義した、
単一メッセージ中に複数の部分 (実体) を含める方法です。
すべての亜型が同じ構造をしていますから、各型の自由度は低まりますが、対応していない[[利用者エージェント]]であっても、とりあえず
multipart/mixed 媒体型として最低限の解釈は可能になります。

* 仕様書

[REFS[
- [30] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-3>
- [34] '''[CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-5.1>'''
- [25] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) <http://tools.ietf.org/html/rfc2183#section-2.9>
- [31] [CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]] ([TIME[2015-02-11 00:35:08 +09:00]] 版) <http://tools.ietf.org/html/rfc6838#section-4.2.6>
- [211] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-3.1.1.4>
]REFS]

* [CODE(MIME)@en[multipart/*]] MIME 型の一覧

[15]
,[[媒体型]],説明,状態,出典
,[[multipart/alternative]]	,選択肢群	,[MIME]
,[[multipart/appledouble]]	,Macintosh 書類	,[MacMIME]
,[[multipart/byteranges]]	,部分塊	,[[HTTP]]
,[[multipart/x-byteranges]]	,部分塊	,HTTP 原案
,[[multipart/digest]]	,要約版メッセージ群	,[MIME]
,[[multipart/encrypted]]	,暗号化メッセージ	,[RFC1847]
,[CODE(MIME)@en[[[multipart/example]]]],,"[[IETF]] [[RFC]], [[IANA]] 登録済","[[RFC]], [IANAREG]"
,[CODE(MIME)@en[[[multipart/foo]]]]
,[[multipart/form-data]]	,FORM 送信	,[RFC2388]
,[CODE(MIME)@en[[[multipart/gedi-record]]]],[[GEDI]],"[[IANA]] ''未''登録, [[ISO]] [[標準]]"
,[[multipart/header-set]]	,ファイル系統物体	,[IANAREG]
,[CODE(MIME)@en[[[multipart/x-mimepgp]]]]	,
,[CODE(MIME)@en[[[multipart/mixed]]]]
,[CODE(MIME)@en[[[multipart/x-mixed-replace]]]]
,[CODE(MIME)@en[[[multipart/x-multi-encrypted]]]]
,[CODE(MIME)@en[[[multipart/multilingual]]]]
,[[multipart/parallel]]	,同時再生	,[MIME]
,[[multipart/related]]	,関連束	,[RFC2387]
,[[multipart/report]]	,配送報告	,[RFC1892]
,[CODE(MIME)[[[multipart/dvb.service]]]]	,Multipart DVB Services	,非標準	,[MHP 1.1]
,[CODE(MIME)[[[multipart/x-sgml]]]]	,[[SGML]] 実体群
,[[multipart/signed]]	,署名メッセージ	,[RFC1847]
,[[multipart/voice-message]]	,音声メッセージ	,[RFC2421] [RFC2423]
,[CODE(MIME)@en[[[multipart/x-www-form-data]]]],[[フォーム・データ集合]],"時代遅れ → [CODE(MIME)@en[[[multipart/form-data]]]]",[[Emacs/W3]]

- [[IANA]] 登録簿 <http://www.iana.org/assignments/media-types/multipart/>

* 意味

[33] [CODE(MIME)@en[[[multipart/*]]]] は、
独立したデータ型の複数の[[実体]]で構成されるデータを表します [SRC[>>30]]。

[FIG(flow)[
:entity:[[実体]]
:v:
:->:entity
]FIG]

* 構文

[32] [CODE(MIME)@en[[[multipart/*]]]] [[MIME型]]は、 [[RFC 2046]] の構文その他の制限に適合しなければ[['''なりません''']] [SRC[>>34, >>31]]。

;; [36] すべての[[部分型]]が同じ構文となっています。これは未知の[[MIME型]]であっても、
すべての[[利用者エージェント]]が解釈できるようにするためです [SRC[>>34]]。

[35] [CODE(MIME)@en[[[multipart/*]]]] の[[本体]]は1つ[[以上]]の[[本体部分]]で構成されます。
[[本体部分]]の前には[[境界区切子行]]があり、
最後には[[閉じ境界区切子行]]があります。 [SRC[>>34]]

[FIG(railroad)[
= ?
== [[前書き]]
= +
== [[境界区切子行]]
== [[本体部分]]
= [[閉じ境界区切子行]]
= ?
== [[後書き]]
]FIG]

[50] [[本体部分]]が1つだけでも有用な場合はあるため、認められています [SRC[>>34]]。

[EG[
[52] [[MIME]] に対応していない[[受信者]]にテキストでないデータを送りたい時に、
[[復号]]方法の指示を[[前書き]]に含められます [SRC[>>34]]。
]EG]

[EG[
[53] [[MIME]] に対応していない[[関門]]が [CODE(MIME)@en[[[Content-Type:]]]]
[[ヘッダー]]を落としてしまっても、[[境界区切子]]を推測して復元できます [SRC[>>34]]。
]EG]

;; [51] 1つもないものは認められていないようです。

[57] [[本体部分]]の順序に意味があるかどうかは、[[MIME型]]に依存します。

** 改行

[8] HTTP は [CODE(MIME)[[[text/*]]]] については MIME とは違って
[[CRLF]] への正規化を要求していません。しかし、 [CODE(MIME)[multipart/*]]
の改行は MIME と同じで CRLF でなければなりません [SRC[>>211]]。

この点は RFC 1945 からしっかり明記されています。

** 前書き

[6] 最初の[[境界文字列]]の前には[[境界文字列]]以外の任意の [[ASCII文字]]の列を記述できます。
これを[[前書き]]といいます。その場合[[前書き]]の後に [[CRLF]]
が必要です。

;; [10] 前書きが空の場合、 [[CRLF]] なしで最初が[[境界文字列]]の [CODE[--]]
となります。

[18] [[前書き]]は、 [[MIME]] 未対応の[[利用者エージェント]]で表示される (人間向けの)
メッセージとして使うことを意図したものです。[[前書き]]が含まれる場合、
多くの場合は [[MUA]] によって自動生成される「[[MIME]] 対応 [[MUA]] で開いてください」
のような文言です。

[19] [[HTTP]] では[[前書き]]は使わないのが普通です。

[43] [RUBYB[[[前書き]]]@en[preamble]]は、通常は空としておくべきです [SRC[>>34]]。

;; [46] しかし多くの [[MIME]] の実装は、[[MIME]] 未対応のソフトウェアに対するメッセージを含める場所として使っています [SRC[>>34]]。

[44] 実装は、[[前書き]]を無視しなければなりません [SRC[>>34]]。

;; [45] [[前書き]]には[[型]]を付けることができませんし、
[[関門]]での扱いが明確ではありませんから、通常は使いません [SRC[>>34]]。

** 境界文字列

[20] [CODE(MIME)@en[[[boundary]]]] [[引数]]の項を参照。

** 後書き

[220] MIME の規定では、最後の本体部分の終わりの境界の後に任意の (US-ASCII) 文字列を入れることができます。
その部分は MIME UA には無視されます。
この部分のことを[DFN[[[後書き]]]]といいます。

[224] [[HTTP]] では、 [[RFC 2616]] までは[[後書き]]を禁止していました。
しかしこの規定は [[RFC 7230]]/[[RFC 7231]] では無くなっています。

[225] [[RFC 2616]] までは、本来 [CODE(HTTP)@en[[[Content-Length:]]]]
[[ヘッダー]]が必要な場合でも [CODE(MIME)[[[multipart/byteranges]]]] 
を使っていれば省略してもいいことになっていました。
これは本体部分の最後の境界で終わりを示せるからです。
ところが後書きがあるとこの仮定が崩れます。
だから禁止しているのです。
しかしこの規定も [[RFC 7230]]/[[RFC 7231]] では無くなっています [SRC[>>211]]。

;; [[メッセージ本体]]の項も参照してください。

[47] [RUBYB[[[後書き]]]@en[epilogue]]は、通常は空としておくべきです [SRC[>>34]]。

[48] 実装は、[[後書き]]を無視しなければなりません [SRC[>>34]]。

;; [45] [[後書き]]には[[型]]を付けることができませんし、
[[関門]]での扱いが明確ではありませんから、通常は使いません [SRC[>>34]]。

* 引数

[39] 次の[[引数]]があります。
[FIG(short list)[
- [CODE(MIME)@en[[[boundary]]]]
]FIG]

[42] [CODE(MIME)@en[[[boundary]]]] [[引数]]は、必須です [SRC[>>34]]。

[41] [[部分型]]によっては、他にも[[引数]]があるかもしれません。

* 本体部分

[5] [CODE(MIME)@en[[[multipart/*]]]] に含まれる[[実体]]のことを、
[[本体部分]]といいます。

;; [4] 詳しくは[[本体部分]]の項を参照。

[49] [CODE(MIME)@en[[[multipart/*]]]] 内で入れ子に [CODE(MIME)@en[[[multipart/*]]]]
を使うこともできます [SRC[>>34]]。

* 処理

[54] 不正な [CODE(MIME)@en[[[multipart/*]]]] が入れ子に含まれている場合に備えて、
内側の[[本体部分]]の処理中も、外側の[[境界区切子]]をも[[走査]]する必要があります [SRC[>>34]]。

[55] 認識できない [CODE(MIME)@en[[[multipart/*]]]] は、
[CODE(MIME)@en[[[multipart/mixed]]]] として扱わなければなりません [SRC[>>34]]。

;; [56] [[MIME]] は [CODE(MIME)@en[[[multipart/mixed]]]] への対応を求めており、
それが実装されないことは想定していないようです。 [[Web]] では
[CODE(MIME)@en[[[multipart/mixed]]]] に対応することは稀で、
いずれも[[ダウンロード]]として扱われます。

* [CODE(MIME)@en[Content-Disposition:]] ヘッダーとの関係

[26] [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] [[実体]] (個別の[[本体部分]]ではなく、
全体) に対して [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]が指定された場合、
それは全体に適用されます [SRC[>>25]]。

[27] 当該 [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] [[実体]]が[[表示]]されていない間は、
各[[本体部分]]に対する [CODE(MIME)@en[[[Content-Disposition:]]]] の指定も適用されません
[SRC[>>25]]。

[EG[
[28] 例えば [CODE(MIME)@en[[[multipart/*]]]] [[実体]]に
[CODE(MIME)@en[[[Content-Disposition: attachment]]]] が指定されている場合、
その [CODE(MIME)@en[[[multipart/*]]]] [[実体]]全体が[[利用者]]の指示があるまで[[表示]]されません。

[29] [[利用者]]の指示で表示する際、 [CODE(MIME)@en[[[Content-Disposition: inline]]]]
の[[実体本体]]と [CODE(MIME)@en[[[Content-Disposition: attachment]]]]
の[[実体本体]]がその中に含まれていれば、前者は自動的に表示し、
後者は更に[[利用者]]の指示があるまで表示しません。
]EG]

* HTTP における [CODE(MIME)@en[multipart/*]]

[22] HTTP での [CODE(MIME)[[[multipart/*]]]] 媒体型の使用について。

[23] [[MIME]] で複数の[[実体]]を一つの[[メッセージ]]に詰め込むために用意されている
[CODE(MIME)[multipart/[VAR[*]]]] 型は、 [[HTTP]] でも使うことがあります。

しかしながら、実際には使えるとも使えないともいえない中途半端な状態で実装されています。

[3] HTTP RFC は [CODE[multipart/*]] 媒体型が HTTP でも使えると言っているものの、対応している実装はそうないと思われます。せいぜい、
[[multipart/x-mixed-replace]] と、 [[HTML]] [[form]]
送信用の [[multipart/form-data]], [[multipart/mixed]] 位ではないでしょうか。
- [7] HTTP は [[Content-Transfer-Encoding:]] 欄がないとか [[Content-Encoding:]] 欄があるとか [[MIME]] と異なる点が幾つかあるわけですが、これが複数部分についてどう適用されるのか、 [[RFC2616]] を読むと MIME と同じ、すなわち CTE: binary の記述が必須とか、 CE: は使えないとか、そう読めますが、後者はともかく前者は実情に合いませんよね。
- [8] >>3 [[multipart/byteranges]] を忘れていた。
- [9] >>19 [[RFC2616]] では該当する記述が削除されている。 [[Base:]] 欄が実質廃止されたのとかも関係するのかな。つまり、 MIME との協調のためにそういうのは止めていこうという方向?

[16] HTTP 応用では、幾つかの亜型は対応している実装がかなりありますが、
全体としてはほとんど無視している状態です。 MIME でも HTTP
でも、未対応の [CODE(MIME)[multipart/[VAR[*]]]] に出会ったら
[CODE(MIME)[[[multipart/mixed]]]] と同じに振舞うことになっていますが、
ほとんどの応用が [CODE(MIME)[multipart/mixed]] に対応していないのだからどうしようもありません。。。

[207] 
: [CODE(MIME)[[[multipart/form-data]]]] : [CODE(HTMLe)[[[form]]]] 要素などの[[フォーム]]からデータを送信する時に [CODE(HTTP)[[[POST]]]] 要求でよく使われる型です。
[[ファイルうp]]には必須とあって一気に普及しましたが、行き当たりばったりな実装ばかりで無難にやり過ごすとしたら最低限のこともできないかもしれません。[WEAK[まあ Web 関連規格は大体がそういう状態ですな。]]
: [CODE(MIME)[[[multipart/byteranges]]]] : [CODE(HTTP)[[[206]]]] 応答で内容全体ではなく内容の一部を複数個送るときに使います。
大方のサーバーと大方の [[WWWブラウザ]]や prefetcher が対応しています。
: [CODE(MIME)[[[multipart/x-byteranges]]]] : [CODE(MIME)[byterange]] の規格制定過程の古い形式で、今でも対応している WWW ブラウザもあります。
とはいえ歴史的なものでおそらく誰も使って無いでしょう。
: [CODE(MIME)[[[multipart/x-mixed-replace]]]] : [[プッシュ]]が流行り始めた時代に
[[NN]] が実装していました。成長し始めの[[コンテンツ業界]] (謎)
でも流行ったみたいで、それ系の掲示板 (謎) で最近までたまに話題に上がっていましたが、
これに対応していない [[WinIE]] の台頭とプッシュが廃れたのでもう死滅状態でしょうか。
[WEAK[ちなみに [[Gecko]] Mozilla は対応していません。]]
逐次レンダリングしないといけないという代物。
: [CODE(MIME)@en[[[multipart/related]]]] :
[[SOAP]] [[メッセージ]]を [[HTTP]] で送信する場合で、 [[SOAP]] [[メッセージ]]内に[[バイナリ・データ]]が含まれる時には、
[CODE(MIME)@en[[[multipart/related]]]] を使えることになっています。仕様上は。
実際使われているのかは謎です。そもそも [[SOAP]] 自体(ry

[208] これ以外の亜型に対応した実装はほとんどありません。

複数個の本体があるとどうレンダリングしたらいいか困っちゃいますからねぇ。
ブラウザとしては。[[フレーム]]と同じようにしたらどうよ? という気もしないでもないですが。

[209] 電子メイルを扱える WWW ブラウザだと、 [CODE(MIME)[multipart/[VAR[*]]]]
を直接扱えなくても HTTP 的には [CODE(MIME)[[[message/rfc822]]]]
で、その中に多部分がある感じにすれば、 (電子メイルを扱う時と同程度には)
表示できたりします。でもまあこんなの HTTP での多部分に対応しているとは言わんな。

[210] HTTP が MIME を採用していれば何も問題はなかったのですが、あいにく
HTTP は「MIME 的なもの」を含んでいるので、多部分を完全に MIME
的に取扱っても良いのか、はっきり書かれていないと困ってしまいます。

何も言っていないのは特に変更しないからだと判断して MIME
的に実装してしまうのももっともなのですが、
そうすると整合性の点で問題になっちゃうこともあるような気もします。

歴代仕様書を比較すると、最新の RFC 2616 は以前の RFC
より MIME との互換性に気を遣っているような感じです。

[24] [[OData]] は [[HTTP]] で [CODE(MIME)@en[[[multipart/mixed]]]]
を使っています。

* 内容転送符号化

[37] [CODE(MIME)@en[[[multipart/*]]]] の[[実体]]について、
[CODE(MIME)@en[[[7bit]]]]、[CODE(MIME)@en[[[8bit]]]]、
[CODE(MIME)@en[[[binary]]]] ''以外''を [CODE(MIME)@en[[[Content-Transfer-Encoding:]]]]
で使うことはできません [SRC[>>34]]。

;; [38] [[本体部分]]に [[CTE]] を使うことは可能です。

* バイナリー表現の試み

[2] MIME は電子メイルでの利用を念頭に設計しましたから、バイナリな転送プロトコル,
例えば HTTP では、境界の扱いなど無駄な部分があります。
そのため、 HTTP で分割転送のために 
[[multipart/byteranges]] [[媒体型]]を採用した時には、よりバイナリ指向な
multipart に代わる仕組みを導入しようという意見も強くありましたが、結局
MIME と互換性のある multipart 形式になりました。

[13]
[[HTTP]] の [CODE(MIME)[multipart/byteranges]]
のときにも、 [CODE(MIME)[multipart/[VAR[*]]]] は overhead が大きいから binary
にしようとか揉めましたが結局 MIME 互換の [CODE(MIME)[multipart/byteranges]] に落ち着きました。

[11] [[WSP]] は多部分型のバイナリ表現を規定しています。
(<http://www.openmobilealliance.org/wapdocs/wap-230-wsp-20010705-a.pdf> 8.5 参照。)

それに伴って定義されている媒体型:
,[CODE(MIME)[[[application/vnd.wap.multipart.alternative]]]]
,[CODE(MIME)[[[application/vnd.wap.multipart.byteranges]]]]
,[CODE(MIME)[[[application/vnd.wap.multipart.form-data]]]]
,[CODE(MIME)[[[application/vnd.wap.multipart.mixed]]]]

* 歴史

[FIG[
[FIGCAPTION[
[21] RFC 2046 5.1.  Multipart Media Type
]FIGCAPTION]

> In the case of multipart entities, in which one or more different
sets of data are combined in a single body, a "multipart" media type
field must appear in the entity's header.  The body must then contain
one or more body parts, each preceded by a boundary delimiter line,
and the last one followed by a closing boundary delimiter line.
After its boundary delimiter line, each body part then consists of a
header area, a blank line, and a body area.  Thus a body part is
similar to an RFC 822 message in syntax, but different in meaning.

一つの[[本体]]の中に1つ以上の異なるデータ集合が組み合わさっている
[[複数部分]][[実体]]の場合、
"multipart" 媒体型欄が実体の頭の中に出現しなければなりません。本体は一つ以上の[[本体]]部分から構成されていなければなりません。各本体部分には境界区切行が先にあって、最後のものは閉じ境界区切行が続きます。境界区切行の後では、各本体部分が頭欄,
空行, 本体領域から構成されます。このように本体部分は
RFC 822 メッセージと構文的には似ていますが、意味が異なります。

> A body part is an entity and hence is NOT to be interpreted as
actually being an RFC 822 message.  To begin with, NO header fields
are actually required in body parts.  A body part that starts with a
blank line, therefore, is allowed and is a body part for which all
default values are to be assumed.  In such a case, the absence of a
Content-Type header usually indicates that the corresponding body has
a content-type of "text/plain; charset=US-ASCII".

本体部分は一つの実体であり、従って実際には RFC 822
[[メッセージ]]であるように解釈しては'''いけません'''。まず、本体部分の中で本当に必須の頭欄は'''ありません'''。ですから、空白行で始まる本体部分は認められていて、この本体部分は全て既定値であると仮定されます。このような場合に、
Content-Type 頭が無いなら通常は、対応する本体は
"text/plain; charset=US-ASCII" の content-type
を持つことを示します。

[PRE[
   The only header fields that have defined meaning for body parts are
   those the names of which begin with "Content-".  All other header
   fields may be ignored in body parts.  Although they should generally
   be retained if at all possible, they may be discarded by gateways if
   necessary.  Such other fields are permitted to appear in body parts
   but must not be depended on.  "X-" fields may be created for
   experimental or private purposes, with the recognition that the
   information they contain may be lost at some gateways.
]PRE]

本文部分に対して意味が定義されている頭領域は "Content-" で始まる名前を
持つもののみです。他の全ての頭領域は本文部分では無視されます。
これは全然可能であるならば通常はそのままにしておくべきですが、
必要ならば関門により捨てられるかもしれません。このような他の領域
が本文部分に出現することは認められますが、それに依存してはいけません。
"X-" 領域を実験あるいは私的な目的で作成しても構いませんが、
そこに含まれる情報は関門で失われ得ることを認識している必要があります。

[PRE[
   NOTE:  The distinction between an RFC 822 message and a body part is
   subtle, but important.  A gateway between Internet and X.400 mail,
   for example, must be able to tell the difference between a body part
   that contains an image and a body part that contains an encapsulated
   message, the body of which is a JPEG image.  In order to represent
   the latter, the body part must have "Content-Type: message/rfc822",
   and its body (after the blank line) must be the encapsulated message,
   with its own "Content-Type: image/jpeg" header field.  The use of
   similar syntax facilitates the conversion of messages to body parts,
   and vice versa, but the distinction between the two must be
   understood by implementors.  (For the special case in which parts
   actually are messages, a "digest" subtype is also defined.)
]PRE]

RFC 822 メッセージと本文部分の区別はわずかですが、重要です。
例えば Internet と X.400 のメイル関門は、画像を含む本文部分と
本文が JPEG 画像のカプセル化メッセージが含まれている本文部分の違いを
知り得る必要があります。後者を表現するためには、本文部分に
"Content-Type: message/rfc822" をつけ、その本文 (空行の後)
に "" 頭領域を持ったカプセル化メッセージを入れなければなりません。
同様の構文を使うことでメッセージの本文部分への変換が促進されますし、
逆に実装者は2つの区別を理解しなければなりません。
(部分が実際メッセージである特別な場合のために、 "digest"
亜型も定義します。)

[PRE[
   As stated previously, each body part is preceded by a boundary
   delimiter line that contains the boundary delimiter.  The boundary
   delimiter MUST NOT appear inside any of the encapsulated parts, on a
   line by itself or as the prefix of any line.  This implies that it is
   crucial that the composing agent be able to choose and specify a
   unique boundary parameter value that does not contain the boundary
   parameter value of an enclosing multipart as a prefix.
]PRE]

前述のように、本文部分の前には境界区切りを含む境界区切行が来ます。
境界区切りは、カプセル化部分の内部で行そのものあるいは行の頭に
現れては'''なりません'''。ですから、構成代理者は、
囲んでいる多部分で boundary パラメーター値に接頭辞として含まれていない、
独特な boundary パラメーター値を選択・指定できます。

[PRE[
   All present and future subtypes of the "multipart" type must use an
   identical syntax.  Subtypes may differ in their semantics, and may
   impose additional restrictions on syntax, but must conform to the
   required syntax for the "multipart" type.  This requirement ensures
   that all conformant user agents will at least be able to recognize
   and separate the parts of any multipart entity, even those of an
   unrecognized subtype.
]PRE]

現在及び将来の全ての "multipart" の亜型は同じ構文を使用しなければなりません。
亜型はその意味において異なるでしょうし、構文に追加の制限を加えても
構いませんが、 "multipart" 型の要求構文に適合しなければなりません。
この要求事項があるので、全ての適合利用者代理者は、その亜型が認識出来ない
ものであっても、多部分実体の部分を少なくても認識・分離することが
出来るでしょう。

[PRE[
   As stated in the definition of the Content-Transfer-Encoding field
   [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is
   permitted for entities of type "multipart".  The "multipart" boundary
   delimiters and header fields are always represented as 7bit US-ASCII
   in any case (though the header fields may encode non-US-ASCII header
   text as per RFC 2047) and data within the body parts can be encoded
   on a part-by-part basis, with Content-Transfer-Encoding fields for
   each appropriate body part.
]PRE]

CTE 領域の定義で述べたように、 ... 以外の符号化は "multipart" 型の
実体には認められていません。 "multipart" 境界区切りと
頭領域は常にいかなる場合においても7ビット US-ASCII で (非 US-ASCII
頭文を RFC 2047 により符号化しても構いませんが。) 表現しなければ
なりません。また本文部文中のデータは、部分ごとに、
適切な各本文部分の CTE 領域をつけて符号化することが出来ます。

* 5.1.1.  Common Syntax

[PRE[
   This section defines a common syntax for subtypes of "multipart".
   All subtypes of "multipart" must use this syntax.  A simple example
   of a multipart message also appears in this section.  An example of a
   more complex multipart message is given in RFC 2049.
]PRE]

この節では "multipart" の亜型の共通の構文を定義します。
"Multipart" の全ての亜型はこの構文をつかわなければなりません。
多部分メッセージの単純な例もこの節に提示します。より複雑な多部分メッセージ
の例は RFC 2049 にあります。

[PRE[
   The Content-Type field for multipart entities requires one parameter,
   "boundary". The boundary delimiter line is then defined as a line
   consisting entirely of two hyphen characters ("-", decimal value 45)
   followed by the boundary parameter value from the Content-Type header
   field, optional linear whitespace, and a terminating CRLF.
]PRE]

多部分実体の CT 領域では、パラメーター "boundary" が必要です。
境界区切行は2つのハイフン文字 ("-", 10進値45) とそれに続けて
CT 頭領域から boundary パラメーター値, 省略可能な行空白間隔, 終端 CRLF
の全体から構成されます。

[PRE[
   NOTE:  The hyphens are for rough compatibility with the earlier RFC
   934 method of message encapsulation, and for ease of searching for
   the boundaries in some implementations.  However, it should be noted
   that multipart messages are NOT completely compatible with RFC 934
   encapsulations; in particular, they do not obey RFC 934 quoting
   conventions for embedded lines that begin with hyphens.  This
   mechanism was chosen over the RFC 934 mechanism because the latter
   causes lines to grow with each level of quoting.  The combination of
   this growth with the fact that SMTP implementations sometimes wrap
   long lines made the RFC 934 mechanism unsuitable for use in the event
   that deeply-nested multipart structuring is ever desired.
]PRE]

参考: ハイフンは、かつての RFC 934 のメッセージのカプセル化方式
との大雑把な互換性と、幾つかの実装で区切りを探すのを容易にする
ためにあります。しかし、多部分メッセージは RFC 934 カプセル化と
完全には互換でないことに注意して下さい。特に、 RFC 934 の、ハイフンで始まる
埋め込み行の quote 記法には従っていません。 RFC 934 の方式では
quote の各段階ごとに行が長くなっていきます。
この成長と、 SMTP 実装がしばしば長い行を折り返すという実情から、
RFC 934 の方式は深く入れ子になった多部分構造もが望ましいところで
使うのには不適切ということになります。

[PRE[
   WARNING TO IMPLEMENTORS:  The grammar for parameters on the Content-
   type field is such that it is often necessary to enclose the boundary
   parameter values in quotes on the Content-type line.  This is not
   always necessary, but never hurts. Implementors should be sure to
   study the grammar carefully in order to avoid producing invalid
   Content-type fields.  Thus, a typical "multipart" Content-Type header
   field might look like this:
]PRE]

実装者への警告: CT 領域のパラメーターの文法から、 boundary パラメータ値を
CT 行において引用符で囲む必要がしばしばあります。これは常に必要では
ありませんが、囲んでおけば損傷することはありません。
実装者は不適切な CT 領域を生成しないように、文法を良く研究するべきです。
よって、典型的な "" CT 頭領域はこのようになります。

[PRE[
     Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
]PRE]

[PRE[
   But the following is not valid:
]PRE]

しかし次のものは(コロンのため)妥当ではありません。

[PRE[
     Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
]PRE]

(because of the colon) and must instead be represented as

代わりに次のように表現しなければなりません。

[PRE[
     Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
]PRE]

[PRE[
   This Content-Type value indicates that the content consists of one or
   more parts, each with a structure that is syntactically identical to
   an RFC 822 message, except that the header area is allowed to be
   completely empty, and that the parts are each preceded by the line
]PRE]

この CT 値は、内容が一つ以上の部分から構成されていて、
それぞれが、頭領域は完全に空でも良いことを除いて 
RFC 822 メッセージと構文的には同じ構造を持っていて、
部分はそれぞれ次の行が前にあることを示します。

[PRE[
     --gc0pJq0M:08jU534c0p
]PRE]

[PRE[
   The boundary delimiter MUST occur at the beginning of a line, i.e.,
   following a CRLF, and the initial CRLF is considered to be attached
   to the boundary delimiter line rather than part of the preceding
   part.  The boundary may be followed by zero or more characters of
   linear whitespace. It is then terminated by either another CRLF and
   the header fields for the next part, or by two CRLFs, in which case
   there are no header fields for the next part.  If no Content-Type
   field is present it is assumed to be "message/rfc822" in a
   "multipart/digest" and "text/plain" otherwise.
]PRE]

境界区切りは行のはじめ、すなわち CRLF の後に出現しなければ
'''なりません'''。最初の CRLF は前の部分ではなく境界区切行の
付属するものと考えます。区切りの後には0文字以上の行空白間隔が続いても
構いません。その後の別の CRLF と次の部分の頭領域, または2つの CRLF
で終端となります。後者の場合は次の部分の頭領域はありません。
CT 領域が無い場合、 "" では "" が, それ以外では "" が仮定されます。

[PRE[
   NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.
]PRE]

参考: 境界区切りの前の CRLF は概念的には境界に付属するものですから、
CRLF (改行) で終わらない部分を作ることが可能なわけです。また、
改行で終わると考えなければならない本文部分では、境界区切行の前に
2つの CRLF がなければなりません。最初のものは前の本文部分の一部で、
2番目のものはカプセル化境界の一部です。

Boundary delimiters must not appear within the encapsulated material,
and must be no longer than 70 characters, not counting the two leading hyphens.

境界区切りはカプセル化されたものの中には出現してはならず、
2つの先導ハイフンを数えないで、70文字を超えてもならりません。

The boundary delimiter line following the last body part is a
distinguished delimiter that indicates that no further body parts
will follow.  Such a delimiter line is identical to the previous
delimiter lines, with the addition of two more hyphens after the
boundary parameter value.

最後の本文部分に続く境界区切行は、それ以上本文部分が
続かないことを示す違った区切りになります。この区切行は今までの
区切行に、2つのハイフンを boundary パラメーター値の後に加えたもの
になります。

[PRE[
     --gc0pJq0M:08jU534c0p--
]PRE]

[PRE[
   NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
   boundary value with the beginning of each candidate line.  An exact
   match of the entire candidate line is not required; it is sufficient
   that the boundary appear in its entirety following the CRLF.
]PRE]

実装者への参考: 境界文字列比較は、各候補行の最初と境界値を
比較します。候補行全体との正確な一致は必要ありません。
CRLF の直ぐ後に境界が出現すれば十分です。

[PRE[
   There appears to be room for additional information prior to the
   first boundary delimiter line and following the final boundary
   delimiter line.  These areas should generally be left blank, and
   implementations must ignore anything that appears before the first
   boundary delimiter line or after the last one.
]PRE]

最初の境界区切行の前と最後の境界区切行の後に追加情報の場所があります。
この領域は通常からにしておくべきで、実装は最初の境界区切行の前や
最後のの後に出現するものを全て無視しなければなりません。

[PRE[
   NOTE:  These "preamble" and "epilogue" areas are generally not used
   because of the lack of proper typing of these parts and the lack of
   clear semantics for handling these areas at gateways, particularly
   X.400 gateways.  However, rather than leaving the preamble area
   blank, many MIME implementations have found this to be a convenient
   place to insert an explanatory note for recipients who read the
   message with pre-MIME software, since such notes will be ignored by
   MIME-compliant software.
]PRE]

参考 この "preamble" (前書き) と "epoligue" (後書き)
は、適切な型付けが出来なく、
関門でのこれらの領域の取り扱いでの意味が明確になっていないので、通常
使われません。しかし、前書き領域を空にしておくのではなく、
多くの MIME 実装は、 MIME 以前のソフトウェアでメッセージを読む受信者への
説明メモを挿入する都合の良い場所としています。このメモは
MIME 適合ソフトウェアには無視されますから。

[PRE[
   NOTE:  Because boundary delimiters must not appear in the body parts
   being encapsulated, a user agent must exercise care to choose a
   unique boundary parameter value.  The boundary parameter value in the
   example above could have been the result of an algorithm designed to
   produce boundary delimiters with a very low probability of already
   existing in the data to be encapsulated without having to prescan the
   data.  Alternate algorithms might result in more "readable" boundary
   delimiters for a recipient with an old user agent, but would require
   more attention to the possibility that the boundary delimiter might
   appear at the beginning of some line in the encapsulated part.  The
   simplest boundary delimiter line possible is something like "---",
   with a closing boundary delimiter line of "-----".
]PRE]

参考: 境界区切りはカプセル化されている本文部分に出現してはならないので、
利用者代理者は独特な boundary パラメーター値を選ぶのに注意しなければなりません。
上の例にある boundary パラメーター値は、カプセル化されるデータを
予め確認せずに、データ中に
存在する確率が非常に低い境界区切りを生成するように設計された算法の結果
であるとしましょう。他の算法ではより「可読」な境界区切りを、
古い利用者代理者の受信者のために使うかもしれません。しかしその場合は
境界区切リがカプセル化されたデータの中の幾つかの行のはじめに
現れるかもしれない可能性により注意する必要がありましょう。
いちばん簡単な可能な境界区切行は "---" のようなもので、
この場合閉じ境界区切行は "-----" となります。

As a very simple example, the following multipart message has two
parts, both of them plain text, one of them explicitly typed and one
of them implicitly typed:

非常に単純な例として、次の多部分メッセージは2つの部分があり、
両方とも平文で、1つは明示的に型を示していませんが、他方は明示的に
示しています。

[PRE[
     From: Nathaniel Borenstein <nsb@bellcore.com>
     To: Ned Freed <ned@innosoft.com>
     Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
     Subject: Sample message
     MIME-Version: 1.0
     Content-type: multipart/mixed; boundary="simple boundary"
]PRE]

[PRE[
     This is the preamble.  It is to be ignored, though it
     is a handy place for composition agents to include an
     explanatory note to non-MIME conformant readers.
]PRE]

[PRE[
     --simple boundary
]PRE]

[PRE[
     This is implicitly typed plain US-ASCII text.
     It does NOT end with a linebreak.
     --simple boundary
     Content-type: text/plain; charset=us-ascii
]PRE]

[PRE[
     This is explicitly typed plain US-ASCII text.
     It DOES end with a linebreak.
]PRE]

[PRE[
     --simple boundary--
]PRE]

[PRE[
     This is the epilogue.  It is also to be ignored.
]PRE]

これは前書きです。これは無視されますが、
非 MIME 適合読者のために説明メモを入れるのに、
構成代理者にとって手軽な場所であります。

これは暗黙の内に US-ASCII の平文に型付けしています。
改行で終わり'''ません'''。

これは明示的に US-ASCII の平文に型付けしています。
これは改行でおわり'''ます'''。

これは後書きです。これも無視されます。

[PRE[
   The use of a media type of "multipart" in a body part within another
   "multipart" entity is explicitly allowed.  In such cases, for obvious
   reasons, care must be taken to ensure that each nested "multipart"
   entity uses a different boundary delimiter.  See RFC 2049 for an
   example of nested "multipart" entities.
]PRE]

他の "" 実体中の本文部分での媒体型 "" の使用は明示的に認められます。
その様な場合、明白な理由により、各入れ子 "" 実体が
違う境界区切を使うことが確実になるように注意しなければなりません。
入れ子の "" 実態の例は RFC 2049 を見て下さい。

The use of the "multipart" media type with only a single body part
may be useful in certain contexts, and is explicitly permitted.

一つだけの本文部分の "" 媒体型の使用は場面によっては有用かも
しれず、明白に認められます。

[PRE[
   NOTE: Experience has shown that a "multipart" media type with a
   single body part is useful for sending non-text media types.  It has
   the advantage of providing the preamble as a place to include
   decoding instructions.  In addition, a number of SMTP gateways move
   or remove the MIME headers, and a clever MIME decoder can take a good
   guess at multipart boundaries even in the absence of the Content-Type
   header and thereby successfully decode the message.
]PRE]

参考: 経験的には、1つの本文部分の "" 媒体型は、
非 text 媒体型を送るのに便利です。前書きを復号指示の場所
として提供できるという利点があります。加えて、多くの
SMTP 関門が MIME 頭を動かしたり消したりします。
りこうな MIME 復号者は、 CT 頭が無くても多部分境界のうまい推定
が出来ますから、これによりメッセージの復号が成功します。

[PRE[
   The only mandatory global parameter for the "multipart" media type is
   the boundary parameter, which consists of 1 to 70 characters from a
   set of characters known to be very robust through mail gateways, and
   NOT ending with white space. (If a boundary delimiter line appears to
   end with white space, the white space must be presumed to have been
   added by a gateway, and must be deleted.)  It is formally specified
   by the following BNF:
]PRE]

"" 媒体型の共通の必須パラメーターは boundary パラメーターだけです。
これはメイル関門で非常に強いと言われている文字の集合から、
1〜70文字使って構成するもので、空白間隔で終わり'''ません'''。
(境界区切行が空白間隔で終わって現れた場合、空白間隔は
関門で追加されたものとして考えて削除しなければなりません。)
次に示す BNF が正式な規定です。

[PRE[
     boundary := 0*69<bchars> bcharsnospace
]PRE]

[PRE[
     bchars := bcharsnospace / " "
]PRE]

[PRE[
     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"
]PRE]

Overall, the body of a "multipart" entity may be specified as follows:

概して、 "multipart" 実体の本文は次のように規定することが出来ます。

[PRE[
     dash-boundary := "--" boundary
                      ; boundary taken from the value of
                      ; boundary parameter of the
                      ; Content-Type field.
]PRE]

; CT 領域の boundary パラメーターの値から採った境界

[PRE[
     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]
]PRE]

[PRE[
     transport-padding := *LWSP-char
                          ; Composers MUST NOT generate
                          ; non-zero length transport
                          ; padding, but receivers MUST
                          ; be able to handle padding
                          ; added by message transports.
]PRE]

; 構成者は0で無い長さの転送埋めを生成しては'''なりません'''が、
受信者はメッセージ転送者が加えた埋めを扱えなければ
'''なりません'''。

[PRE[
     encapsulation := delimiter transport-padding
                      CRLF body-part
]PRE]

[PRE[
     delimiter := CRLF dash-boundary
]PRE]

[PRE[
     close-delimiter := delimiter "--"
]PRE]

[PRE[
     preamble := discard-text
]PRE]

[PRE[
     epilogue := discard-text
]PRE]

[PRE[
     discard-text := *(*text CRLF) *text
                     ; May be ignored or discarded.
]PRE]

; 無視したり捨てたりして構いません。

[PRE[
     body-part := MIME-part-headers [CRLF *OCTET]
                  ; Lines in a body-part must not start
                  ; with the specified dash-boundary and
                  ; the delimiter must not appear anywhere
                  ; in the body part.  Note that the
                  ; semantics of a body-part differ from
                  ; the semantics of a message, as
                  ; described in the text.
]PRE]

; body-part 中の行は指定された dash-boundary で始まってはなりませんし、
delimiter は本文部文中のどこにも現れてはなりません。なお、
body-part の意味は、文中に述べたようにメッセージの意味とは異なります。

[PRE[
     OCTET := <any 0-255 octet value>
]PRE]

IMPORTANT:  The free insertion of linear-white-space and RFC 822
comments between the elements shown in this BNF is NOT allowed since
this BNF does not specify a structured header field.

重要: この BNF 中の要素間への lws と RFC 822 注釈の自由な挿入は、
この BNF が構造化頭領域を規定するものではないので、
認められま'''せん'''。

[PRE[
   NOTE:  In certain transport enclaves, RFC 822 restrictions such as
   the one that limits bodies to printable US-ASCII characters may not
   be in force. (That is, the transport domains may exist that resemble
   standard Internet mail transport as specified in RFC 821 and assumed
   by RFC 822, but without certain restrictions.) The relaxation of
   these restrictions should be construed as locally extending the
   definition of bodies, for example to include octets outside of the
   US-ASCII range, as long as these extensions are supported by the
   transport and adequately documented in the Content- Transfer-Encoding
   header field.  However, in no event are headers (either message
   headers or body part headers) allowed to contain anything other than
   US-ASCII characters.
]PRE]

参考: ある転送 enclave では、本文を印字可能 US-ASCII 文字
に制限するといった RFC 822 の制限が強制されていないかもしれません。
(すなわち、ある制限を除いた RFC 821 で規定された標準 Internet メイル転送に似た、
そして RFC 822 と見せかけた転送範囲が存在するかもしれません。)
こうした制限の緩和は、
例えば US-ASCII 範囲外のオクテットを含めることは、
これらの拡張を転送が対応していて、 CTE 頭領域で十分に明示される限りは、
本文の定義の局地的な拡張と解釈するべきです。しかし、頭
(メッセージ頭と本文部分かしら共に) で US-ASCII 以外の文字を含めることは
認められません。

[PRE[
   NOTE:  Conspicuously missing from the "multipart" type is a notion of
   structured, related body parts. It is recommended that those wishing
   to provide more structured or integrated multipart messaging
   facilities should define subtypes of multipart that are syntactically
   identical but define relationships between the various parts. For
   example, subtypes of multipart could be defined that include a
   distinguished part which in turn is used to specify the relationships
   between the other parts, probably referring to them by their
   Content-ID field.  Old implementations will not recognize the new
   subtype if this approach is used, but will treat it as
   multipart/mixed and will thus be able to show the user the parts that
   are recognized.
]PRE]

参考: "multipart" 型に目立って欠けているのは、本文部分に関する構造の記述です。
より構造化された, よりまたは統合されたメッセージ機能を提供しようと
する時は、構造的には同じであるが各部分間の関係を定義した多部分の
亜型を定義するべきです。例えば、ある多部分の亜型は、特別な部分を含み、
次にはこれが他の部分との関係を指定する (おそらくは
Content-ID 領域を参照するのに使って。) のに使われるというように定義出来ます。
この方法が使われた時に古い実装は新しい亜型を認識できませんが、
multipart/mixed であるものとして扱い、認識できる部分を利用者に示す
ことが出来るでしょう。

* 5.1.2.  Handling Nested Messages and Multiparts

[PRE[
   The "message/rfc822" subtype defined in a subsequent section of this
   document has no terminating condition other than running out of data.
   Similarly, an improperly truncated "multipart" entity may not have
   any terminating boundary marker, and can turn up operationally due to
   mail system malfunctions.
]PRE]

この文書の後の節で定義する "" 亜型は、データが終わる以外に
終端を示すものがありません。同様に、不適切に切られた "multipart"
実体は終端境界印を持たないかもしれません。そしてこれは、
メイル系統の不調により出現する可能性があります。

[PRE[
   It is essential that such entities be handled correctly when they are
   themselves imbedded inside of another "multipart" structure.  MIME
   implementations are therefore required to recognize outer level
   boundary markers at ANY level of inner nesting.  It is not sufficient
   to only check for the next expected marker or other terminating
   condition.
]PRE]

このような実体が他の "multipart" 構造の内側に埋め込まれていた時に
正しく扱えることが必要です。 MIME 実装は従って、内側の入れ子の
'''どの'''段階にあっても外側の境界印を認識出来る必要があります。
次に予期される印やその他の終端を確認するだけでは十分ではありません。

* 5.1.3.  Mixed Subtype

[PRE[
   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.
   Any "multipart" subtypes that an implementation does not recognize
   must be treated as being of subtype "mixed".
]PRE]

"multipart" の "mixed" 亜型は、各本文部分が独立していて、
特定の順で束ねる必要があるときに使うことを意図しています。
実装が認識出来ない "multipart" の亜型はすべて、亜型 "mixed"
であるとして扱わなければなりません。

* 5.1.4.  Alternative Subtype

See [[multipart/alternative媒体型]]

* 5.1.5.  Digest Subtype

See [[multipart/digest媒体型]]

* 5.1.6.  Parallel Subtype

See [[multipart/parallel媒体型]]

* 5.1.7.  Other Multipart Subtypes

Other "multipart" subtypes are expected in the future.  MIME
implementations must in general treat unrecognized subtypes of
"multipart" as being equivalent to "multipart/mixed".

他の "multipart" 亜型が将来期待されます。 MIME 実装は通常、
認識出来ない "multipart" の亜型を "multipart/mixed" と同等であるものとして
扱わなければなりません。
]FIG]

[FIG[
[FIGCAPTION[
[221] RFC 2049 Appendix A -- A Complex Multipart Example
]FIGCAPTION]

What follows is the outline of a complex multipart message.  This
message contains five parts that are to be displayed serially:  two
introductory plain text objects, an embedded multipart message, a
text/enriched object, and a closing encapsulated text message in a
non-ASCII character set.  The embedded multipart message itself
contains two objects to be displayed in parallel, a picture and an
audio fragment.

[PRE[
     MIME-Version: 1.0
     From: Nathaniel Borenstein <nsb@nsb.fv.com>
     To: Ned Freed <ned@innosoft.com>
     Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
     Subject: A multipart example
     Content-Type: multipart/mixed;
                   boundary=unique-boundary-1
]PRE]

[PRE[
     This is the preamble area of a multipart message.
     Mail readers that understand multipart format
     should ignore this preamble.
]PRE]

[PRE[
     If you are reading this text, you might want to
     consider changing to a mail reader that understands
     how to properly display multipart messages.
]PRE]

[PRE[
     --unique-boundary-1
]PRE]

[PRE[
       ... Some text appears here ...
]PRE]

[PRE[
     [Note that the blank between the boundary and the start
      of the text in this part means no header fields were
      given and this is text in the US-ASCII character set.
      It could have been done with explicit typing as in the
      next part.]
]PRE]

[PRE[
     --unique-boundary-1
     Content-type: text/plain; charset=US-ASCII
]PRE]

[PRE[
     This could have been part of the previous part, but
     illustrates explicit versus implicit typing of body
     parts.
]PRE]

[PRE[
     --unique-boundary-1
     Content-Type: multipart/parallel; boundary=unique-boundary-2
]PRE]

[PRE[
     --unique-boundary-2
     Content-Type: audio/basic
     Content-Transfer-Encoding: base64
]PRE]

[PRE[
       ... base64-encoded 8000 Hz single-channel
           mu-law-format audio data goes here ...
]PRE]

[PRE[
     --unique-boundary-2
     Content-Type: image/jpeg
     Content-Transfer-Encoding: base64
]PRE]

[PRE[
       ... base64-encoded image data goes here ...
]PRE]

[PRE[
     --unique-boundary-2--
]PRE]

[PRE[
     --unique-boundary-1
     Content-type: text/enriched
]PRE]

[PRE[
     This is <bold><italic>enriched.</italic></bold>
     <smaller>as defined in RFC 1896</smaller>
]PRE]

[PRE[
     Isn't it
     <bigger><bigger>cool?</bigger></bigger>
]PRE]

[PRE[
     --unique-boundary-1
     Content-Type: message/rfc822
]PRE]

[PRE[
     From: (mailbox in US-ASCII)
     To: (address in US-ASCII)
     Subject: (subject in US-ASCII)
     Content-Type: Text/plain; charset=ISO-8859-1
     Content-Transfer-Encoding: Quoted-printable
]PRE]

[PRE[
       ... Additional text in ISO-8859-1 goes here ...
]PRE]

[PRE[
     --unique-boundary-1--
]PRE]
]FIG]

[FIG[
[FIGCAPTION[
[222] RFC 1945 (HTTP/1.0) 3.6.2; RFC 2068・2616 (HTTP/1.1) 3.7.2 Multipart Types
]FIGCAPTION]

> MIME provides for a number of "multipart" types -- encapsulations 
of [DEL[[INS[{1945}]] several]] [INS[[INS[{2068,2616}]] one or more]] entities within a 
single [DEL[[INS[{1945}]] message's Entity-Body]] [INS[[INS[{2068,2616}]] message-body]]. [DEL[[INS[{1945}]] The multipart types registered by IANA [15] do not have any special meaning for HTTP/1.0, though user agents may need to understand each type in order to correctly interpret the purpose of each body-part. An HTTP user agent should follow the same or similar behavior as a MIME user agent does upon receipt of a multipart type. HTTP servers should not assume that all HTTP clients are prepared to handle multipart types.]]

[[MIME]] は、幾つかの [CODE(MIME)[multipart]] (多部分)
型を提供しています。これを使うと、一つの [CODE(ABNF)[[[message-body]]]]
に一つ以上の[[実体]]をカプセル化できます。 [DEL[IANA に登録されている多部分型は、 HTTP/1.0 に対して特別な意味を持っていません。ただし[[利用者エージェント]]は各[[本体部分]]の目的を正しく解釈するために各型を理解する必要があるかもしれません。 HTTP 利用者エージェントは、多部分型を受信した時の MIME 利用者エージェントと同じか同様の振る舞いをするべきです。 HTTP [[サーバー]]は、すべての HTTP [[クライアント]]が多部分型を扱う準備ができていると仮定するべきではありません。]]

> All multipart types share a common syntax[INS[, [INS[{2068,2616}]] as defined in  [DEL[MIME [7] ]][INS[section 5.1.1 of RFC 2046 [40] ]],]] and [DEL[[INS[{1945}]] must]] [INS[MUST]]
include a boundary parameter as part of the media type value. The message body is itself a protocol element and [DEL[[INS[{1945}]] must]] [INS[MUST]]
therefore use only CRLF to represent line breaks between body-parts. [DEL[[INS[{1945}]] Multipart body-parts may contain HTTP header fields which are significant to the meaning of that part.]] [INS[[INS[{2068,2616}]] Unlike in [DEL[MIME]] [INS[RFC 2046]], the epilogue of any multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original multipart contains an epilogue). [INS[[INS[{2616}]] These restrictions exist in order to preserve the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart boundary.]]]]

すべての多部分型は、 MIME で定義されている共通の構文を共有し、
媒体型値の一部として [CODE(MIME)[[[boundary]]]] (境界) 引数を含みます。
メッセージ本体はそれ自体プロトコル要素ですから、
本体部分間の[[改行]]を表現するときには [CODE(MIME)[[[CRLF]]]]
だけを使用しなければ'''なりません'''。 [DEL[多部分本体部分は、その部分の意味にとって重要である HTTP 頭欄を含んでも構いません。]] [INS[MIME とは異なり、多部分メッセージの [CODE(ABNF)[[[epilogue]]]] (後書き) は空でなければなりません。 HTTP [[応用]]は、 (たとえもとの多部分が後書きを含んでいたとしても) 後書きを転送しては'''なりません'''。[INS[この制限は、多部分 [CODE(ABNF)[message-body]] の自己区切性を維持するために存在します。 [CODE(ABNF)[message-body]] の「終了」は終了多部分境界で示します。]]]]

[INS[
[INS[
>[INS[{2616}]] In general, HTTP treats a multipart message-body no differently than
any other media type: strictly as payload. The one exception is the
"multipart/byteranges" type (appendix 19.2) when it appears in a 206
(Partial Content) response, which will be interpreted by some HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all
other cases, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type.
The MIME header fields within each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by
their MIME semantics.

通常、 HTTP は多部分 [CODE(ABNF)[message-body]] を他の媒体型と何ら違わず、
厳密に積荷として扱います。1つの例外は [CODE(MIME)[[[multipart/byteranges]]]]
型が [CODE(HTTP)[[[206]] (部分内容)]] 応答で使われた時で、
12.5.3節と14.16節で説明する HTTP [[キャッシュ]]機構により解釈されます。
これ以外の全ての場合には、 HTTP 利用者エージェントは、多部分型を受信した時の MIME 利用者エージェントと同じか同様の振る舞いをする'''べきです'''。
多部分 [CODE(ABNF)[message-body]] の各本体部分中の MIME 頭欄は、
HTTP ではその MIME 的な意味で定義された以上の意義を持ちません。

]INS]
[DEL[
>[INS[{2068}]]  In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part. A Content-Location header
field (section 14.15) SHOULD be included in the body-part of each
enclosed entity that can be identified by a URL.

HTTP では、多部分本体部分は、その部分の意味にとって重要である HTTP 頭欄を含んでも'''構いません'''。
[[URL]] で識別できる[[囲まれた実体]]の本体部分には
[CODE(HTTP)[[[Content-Location]]]] 頭欄を含める'''べきです'''。
]DEL]

>[INS[{2068,2616}]] In general, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type.
If an application receives an unrecognized multipart subtype, the
application MUST treat it as being equivalent to "multipart/mixed".

通常、 HTTP 利用者代理者は、多部分型を受信した時の 
MIME 利用者エージェントと同じか同様の振る舞いをする'''べきです'''。
応用が認識出来ない多部分亜型を受け取った場合は、
応用は [CODE(MIME)[[[multipart/mixed]]]] と同等として扱わなければ'''なりません'''。

> Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST request
method, as described in RFC 1867 [15].

注意: [CODE(MIME)[[[multipart/form-data]]]] 型が特に
[CODE(HTTP)[[[POST]]]] 要求方式での処理に適当なフォーム・データ運搬のために定義されています。
これは [[RFC1867]] で説明されています。
]INS]
]FIG]

[FIG[
[FIGCAPTION[
[223] RFC 1945 (HTTP/1.0) C.5; RFC 2068 (HTTP/1.1) 19.4.5 HTTP Header Fields in Multipart Body-Parts
]FIGCAPTION]

> In [DEL[RFC 1521]] [INS[MIME]], most header fields in multipart body-parts are generally
ignored unless the field name begins with "Content-". In [DEL[HTTP/1.0]] [INS[HTTP/1.1]],
multipart body-parts may contain any HTTP header fields which are
significant to the meaning of that part.

MIME では、多部分本体部分中のほとんどの頭欄が、欄名が [CODE(MIME)[Content-]]
で始まらない限り通常は無視されます。 HTTP
では、多部分本体部分に、その部分の意味にとって重要な任意の 
HTTP 頭欄を入れることができます。

[INS[
注: この節は、 RFC 2616 では削除されています。
]INS]
]FIG]

* メモ

[58] [[複数部分]]より[CODE[[[多]]部分]]と訳す方がちょっといいかなあと思う今日このごろです。

[59] >>58 辞書で [CODE[multi‐]] の訳語を眺めてみた限りでは、全体的には[CODE[多]]が優勢で、計算機系では他の分野より[CODE[複数]]と訳すことがおおいもののやっぱり[CODE[多]]が優勢な気がします。[CODE[多重]]と訳した場合も比較的多くて、ちょっと心惹かれます。[CODE[多重部分]]みたいな。

[60] あ、ただし、[CODE[多重]]はほとんどすべてが [CODE[multiple]] の訳語なんですね。だからちょっと [CODE(regex)[multi(?!ple)]] の訳語に使うのは気がひけるというか。

[12]
複数の[[実体]]を一つの実体にまとめる方法としては、 MIME
の [CODE(MIME)[multipart/[VAR[*]]]] 
以外にも色々考案されています。

MIME 以前の [[RFC 934]] や [CODE(822)[[[Encoding]]:]] 欄などはその一種ですし、
[[ZIP]] や [[TAR]] の類も広義ではその仲間です。

より狭義に、 MIME 実体をまとめた MIME 実体としては、
[CODE(MIME)[[[application/vnd.pwg-multiplexed]]]]
があります。
この形式では中身の実体を複数にぶった切って途中に別の実体を挟んだりできます。
([[HTML]] の [CODE(HTMLe)[[[img]]]] 要素の直後に画像実体がくるような使い方を想定しています。)

[14]
[CODE(MIME)@en[[[application/vnd.oma.drm.message]]]]
は [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] の[[構文]]を採用しています。

[17] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
([TIME[2009-09-12 07:37:40 +09:00]] 版)
<http://tools.ietf.org/html/rfc5621#section-4>