[1] MIME の multipart/related
媒体型は、関連する実体を1つにまとめるための仕組みです。
HTML 文書とその中で参照されている画像のように、
意味的に1つの文書であっても物理的には複数の実体で表されていることがよくあります。
そのような場合を MIME で統一的に扱うために
multipart/related が開発されました。
[16] HTMLメールの形式として広く利用されています。それ以外の用途でも MIME や HTTP でしばしば利用されますが、広く受け入れられた用法は無いようです。
Message-Context) <urn:ietf:rfc:3458>Content-Disposition
handling 引数) <urn:ietf:rfc:3459>[3] 構文は MIME の multipart/*
共通のものを使用しています。
[5] multipart/related 内の本体部分の中で中心的な役割を果たすのが根 (開始) 部分
です。根は 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] 実例のあるもの:
type | start-info | 説明 | 状態 | 出典 |
|---|---|---|---|---|
multipart/alternative | IETF 標準化過程 | [MHTML] | ||
application/beep+xml | BEEP 弾頭 | IETF 標準化過程 (例) | [APEX] (例) | |
text/calendar | iCalendar 添付 | IETF 標準化過程 (例) | [iCal] (例) | |
application/dicom | DICOM | IETF 情報提供 | [DICOM] | |
text/directory | ディレクトリ | IETF 標準化過程 | [Directory] | |
text/html | HTML文書 | IETF 標準化過程 | [MHTML], [CID] (例) | |
application/sdp | セッション記述 | IETF 標準化過程 (例) | [PINT] | |
message/tracking-status | メッセージ追跡状況 | IETF 提案標準 | [MTQP] | |
application/vnd.pwg-xhtml-print | XHTML文書 | IETF 情報提供 (例) | [Multiplexed] | |
applicatiin/xml | SOAP/BEEP | IETF 提案標準 | [SOAP/BEEP] | |
text/xml | SOAP 添付 | W3C 会員提出 Note | [SOAP Attach] | |
application/xop+xml | 根部分の媒体型 type 引数と同じ | XOP | W3C 勧告 | [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>
If you have metadata that you want to send along with the data to upload, you can make a single multipart/related 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.