[1] multipart/* MIME型は、 MIME が汎用的に定義した、
単一メッセージ中に複数の部分 (実体) を含める方法です。
すべての亜型が同じ構造をしていますから、各型の自由度は低まりますが、対応していない利用者エージェントであっても、とりあえず
multipart/mixed 媒体型として最低限の解釈は可能になります。
multipart/* MIME 型の一覧| 媒体型 | |||
|---|---|---|---|
| multipart/alternative | 選択肢群 | [MIME] | |
multipart/appledouble | |||
| multipart/byteranges | 部分塊 | HTTP | |
| multipart/x-byteranges | 部分塊 | HTTP 原案 | |
| multipart/digest | 要約版メッセージ群 | [MIME] | |
| multipart/encrypted | 暗号化メッセージ | [RFC1847] | |
multipart/example | IETF RFC, IANA 登録済 | RFC, [IANAREG] | |
multipart/foo | |||
| multipart/form-data | FORM 送信 | [RFC2388] | |
multipart/gedi-record | GEDI | IANA 未登録, ISO 標準 | |
| multipart/header-set | ファイル系統物体 | [IANAREG] | |
multipart/x-mimepgp | |||
multipart/mixed | |||
multipart/x-mixed-replace | |||
multipart/x-multi-encrypted | |||
multipart/multilingual | |||
| multipart/parallel | 同時再生 | [MIME] | |
| multipart/related | 関連束 | [RFC2387] | |
| multipart/report | 配送報告 | [RFC1892] | |
multipart/dvb.service | Multipart DVB Services | 非標準 | [MHP 1.1] |
multipart/x-sgml | SGML 実体群 | ||
| multipart/signed | 署名メッセージ | [RFC1847] | |
| multipart/voice-message | 音声メッセージ | [RFC2421] [RFC2423] | |
multipart/x-www-form-data | フォーム・データ集合 | 時代遅れ → multipart/form-data | Emacs/W3 |
[33] multipart/* は、
独立したデータ型の複数の実体で構成されるデータを表します >>30。
[32] multipart/* MIME型は、 RFC 2046 の構文その他の制限に適合しなければなりません >>34, >>31。
[35] multipart/* の本体は1つ以上の本体部分で構成されます。
本体部分の前には境界区切子行があり、
最後には閉じ境界区切子行があります。 >>34
[50] 本体部分が1つだけでも有用な場合はあるため、認められています >>34。
[51] 1つもないものは認められていないようです。しかし現実には用いられることがあります。
[57] 本体部分の順序に意味があるかどうかは、MIME型に依存します。
[8] HTTP は text/* については MIME とは違って
CRLF への正規化を要求していません。しかし、 multipart/*
の改行は MIME と同じで CRLF でなければなりません >>211。
この点は RFC 1945 からしっかり明記されています。
[6] 最初の境界文字列の前には境界文字列以外の任意の ASCII文字の列を記述できます。 これを前書きといいます。その場合前書きの後に CRLF が必要です。
[18] 前書きは、 MIME 未対応の利用者エージェントで表示される (人間向けの) メッセージとして使うことを意図したものです。前書きが含まれる場合、 多くの場合は MUA によって自動生成される「MIME 対応 MUA で開いてください」 のような文言です。
[220] MIME の規定では、最後の本体部分の終わりの境界の後に任意の (US-ASCII) 文字列を入れることができます。 その部分は MIME UA には無視されます。 この部分のことを後書きといいます。
[224] HTTP では、 RFC 2616 までは後書きを禁止していました。 しかしこの規定は RFC 7230/RFC 7231 では無くなっています。
[225] RFC 2616 までは、本来 Content-Length:
ヘッダーが必要な場合でも multipart/byteranges
を使っていれば省略してもいいことになっていました。
これは本体部分の最後の境界で終わりを示せるからです。
ところが後書きがあるとこの仮定が崩れます。
だから禁止しているのです。
しかしこの規定も RFC 7230/RFC 7231 では無くなっています >>211。
[5] multipart/* に含まれる実体のことを、
本体部分といいます。
[49] multipart/* 内で入れ子に multipart/*
を使うこともできます >>34。
[54] 不正な multipart/* が入れ子に含まれている場合に備えて、
内側の本体部分の処理中も、外側の境界区切子をも走査する必要があります >>34。
[55] 認識できない multipart/* は、
multipart/mixed として扱わなければなりません >>34。
multipart/mixed への対応を求めており、
それが実装されないことは想定していないようです。 Web では
multipart/mixed に対応することは稀で、
いずれもダウンロードとして扱われます。[64] Content-Language: も参照。
Content-Disposition: ヘッダーとの関係[26] multipart/* 実体 (個別の本体部分ではなく、
全体) に対して Content-Disposition: ヘッダーが指定された場合、
それは全体に適用されます >>25。
[27] 当該 multipart/* 実体が表示されていない間は、
各本体部分に対する Content-Disposition: の指定も適用されません
>>25。
[28] 例えば multipart/* 実体に
Content-Disposition: attachment が指定されている場合、
その multipart/* 実体全体が利用者の指示があるまで表示されません。
[29] 利用者の指示で表示する際、 Content-Disposition: inline
の実体本体と Content-Disposition: attachment
の実体本体がその中に含まれていれば、前者は自動的に表示し、
後者は更に利用者の指示があるまで表示しません。
multipart/*[22] HTTP での multipart/* 媒体型の使用について。
[23] MIME で複数の実体を一つのメッセージに詰め込むために用意されている
multipart/* 型は、 HTTP でも使うことがあります。
しかしながら、実際には使えるとも使えないともいえない中途半端な状態で実装されています。
[3] HTTP RFC は multipart/* 媒体型が HTTP でも使えると言っているものの、対応している実装はそうないと思われます。せいぜい、
multipart/x-mixed-replace と、 HTML form
送信用の multipart/form-data, multipart/mixed 位ではないでしょうか。
[16] HTTP 応用では、幾つかの亜型は対応している実装がかなりありますが、
全体としてはほとんど無視している状態です。 MIME でも HTTP
でも、未対応の multipart/* に出会ったら
multipart/mixed と同じに振舞うことになっていますが、
ほとんどの応用が multipart/mixed に対応していないのだからどうしようもありません。。。
multipart/form-dataform 要素などのフォームからデータを送信する時に POST 要求でよく使われる型です。
ファイルうpには必須とあって一気に普及しましたが、行き当たりばったりな実装ばかりで無難にやり過ごすとしたら最低限のこともできないかもしれません。まあ Web 関連規格は大体がそういう状態ですな。multipart/byteranges206 応答で内容全体ではなく内容の一部を複数個送るときに使います。
大方のサーバーと大方の WWWブラウザや prefetcher が対応しています。multipart/x-byterangesbyterange の規格制定過程の古い形式で、今でも対応している WWW ブラウザもあります。
とはいえ歴史的なものでおそらく誰も使って無いでしょう。multipart/x-mixed-replacemultipart/relatedmultipart/related を使えることになっています。仕様上は。
実際使われているのかは謎です。そもそも SOAP 自体(ry[208] これ以外の亜型に対応した実装はほとんどありません。
複数個の本体があるとどうレンダリングしたらいいか困っちゃいますからねぇ。 ブラウザとしては。フレームと同じようにしたらどうよ? という気もしないでもないですが。
[209] 電子メイルを扱える WWW ブラウザだと、 multipart/*
を直接扱えなくても HTTP 的には message/rfc822
で、その中に多部分がある感じにすれば、 (電子メイルを扱う時と同程度には)
表示できたりします。でもまあこんなの HTTP での多部分に対応しているとは言わんな。
[210] HTTP が MIME を採用していれば何も問題はなかったのですが、あいにく HTTP は「MIME 的なもの」を含んでいるので、多部分を完全に MIME 的に取扱っても良いのか、はっきり書かれていないと困ってしまいます。
何も言っていないのは特に変更しないからだと判断して MIME 的に実装してしまうのももっともなのですが、 そうすると整合性の点で問題になっちゃうこともあるような気もします。
歴代仕様書を比較すると、最新の RFC 2616 は以前の RFC より MIME との互換性に気を遣っているような感じです。
[24] OData は HTTP で multipart/mixed
を使っています。
[37] multipart/* の実体について、
7bit、8bit、
binary 以外を Content-Transfer-Encoding:
で使うことはできません >>34。
[2] MIME は電子メイルでの利用を念頭に設計しましたから、バイナリな転送プロトコル, 例えば HTTP では、境界の扱いなど無駄な部分があります。 そのため、 HTTP で分割転送のために multipart/byteranges 媒体型を採用した時には、よりバイナリ指向な multipart に代わる仕組みを導入しようという意見も強くありましたが、結局 MIME と互換性のある multipart 形式になりました。
[13]
HTTP の multipart/byteranges
のときにも、 multipart/* は overhead が大きいから binary
にしようとか揉めましたが結局 MIME 互換の multipart/byteranges に落ち着きました。
[11] WSP は多部分型のバイナリ表現を規定しています。 (http://www.openmobilealliance.org/wapdocs/wap-230-wsp-20010705-a.pdf 8.5 参照。)
それに伴って定義されている媒体型:
application/vnd.wap.multipart.alternative |
application/vnd.wap.multipart.byteranges |
application/vnd.wap.multipart.form-data |
application/vnd.wap.multipart.mixed |
[61] 現代に発明されていたなら構造化構文接尾辞となっていたことでしょう。
[62] null, , https://catill.bitbucket.io/CATP/catp1.1/honbun.html#_Toc464618953
[63] >>62 CATP の Multi-record の構文は明らかに MIME multipart
の影響を受けています。
(が CATP は MIME を使わず、独自に定義しています。)
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 を持つことを示します。
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.
本文部分に対して意味が定義されている頭領域は "Content-" で始まる名前を 持つもののみです。他の全ての頭領域は本文部分では無視されます。 これは全然可能であるならば通常はそのままにしておくべきですが、 必要ならば関門により捨てられるかもしれません。このような他の領域 が本文部分に出現することは認められますが、それに依存してはいけません。 "X-" 領域を実験あるいは私的な目的で作成しても構いませんが、 そこに含まれる情報は関門で失われ得ることを認識している必要があります。
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.)
RFC 822 メッセージと本文部分の区別はわずかですが、重要です。 例えば Internet と X.400 のメイル関門は、画像を含む本文部分と 本文が JPEG 画像のカプセル化メッセージが含まれている本文部分の違いを 知り得る必要があります。後者を表現するためには、本文部分に "Content-Type: message/rfc822" をつけ、その本文 (空行の後) に "" 頭領域を持ったカプセル化メッセージを入れなければなりません。 同様の構文を使うことでメッセージの本文部分への変換が促進されますし、 逆に実装者は2つの区別を理解しなければなりません。 (部分が実際メッセージである特別な場合のために、 "digest" 亜型も定義します。)
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.
前述のように、本文部分の前には境界区切りを含む境界区切行が来ます。 境界区切りは、カプセル化部分の内部で行そのものあるいは行の頭に 現れてはなりません。ですから、構成代理者は、 囲んでいる多部分で boundary パラメーター値に接頭辞として含まれていない、 独特な boundary パラメーター値を選択・指定できます。
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.
現在及び将来の全ての "multipart" の亜型は同じ構文を使用しなければなりません。 亜型はその意味において異なるでしょうし、構文に追加の制限を加えても 構いませんが、 "multipart" 型の要求構文に適合しなければなりません。 この要求事項があるので、全ての適合利用者代理者は、その亜型が認識出来ない ものであっても、多部分実体の部分を少なくても認識・分離することが 出来るでしょう。
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.
CTE 領域の定義で述べたように、 ... 以外の符号化は "multipart" 型の 実体には認められていません。 "multipart" 境界区切りと 頭領域は常にいかなる場合においても7ビット US-ASCII で (非 US-ASCII 頭文を RFC 2047 により符号化しても構いませんが。) 表現しなければ なりません。また本文部文中のデータは、部分ごとに、 適切な各本文部分の CTE 領域をつけて符号化することが出来ます。
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.
この節では "multipart" の亜型の共通の構文を定義します。 "Multipart" の全ての亜型はこの構文をつかわなければなりません。 多部分メッセージの単純な例もこの節に提示します。より複雑な多部分メッセージ の例は RFC 2049 にあります。
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.多部分実体の CT 領域では、パラメーター "boundary" が必要です。 境界区切行は2つのハイフン文字 ("-", 10進値45) とそれに続けて CT 頭領域から boundary パラメーター値, 省略可能な行空白間隔, 終端 CRLF の全体から構成されます。
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.
参考: ハイフンは、かつての RFC 934 のメッセージのカプセル化方式 との大雑把な互換性と、幾つかの実装で区切りを探すのを容易にする ためにあります。しかし、多部分メッセージは RFC 934 カプセル化と 完全には互換でないことに注意して下さい。特に、 RFC 934 の、ハイフンで始まる 埋め込み行の quote 記法には従っていません。 RFC 934 の方式では quote の各段階ごとに行が長くなっていきます。 この成長と、 SMTP 実装がしばしば長い行を折り返すという実情から、 RFC 934 の方式は深く入れ子になった多部分構造もが望ましいところで 使うのには不適切ということになります。
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:
実装者への警告: CT 領域のパラメーターの文法から、 boundary パラメータ値を CT 行において引用符で囲む必要がしばしばあります。これは常に必要では ありませんが、囲んでおけば損傷することはありません。 実装者は不適切な CT 領域を生成しないように、文法を良く研究するべきです。 よって、典型的な "" CT 頭領域はこのようになります。
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
But the following is not valid:
しかし次のものは(コロンのため)妥当ではありません。
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
(because of the colon) and must instead be represented as
代わりに次のように表現しなければなりません。
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
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
この CT 値は、内容が一つ以上の部分から構成されていて、 それぞれが、頭領域は完全に空でも良いことを除いて RFC 822 メッセージと構文的には同じ構造を持っていて、 部分はそれぞれ次の行が前にあることを示します。
--gc0pJq0M:08jU534c0p
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.
境界区切りは行のはじめ、すなわち CRLF の後に出現しなければ なりません。最初の CRLF は前の部分ではなく境界区切行の 付属するものと考えます。区切りの後には0文字以上の行空白間隔が続いても 構いません。その後の別の CRLF と次の部分の頭領域, または2つの CRLF で終端となります。後者の場合は次の部分の頭領域はありません。 CT 領域が無い場合、 "" では "" が, それ以外では "" が仮定されます。
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.
参考: 境界区切りの前の 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 パラメーター値の後に加えたもの になります。
--gc0pJq0M:08jU534c0p--
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.
実装者への参考: 境界文字列比較は、各候補行の最初と境界値を 比較します。候補行全体との正確な一致は必要ありません。 CRLF の直ぐ後に境界が出現すれば十分です。
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.
最初の境界区切行の前と最後の境界区切行の後に追加情報の場所があります。 この領域は通常からにしておくべきで、実装は最初の境界区切行の前や 最後のの後に出現するものを全て無視しなければなりません。
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.
参考 この "preamble" (前書き) と "epoligue" (後書き) は、適切な型付けが出来なく、 関門でのこれらの領域の取り扱いでの意味が明確になっていないので、通常 使われません。しかし、前書き領域を空にしておくのではなく、 多くの MIME 実装は、 MIME 以前のソフトウェアでメッセージを読む受信者への 説明メモを挿入する都合の良い場所としています。このメモは MIME 適合ソフトウェアには無視されますから。
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 "-----".
参考: 境界区切りはカプセル化されている本文部分に出現してはならないので、 利用者代理者は独特な 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つは明示的に型を示していませんが、他方は明示的に 示しています。
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" 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.--simple boundary
This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.--simple boundary--
This is the epilogue. It is also to be ignored.
これは前書きです。これは無視されますが、 非 MIME 適合読者のために説明メモを入れるのに、 構成代理者にとって手軽な場所であります。
これは暗黙の内に US-ASCII の平文に型付けしています。 改行で終わりません。
これは明示的に US-ASCII の平文に型付けしています。 これは改行でおわります。
これは後書きです。これも無視されます。
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.
他の "" 実体中の本文部分での媒体型 "" の使用は明示的に認められます。 その様な場合、明白な理由により、各入れ子 "" 実体が 違う境界区切を使うことが確実になるように注意しなければなりません。 入れ子の "" 実態の例は 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.
一つだけの本文部分の "" 媒体型の使用は場面によっては有用かも しれず、明白に認められます。
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.
参考: 経験的には、1つの本文部分の "" 媒体型は、 非 text 媒体型を送るのに便利です。前書きを復号指示の場所 として提供できるという利点があります。加えて、多くの SMTP 関門が MIME 頭を動かしたり消したりします。 りこうな MIME 復号者は、 CT 頭が無くても多部分境界のうまい推定 が出来ますから、これによりメッセージの復号が成功します。
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:
"" 媒体型の共通の必須パラメーターは boundary パラメーターだけです。 これはメイル関門で非常に強いと言われている文字の集合から、 1〜70文字使って構成するもので、空白間隔で終わりません。 (境界区切行が空白間隔で終わって現れた場合、空白間隔は 関門で追加されたものとして考えて削除しなければなりません。) 次に示す BNF が正式な規定です。
boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"Overall, the body of a "multipart" entity may be specified as follows:
概して、 "multipart" 実体の本文は次のように規定することが出来ます。
dash-boundary := "--" boundary
; boundary taken from the value of
; boundary parameter of the
; Content-Type field.; CT 領域の boundary パラメーターの値から採った境界
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue] 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.; 構成者は0で無い長さの転送埋めを生成してはなりませんが、 受信者はメッセージ転送者が加えた埋めを扱えなければ なりません。
encapsulation := delimiter transport-padding
CRLF body-partdelimiter := CRLF dash-boundary
close-delimiter := delimiter "--"
preamble := discard-text
epilogue := discard-text
discard-text := *(*text CRLF) *text
; May be ignored or discarded.; 無視したり捨てたりして構いません。
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.; body-part 中の行は指定された dash-boundary で始まってはなりませんし、 delimiter は本文部文中のどこにも現れてはなりません。なお、 body-part の意味は、文中に述べたようにメッセージの意味とは異なります。
OCTET := <any 0-255 octet value>
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 が構造化頭領域を規定するものではないので、 認められません。
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.
参考: ある転送 enclave では、本文を印字可能 US-ASCII 文字 に制限するといった RFC 822 の制限が強制されていないかもしれません。 (すなわち、ある制限を除いた RFC 821 で規定された標準 Internet メイル転送に似た、 そして RFC 822 と見せかけた転送範囲が存在するかもしれません。) こうした制限の緩和は、 例えば US-ASCII 範囲外のオクテットを含めることは、 これらの拡張を転送が対応していて、 CTE 頭領域で十分に明示される限りは、 本文の定義の局地的な拡張と解釈するべきです。しかし、頭 (メッセージ頭と本文部分かしら共に) で US-ASCII 以外の文字を含めることは 認められません。
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.
参考: "multipart" 型に目立って欠けているのは、本文部分に関する構造の記述です。 より構造化された, よりまたは統合されたメッセージ機能を提供しようと する時は、構造的には同じであるが各部分間の関係を定義した多部分の 亜型を定義するべきです。例えば、ある多部分の亜型は、特別な部分を含み、 次にはこれが他の部分との関係を指定する (おそらくは Content-ID 領域を参照するのに使って。) のに使われるというように定義出来ます。 この方法が使われた時に古い実装は新しい亜型を認識できませんが、 multipart/mixed であるものとして扱い、認識できる部分を利用者に示す ことが出来るでしょう。
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.
この文書の後の節で定義する "" 亜型は、データが終わる以外に 終端を示すものがありません。同様に、不適切に切られた "multipart" 実体は終端境界印を持たないかもしれません。そしてこれは、 メイル系統の不調により出現する可能性があります。
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.
このような実体が他の "multipart" 構造の内側に埋め込まれていた時に 正しく扱えることが必要です。 MIME 実装は従って、内側の入れ子の どの段階にあっても外側の境界印を認識出来る必要があります。 次に予期される印やその他の終端を確認するだけでは十分ではありません。
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".
"multipart" の "mixed" 亜型は、各本文部分が独立していて、 特定の順で束ねる必要があるときに使うことを意図しています。 実装が認識出来ない "multipart" の亜型はすべて、亜型 "mixed" であるとして扱わなければなりません。
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" と同等であるものとして 扱わなければなりません。
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.
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 This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble. If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.--unique-boundary-1
... Some text appears here ...
[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.] --unique-boundary-1
Content-type: text/plain; charset=US-ASCII This could have been part of the previous part, but
illustrates explicit versus implicit typing of body
parts. --unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64 ... base64-encoded 8000 Hz single-channel
mu-law-format audio data goes here ... --unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64... base64-encoded image data goes here ...
--unique-boundary-2--
--unique-boundary-1
Content-type: text/enriched This is <bold><italic>enriched.</italic></bold>
<smaller>as defined in RFC 1896</smaller> Isn't it
<bigger><bigger>cool?</bigger></bigger> --unique-boundary-1
Content-Type: message/rfc822 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... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--
MIME provides for a number of "multipart" types -- encapsulations of
{1945} several{2068,2616} one or more entities within a single{1945} message's Entity-Body{2068,2616} message-body.{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 は、幾つかの multipart (多部分)
型を提供しています。これを使うと、一つの message-body
に一つ以上の実体をカプセル化できます。 IANA に登録されている多部分型は、 HTTP/1.0 に対して特別な意味を持っていません。ただし利用者エージェントは各本体部分の目的を正しく解釈するために各型を理解する必要があるかもしれません。 HTTP 利用者エージェントは、多部分型を受信した時の MIME 利用者エージェントと同じか同様の振る舞いをするべきです。 HTTP サーバーは、すべての HTTP クライアントが多部分型を扱う準備ができていると仮定するべきではありません。
All multipart types share a common syntax, {2068,2616} as defined in
MIME [7]section 5.1.1 of RFC 2046 [40] , and{1945} mustMUST include a boundary parameter as part of the media type value. The message body is itself a protocol element and{1945} mustMUST therefore use only CRLF to represent line breaks between body-parts.{1945} Multipart body-parts may contain HTTP header fields which are significant to the meaning of that part.{2068,2616} Unlike inMIMERFC 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). {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 で定義されている共通の構文を共有し、
媒体型値の一部として boundary (境界) 引数を含みます。
メッセージ本体はそれ自体プロトコル要素ですから、
本体部分間の改行を表現するときには CRLF
だけを使用しなければなりません。 多部分本体部分は、その部分の意味にとって重要である HTTP 頭欄を含んでも構いません。 MIME とは異なり、多部分メッセージの epilogue (後書き) は空でなければなりません。 HTTP 応用は、 (たとえもとの多部分が後書きを含んでいたとしても) 後書きを転送してはなりません。この制限は、多部分 message-body の自己区切性を維持するために存在します。 message-body の「終了」は終了多部分境界で示します。
{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 は多部分 message-body を他の媒体型と何ら違わず、
厳密に積荷として扱います。1つの例外は multipart/byteranges
型が 206 (部分内容) 応答で使われた時で、
12.5.3節と14.16節で説明する HTTP キャッシュ機構により解釈されます。
これ以外の全ての場合には、 HTTP 利用者エージェントは、多部分型を受信した時の MIME 利用者エージェントと同じか同様の振る舞いをするべきです。
多部分 message-body の各本体部分中の MIME 頭欄は、
HTTP ではその MIME 的な意味で定義された以上の意義を持ちません。
{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 で識別できる囲まれた実体の本体部分には
Content-Location 頭欄を含めるべきです。
{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 利用者エージェントと同じか同様の振る舞いをするべきです。
応用が認識出来ない多部分亜型を受け取った場合は、
応用は 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].
注意: multipart/form-data 型が特に
POST 要求方式での処理に適当なフォーム・データ運搬のために定義されています。
これは RFC1867 で説明されています。
In
RFC 1521MIME, most header fields in multipart body-parts are generally ignored unless the field name begins with "Content-". InHTTP/1.0HTTP/1.1, multipart body-parts may contain any HTTP header fields which are significant to the meaning of that part.
MIME では、多部分本体部分中のほとんどの頭欄が、欄名が Content-
で始まらない限り通常は無視されます。 HTTP
では、多部分本体部分に、その部分の意味にとって重要な任意の
HTTP 頭欄を入れることができます。
注: この節は、 RFC 2616 では削除されています。
[58] 複数部分より多部分と訳す方がちょっといいかなあと思う今日このごろです。
[59] >>58 辞書で multi‐ の訳語を眺めてみた限りでは、全体的には多が優勢で、計算機系では他の分野より複数と訳すことがおおいもののやっぱり多が優勢な気がします。多重と訳した場合も比較的多くて、ちょっと心惹かれます。多重部分みたいな。
[60] あ、ただし、多重はほとんどすべてが multiple の訳語なんですね。だからちょっと multi(?!ple) の訳語に使うのは気がひけるというか。
[12]
複数の実体を一つの実体にまとめる方法としては、 MIME
の multipart/*
以外にも色々考案されています。
MIME 以前の RFC 934 や Encoding: 欄などはその一種ですし、
ZIP や TAR の類も広義ではその仲間です。
より狭義に、 MIME 実体をまとめた MIME 実体としては、
application/vnd.pwg-multiplexed
があります。
この形式では中身の実体を複数にぶった切って途中に別の実体を挟んだりできます。
(HTML の img 要素の直後に画像実体がくるような使い方を想定しています。)
[14]
application/vnd.oma.drm.message
は multipart/* の構文を採用しています。
[17] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) http://tools.ietf.org/html/rfc5621#section-4