[1] MIME の multipart/related 媒体型は、関連する実体を1つにまとめるための仕組みです。 HTML 文書とその中で参照されている画像のように、 意味的に1つの文書であっても物理的には複数の実体で表されていることがよくあります。 そのような場合を MIME で統一的に扱うために multipart/related が開発されました。

[16] HTMLメールの形式として広く利用されています。それ以外の用途でも MIME や HTTP でしばしば利用されますが、広く受け入れられた用法は無いようです。

仕様書

構文

[3] 構文は MIME の multipart/* 共通のものを使用しています。

[5] multipart/related 内の本体部分の中で中心的な役割を果たすのが根root (開始start) 部分 です。根は start 引数で指定されますが、 引数が省略されれば一番最初の本体部分の実体となります。

[7] multipart/related が入れ子になることも認められています RFC-REL。

引数

[4] multipart/related には次の引数があります。
引数名引数値既定値説明状態出典
boundary(必須)多部分境界IETF 原案標準MIME
start内容ID(最初の実体)根実体IETF 原案標準[RFC-REL]
start-info追加情報IETF 原案標準[RFC-REL]
type媒体型(必須)根媒体型IETF 原案標準[RFC-REL]

multipart/related の定義 RFC-REL には明記されていませんが、当然 boundary 引数が必要なはずです。

意味

[6] multipart/related 実体 (に含まれる各本体部分) の意味の解釈・レンダリングは type 引数によって識別される媒体型によります。

[7] Content-Disposition との関係: 第2版の RFC 2112 以後 Content-Disposition との関係も規定されています。 Content-Disposition の配置型 (inline や attachment) は、 multipart/related 未対応の利用者エージェントのために指定できますが、 multipart/related 対応の利用者エージェントは無視しなければなりません (レンダリングは type 引数で指定された媒体型の側で決まります)。 しかし、 filename 引数などの情報は利用して構いません。

応用

[10] multipart/related の中には (根部分も含めて) 任意の媒体型を使うことができます。登録簿や審査も特にありません。 しかし、解釈・レンダリングのされ方を統一したり、 start-info 引数を実用的にしたりするためには何らかの標準が必要です。 multipart/related の定義 RFC-REL では媒体型登録の時に説明するのがいいと言っています。

[8] 実例のあるもの:
typestart-info説明状態出典
multipart/alternativeIETF 標準化過程[MHTML]
application/beep+xmlBEEP 弾頭IETF 標準化過程 (例)[APEX] (例)
text/calendariCalendar 添付IETF 標準化過程 (例)[iCal] (例)
application/dicomDICOMIETF 情報提供[DICOM]
text/directoryディレクトリIETF 標準化過程[Directory]
text/htmlHTML文書IETF 標準化過程[MHTML], [CID] (例)
application/sdpセッション記述IETF 標準化過程 (例)[PINT]
message/tracking-statusメッセージ追跡状況IETF 提案標準[MTQP]
application/vnd.pwg-xhtml-printXHTML文書IETF 情報提供 (例)[Multiplexed]
applicatiin/xmlSOAP/BEEPIETF 提案標準[SOAP/BEEP]
text/xmlSOAP 添付W3C 会員提出 Note[SOAP Attach]
application/xop+xml根部分の媒体型 type 引数と同じXOPW3C 勧告[XOP]

出典:

よくある間違い

[13] multipart/related の type 引数は必須ですが、省略されることがあります。 そういう例を出している RFC まであります PINT。 値は媒体型 (引数なし) ですが、媒体型 (狭義) を省略して媒体亜型だけしか指定していない例を出している RFC があります MTQP。媒体型 (狭義) と媒体亜型の間の / は tspecials に含まれるので、 token に含めることができません。つまり、 type 引数は常に引用符で括った引用文字列でなければなりませんが、 そうでない例を出している RFC があります。

[14] multipart/related と Content-ID や cid: URI が併用されることはよくありますが (>>11)、 その時に内容ID として不正な URI参照を使うことがあります。 そういう例を出している RFC や W3C 勧告 XOP まであります。

[19] RFC 6047 - iCalendar Message-Based Interoperability Protocol (iMIP) ( 版) http://tools.ietf.org/html/rfc6047#section-4.3

ここに示されている例は multipart/related を type なしで使っています。

不適切なメッセージへの対処

[15] 本来 multipart/related を使うべきではないのに、誤って multipart/related が使われることがあります。例えば根メッセージが text/plain だとすると、 他の本体部分への参照は含まれ得ませんから、 間違って multipart/related と札付けされてしまっていると思われます。

このような場合、利用者がメッセージ内の情報にアクセスできないと不便です。 根メッセージの媒体型が (multipart/related で使うものとして) 対応しているもの以外であれば、 利用者エージェントは知らないものとして (つまり multipart/mixed のように) 処理するべきです。また、そうでない場合であっても、 根メッセージ以外を表示する手段を利用者エージェントの界面として用意しておくと便利でしょう。

関連

[9] RFC 1867 (HTML フォームによるファイルのうp) は、 multipart/form-data は用法と応用が随分 multipart/related とは異なるから使わなかったと述べています RFC 1867 5.11。

[10] application/vnd.pwg-multiplexed は multipart/related と似たような目的の異なった構文を持つ媒体型です。

[11] multipart/related 内の各実体を相互に参照する方法は特別には規定されていませんが、 cid: URI scheme を使って実体の Content-ID によって参照する方法が良く採られます。

[12] multipart/related を MIME で転送する場合、 MIME の規定により Content-Transfer-Encoding を使ってはいけません (Base64 などを使うことはできません)。 multipart/related の中身の各実体には使用できます。

メモ

[17] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) http://tools.ietf.org/html/rfc5621#section-7

[18] XForms 1.1 ( 版) http://www.w3.org/TR/2009/REC-xforms-20091020/#serialize-multipart

[20] WICD Mobile 1.0 ( ( 版)) http://www.w3.org/TR/WICDMobile/#packaging

[21] WICD Mobile 1.0 ( ( 版)) http://www.w3.org/TR/WICDMobile/#packaging

[22] draft-gregorio-atompub-multipart-04 - AtomPub Multipart Media Resource Creation ( ( 版)) https://tools.ietf.org/html/draft-gregorio-atompub-multipart-04

[23] RFC 4662 - A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists ( ( 版)) http://tools.ietf.org/html/rfc4662#section-5

[24] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( ( 版)) http://tools.ietf.org/html/rfc5621#section-7

[25] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( ( 版)) http://tools.ietf.org/html/rfc5621#section-8.2

[26] Loading Data Into BigQuery - Google BigQuery — Google Cloud Platform ( ( 版)) https://cloud.google.com/bigquery/loading-data-into-bigquery

[27] Loading Data with a POST Request - Google BigQuery — Google Cloud Platform ( ( 版)) https://cloud.google.com/bigquery/loading-data-post-request

[28] Upload Files - Drive REST API — Google Developers ( 版) https://developers.google.com/drive/web/manage-uploads

[29] Chrome では multipart/related へのリンクが (204 応答のように) 無反応になります。何か条件次第で開けるのかもしれません。

[30] HTMLメールでmultipart/relatedパートを入れないとGmailなどの受信側でDKIM認証が失敗する - igreks開発日記 ( 版) http://www.igreks.jp/dev/2014/11/htmlmultipartrelatedgmaildkim.html

[31] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) https://tools.ietf.org/html/rfc5621

[32] Loading Data with a POST Request - BigQuery — Google Cloud Platform (Google 著, 版) https://cloud.google.com/bigquery/loading-data-post-request

If you have metadata that you want to send along with the data to upload, you can make a single multipart/related request.

[33] Loading Data with a POST Request - BigQuery — Google Cloud Platform (Google 著, 版) https://cloud.google.com/bigquery/loading-data-post-request

The body of the request is formatted as a multipart/related content type [RFC2387] and contains exactly two parts. The parts are identified by a boundary string, and the final boundary string is followed by two hyphens.

Each part of the multipart request needs an additional Content-Type header:

Metadata part: Must come first, and Content-Type must match one of the accepted metadata formats.

Media part: Must come second, and Content-Type must match one the method's accepted media MIME types.

See the API reference for each method's list of accepted MIME types and size limits for uploaded files.