| 1 |
wakaba |
1.4 |
|
| 2 |
|
|
[2] [[MIME]] の [DFN[[CODE(MIME)[multipart/alternative]] [[媒体型]]]]は、
|
| 3 |
|
|
同じ情報の複数の[Q[代替]]となる[[表現]]を1つにまとめるために使うことができる書式です。
|
| 4 |
|
|
|
| 5 |
|
|
[3] 例えば、[[電子メイル]]の[[宛先]]が正しくないことを伝える [[DSN]]
|
| 6 |
|
|
の[[メッセージ]]で、人間向けの説明文の[[日本語]]版と[[英語]]版を同時に含めることができます。
|
| 7 |
|
|
あるいは[[アニメーション]]画像を提供する時に、
|
| 8 |
|
|
[[MNG]] 版と [[GIF]] 版を提供し、受け取った側で使える方を使ってもらうということができます。
|
| 9 |
|
|
|
| 10 |
|
|
[4]
|
| 11 |
|
|
本質的には同じものを表す複数の[[表現]]を提供する技術としては [[HTTP]]
|
| 12 |
|
|
の[[内容折衝]]が有名ですが、 [[HTTP]] は提供側 ([[鯖]])
|
| 13 |
|
|
と利用側 ([[利用者エージェント]]) が直接通信するので、
|
| 14 |
|
|
[[利用者エージェント]]が用意した情報を使って[[鯖]]側で折衝
|
| 15 |
|
|
([[表現]]の選択) を行います。それに対して[[送信者]]と[[受信者]]が時間的・空間的に離れている[[電子メイル]]では、
|
| 16 |
|
|
[[送信者]]が用意した選択肢を
|
| 17 |
|
|
[CODE(MIME)[[[multipart/alternative]]]] 形式に詰め込み、
|
| 18 |
|
|
[[受信者]]がその中から好きなものを選ぶという方法を採っています。
|
| 19 |
|
|
|
| 20 |
|
|
[5] 仕様書:
|
| 21 |
|
|
= [DEL[[[RFC 1341]] ([[MIME]] 1[SUP[st]]) ([[IETF]] [[提案標準]]) <urn:ietf:rfc:1341>]]
|
| 22 |
|
|
= [DEL[[[RFC 1521]] ([[MIME]] 2[SUP[nd]]) ([[IETF]] [[原案標準]]) <urn:ietf:rfc:1521>]]
|
| 23 |
|
|
= [DEL[[[RFC 1766]] ([CODE(MIME)[differences]] 引数) ([[IETF]] [[提案標準]]) <urn:ietf:rfc:1766>]] ([[RFC 3282]] により[[廃止]])
|
| 24 |
|
|
= [[RFC 2046]] ([[MIME]] 3[SUP[rd]]) ([[IETF]] [[原案標準]]) <urn:ietf:rfc:2046>
|
| 25 |
|
|
-- [CSECTION@en[5.1.4. Alternative Subtype]]
|
| 26 |
|
|
|
| 27 |
|
|
|
| 28 |
|
|
* 構文
|
| 29 |
|
|
|
| 30 |
|
|
[6] [CODE(MIME)[multipart/alternative]] の構文は、
|
| 31 |
|
|
他の [CODE(MIME)[[[multipart/[VAR[*]]]]]] [[媒体型]]と共通です。
|
| 32 |
|
|
[[本体]]の部分に複数の[[本体部分]]を [CODE(MIME)[[[boundary]]]]
|
| 33 |
|
|
[[引数]]で区切って並べます。
|
| 34 |
|
|
|
| 35 |
|
|
[8] 含まれる各[[本体部分]]の順序は、
|
| 36 |
|
|
後の方程[Q[オリジナル]]に近いものにします。例えば元々の [[PDF]]
|
| 37 |
|
|
版、それから作成した [[HTML]] 版、[RUBY[[[平文]]] @en[プレイン・テキスト]]版と
|
| 38 |
|
|
3つあれば、[[平文]]、 [[HTML]]、 [[PDF]] の順で並べます。
|
| 39 |
|
|
|
| 40 |
|
|
このような順序にするのは、 [[MIME]] に対応していない[[利用者エージェント]]で見た時に
|
| 41 |
|
|
(つまり[[平文]]として見た時に) できるだけ[Q[ごみ]]が[[利用者]]に見えないようにと配慮されたことによります。
|
| 42 |
|
|
|
| 43 |
|
|
[10]
|
| 44 |
|
|
テストメールです。
|
| 45 |
|
|
([[松本]] [windingbird@hotmail.com] [WEAK[2007-12-21 04:07:01 +00:00]])
|
| 46 |
|
|
|
| 47 |
|
|
|
| 48 |
|
|
[11]
|
| 49 |
|
|
上記間違えました。申し訳ありません。削除して頂けますでしょうか?
|
| 50 |
|
|
([[松本]] [windingbird@hotmail.com] [WEAK[2007-12-21 04:08:22 +00:00]])
|
| 51 |
|
|
|
| 52 |
|
|
|
| 53 |
|
|
[[#comment]]
|
| 54 |
|
|
|
| 55 |
|
|
|
| 56 |
|
|
** 引数
|
| 57 |
|
|
|
| 58 |
|
|
[7]
|
| 59 |
|
|
,引数名 ,引数値 ,既定値 ,説明 ,状態 ,出典
|
| 60 |
|
|
,[CODE(MIME)[[[boundary]]]] , ,(必須) ,境界文字列 ,[[IETF]] [[原案標準]] ,[[MIME]]
|
| 61 |
|
|
,[CODE(MIME)[[[differences]]]] , , ,違う点 ,廃止 ([[IETF]] [[提案標準]]) ,[[RFC 1766]]
|
| 62 |
|
|
|
| 63 |
|
|
[[#comment]]
|
| 64 |
|
|
|
| 65 |
|
|
|
| 66 |
|
|
* 仕様書から
|
| 67 |
|
|
|
| 68 |
|
|
|
| 69 |
|
|
** RFC 2046 (MIME 3[SUP[rd]]) 5.1.4. Alternative Subtype
|
| 70 |
|
|
|
| 71 |
|
|
> The "multipart/alternative" type is syntactically identical to
|
| 72 |
|
|
"multipart/mixed", but the semantics are different. In particular,
|
| 73 |
|
|
each of the body parts is an "alternative" version of the same
|
| 74 |
|
|
information.
|
| 75 |
|
|
|
| 76 |
|
|
[DFN[[CODE(MIME)[multipart/alternative]]]] 型は構文的には
|
| 77 |
|
|
[CODE(MIME)[[[multipart/mixed]]]] と同じですが、
|
| 78 |
|
|
意味的には異なります。特に、
|
| 79 |
|
|
各[[本体部分]]は同じ情報の[Q[代替]]版とします。
|
| 80 |
|
|
|
| 81 |
|
|
> Systems should recognize that the content of the various parts are
|
| 82 |
|
|
interchangeable. Systems should choose the "best" type based on the
|
| 83 |
|
|
local environment and references, in some cases even through user
|
| 84 |
|
|
interaction. As with "multipart/mixed", the order of body parts is
|
| 85 |
|
|
significant. In this case, the alternatives appear in an order of
|
| 86 |
|
|
increasing faithfulness to the original content. In general, the
|
| 87 |
|
|
best choice is the LAST part of a type supported by the recipient
|
| 88 |
|
|
system's local environment.
|
| 89 |
|
|
|
| 90 |
|
|
システムは各[[部分]]の[[内容]]は交換可能であることを認識するべきです。
|
| 91 |
|
|
システムは局所環境や場合によっては[[利用者]]との[[対話]]にも基づき、
|
| 92 |
|
|
[Q[最善]]な型を選ぶべきです。 [CODE(MIME)[[[multipart/mixed]]]]
|
| 93 |
|
|
と同じように[[本体部分]]の順序は意味を持ちます。この場合、
|
| 94 |
|
|
各選択肢は元の内容への忠実度の順に並べます。
|
| 95 |
|
|
通常、受信システムの局所環境で対応している型の'''最後'''の[[部分]]を選ぶのが最良です。
|
| 96 |
|
|
|
| 97 |
|
|
> "Multipart/alternative" may be used, for example, to send a message
|
| 98 |
|
|
in a fancy text format in such a way that it can easily be displayed anywhere:
|
| 99 |
|
|
|
| 100 |
|
|
[CODE(MIME)[multipart/alternative]] は例えば装飾付きの文章書式で[[メッセージ]]を送る時にどこでも簡単に表示できるようにするために使うことができます。
|
| 101 |
|
|
|
| 102 |
|
|
>
|
| 103 |
|
|
[PRE(822 example code)[
|
| 104 |
|
|
From: Nathaniel Borenstein <nsb@bellcore.com>
|
| 105 |
|
|
To: Ned Freed <ned@innosoft.com>
|
| 106 |
|
|
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
|
| 107 |
|
|
Subject: Formatted text mail
|
| 108 |
|
|
MIME-Version: 1.0
|
| 109 |
|
|
Content-Type: multipart/alternative; boundary=boundary42
|
| 110 |
|
|
--boundary42
|
| 111 |
|
|
Content-Type: text/plain; charset=us-ascii
|
| 112 |
|
|
... plain text version of message goes here ...
|
| 113 |
|
|
--boundary42
|
| 114 |
|
|
Content-Type: text/enriched
|
| 115 |
|
|
... RFC 1896 text/enriched version of same message
|
| 116 |
|
|
goes here ...
|
| 117 |
|
|
--boundary42
|
| 118 |
|
|
Content-Type: application/x-whatever
|
| 119 |
|
|
... fanciest version of same message goes here ...
|
| 120 |
|
|
--boundary42--
|
| 121 |
|
|
]PRE]
|
| 122 |
|
|
|
| 123 |
|
|
[PRE[
|
| 124 |
|
|
In this example, users whose mail systems understood the
|
| 125 |
|
|
"application/x-whatever" format would see only the fancy version,
|
| 126 |
|
|
while other users would see only the enriched or plain text version,
|
| 127 |
|
|
depending on the capabilities of their system.
|
| 128 |
|
|
]PRE]
|
| 129 |
|
|
|
| 130 |
|
|
[PRE[
|
| 131 |
|
|
In general, user agents that compose "multipart/alternative" entities
|
| 132 |
|
|
must place the body parts in increasing order of preference, that is,
|
| 133 |
|
|
with the preferred format last. For fancy text, the sending user
|
| 134 |
|
|
agent should put the plainest format first and the richest format
|
| 135 |
|
|
last. Receiving user agents should pick and display the last format
|
| 136 |
|
|
they are capable of displaying. In the case where one of the
|
| 137 |
|
|
alternatives is itself of type "multipart" and contains unrecognized
|
| 138 |
|
|
sub-parts, the user agent may choose either to show that alternative,
|
| 139 |
|
|
an earlier alternative, or both.
|
| 140 |
|
|
]PRE]
|
| 141 |
|
|
|
| 142 |
|
|
[PRE[
|
| 143 |
|
|
NOTE: From an implementor's perspective, it might seem more sensible
|
| 144 |
|
|
to reverse this ordering, and have the plainest alternative last.
|
| 145 |
|
|
However, placing the plainest alternative first is the friendliest
|
| 146 |
|
|
possible option when "multipart/alternative" entities are viewed
|
| 147 |
|
|
using a non-MIME-conformant viewer. While this approach does impose
|
| 148 |
|
|
some burden on conformant MIME viewers, interoperability with older
|
| 149 |
|
|
mail readers was deemed to be more important in this case.
|
| 150 |
|
|
]PRE]
|
| 151 |
|
|
|
| 152 |
|
|
[PRE[
|
| 153 |
|
|
It may be the case that some user agents, if they can recognize more
|
| 154 |
|
|
than one of the formats, will prefer to offer the user the choice of
|
| 155 |
|
|
which format to view. This makes sense, for example, if a message
|
| 156 |
|
|
includes both a nicely- formatted image version and an easily-edited
|
| 157 |
|
|
text version. What is most critical, however, is that the user not
|
| 158 |
|
|
automatically be shown multiple versions of the same data. Either
|
| 159 |
|
|
the user should be shown the last recognized version or should be
|
| 160 |
|
|
given the choice.
|
| 161 |
|
|
]PRE]
|
| 162 |
|
|
|
| 163 |
|
|
[PRE[
|
| 164 |
|
|
THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a
|
| 165 |
|
|
"multipart/alternative" entity represents the same data, but the
|
| 166 |
|
|
mappings between the two are not necessarily without information
|
| 167 |
|
|
loss. For example, information is lost when translating ODA to
|
| 168 |
|
|
PostScript or plain text. It is recommended that each part should
|
| 169 |
|
|
have a different Content-ID value in the case where the information
|
| 170 |
|
|
content of the two parts is not identical. And when the information
|
| 171 |
|
|
content is identical -- for example, where several parts of type
|
| 172 |
|
|
"message/external-body" specify alternate ways to access the
|
| 173 |
|
|
identical data -- the same Content-ID field value should be used, to
|
| 174 |
|
|
optimize any caching mechanisms that might be present on the
|
| 175 |
|
|
recipient's end. However, the Content-ID values used by the parts
|
| 176 |
|
|
should NOT be the same Content-ID value that describes the
|
| 177 |
|
|
"multipart/alternative" as a whole, if there is any such Content-ID
|
| 178 |
|
|
field. That is, one Content-ID value will refer to the
|
| 179 |
|
|
"multipart/alternative" entity, while one or more other Content-ID
|
| 180 |
|
|
values will refer to the parts inside it.
|
| 181 |
|
|
]PRE]
|
| 182 |
|
|
|
| 183 |
|
|
|
| 184 |
|
|
* "difference" パラメーター
|
| 185 |
|
|
|
| 186 |
|
|
RFC 1766 が定義していました。 multipart/alternative
|
| 187 |
|
|
で選択肢になっている各部分の差異について指定します。
|
| 188 |
|
|
|
| 189 |
|
|
RFC 1766 では値として、 one or more 個の "Content-Type" / "Content-Language"
|
| 190 |
|
|
/ iana-token が指定できるとされています。値は RFC
|
| 191 |
|
|
として出版されている頭領域名でなければなりません。
|
| 192 |
|
|
従って、値の大文字・小文字は区別しないのでしょう(明記されては
|
| 193 |
|
|
いません)。
|
| 194 |
|
|
|
| 195 |
|
|
「more」個の値を指定する例が示されていないので、どうするのか
|
| 196 |
|
|
わかりませんが、読点 (comma) 区切りと解するのが適当でしょうか。
|
| 197 |
|
|
|
| 198 |
|
|
RFC 1766 を廃止する RFC 3282 では、 differences
|
| 199 |
|
|
パラメーターは実際には使われなかったとして、
|
| 200 |
|
|
differences パラメーターも廃止しています。
|
| 201 |
|
|
|
| 202 |
|
|
値は IANA に登録することになってますが、それっぽい登録簿は
|
| 203 |
|
|
無いみたいです。
|
| 204 |
|
|
|
| 205 |
|
|
* 歴史
|
| 206 |
|
|
|
| 207 |
|
|
** RFC 1766
|
| 208 |
|
|
|
| 209 |
|
|
[REFS[
|
| 210 |
|
|
- [14] [CITE@en[RFC 1766 - Tags for the Identification of Languages]]
|
| 211 |
|
|
<http://tools.ietf.org/html/rfc1766#section-4>
|
| 212 |
|
|
]REFS]
|
| 213 |
|
|
|
| 214 |
|
|
* 関連
|
| 215 |
|
|
|
| 216 |
|
|
[9] [CODE(MIME)[[[Content-ID]]:]]
|
| 217 |
|
|
欄は[[実体]]の[[一意]]な識別子を与えるもので、
|
| 218 |
|
|
通常は[[実体]]ごとに異なるものとしなければなりませんが、
|
| 219 |
|
|
[CODE(MIME)[[[multipart/alternative]]]] 内の各[[本体部分]]の
|
| 220 |
|
|
[CODE(MIME)[Content-ID]] は同じものでも構わないとされています。
|
| 221 |
|
|
|
| 222 |
|
|
* メモ
|
| 223 |
|
|
|
| 224 |
|
|
[1]
|
| 225 |
|
|
引数 [CODE(MIME)[[[differences]]]]
|
| 226 |
|
|
と似たようなのが [CODE(HTTP)[[[URI:]]]] 欄にもあったっけ。
|
| 227 |
|
|
|
| 228 |
|
|
[12] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
|
| 229 |
|
|
([TIME[2009-09-12 07:37:40 +09:00]] 版)
|
| 230 |
|
|
<http://tools.ietf.org/html/rfc5621#section-4>
|
| 231 |
|
|
|
| 232 |
|
|
[13] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]]
|
| 233 |
|
|
([TIME[2009-09-12 07:37:40 +09:00]] 版)
|
| 234 |
wakaba |
1.3 |
<http://tools.ietf.org/html/rfc5621#section-6> |
Parent Directory
| 
Revision Log