多部分/替代子类型，客户端何时使用它？
为什么网络邮件（如 Gmail）使用多部分/替代子类型（以 HTML 格式撰写时）发送 MIME 邮件，而其他邮件则以 MIME 形式发送 HTML，其中包含文本/html 部分（不使用替代子类型）？
Why webmails (like Gmail) sends MIME messages using multipart/alternative subtype (when composing in HTML) while others send HTML as MIME with text/html parts inside (without using alternative subtype)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第 5.1.4 节 ://www.rfc-editor.org/rfc/rfc2046" rel="nofollow noreferrer">RFC 2046 定义
multipart/alternateMIME 类型，允许发送者提供相同消息的不同的、可互换的表示，并让接收者选择最适合的表示形式它的能力。请注意，虽然应保留每种表示形式对用户的一般含义，但从一种表示形式到另一种表示形式通常会丢失一些信息（例如text/plain缺少与相关的格式信息>文本/html）。替代方案通常应从最简单到最丰富的顺序排列，即如果替代方案再次是text/html和text/plain那么text/plain应该放在第一位。这有助于不符合 MIME 的查看器的用户，其中最容易解释的部分将首先显示。一般来说，符合 MIME 的查看器应该显示它能够查看的最后一个表示形式，因为它是最可取的。此内容类型通常与
多部分/混合形成对比，其中许多不同资源组合在一条消息中。某些邮件服务以
multipart/alternative形式提供消息的主要原因是为了支持接收端不同类型的查看应用程序。例如，某些查看器缺乏呈现 HTML 的能力，并且需要text/plain表示形式才能使消息完全可读。同时，其他查看器确实能够呈现 HTML，并且当消息以text/html形式传递时可以提供更好的用户体验。在支持广泛的观看者和增强能力更强的观看者的用户体验之间进行权衡的最灵活的解决方案是通过传递包装在multipart/alternative消息中的两种表示形式来提供。有关详细信息，请参阅 RFC 2046。
The section 5.1.4 of RFC 2046 defines
multipart/alternativeMIME type to allow the sender to provide different, interchangeable representations of the same message and to leave it up to the receiver to chose the form of presentation most suitable for its capabilities. Note that while the general meaning of each representation for the user should be retained, there usually is some information loss from one representation to the other (e.g.text/plainis missing the formatting information with respect totext/html). The alternatives should generally be ordered from the plainest to the richest, i.e. if the alternatives are againtext/htmlandtext/plainthentext/plainshould come first. This helps the users of non-MIME-conformant viewers in which the easiest to interpret part will show up first. Generally, a a MIME-conformant viewer should display the last representation it is capable of viewing since it is the most preferable.This content type is often contrasted with
multipart/mixedwhere a number of different resources are combined in a single message.The main reason some mail services provide messages as
multipart/alternativeis to support different types of viewing applications on the receiving end. For example, some viewers lack the ability to render HTML and requiretext/plainrepresentation for the message to be at all readable. At the same time, other viewers do have the ability to render HTML and can provide much better user experience when message is delivered astext/html. The most flexible solution to the trade-off between supporting wide range of viewers and enhancing user experience for the more capable ones is afforded by delivering both representations wrapped in amultipart/alternativemessage.For details see RFC 2046.
multipart/alternative表示每个部分都是相同（或相似）内容的“替代”版本，每个部分采用不同的格式，由其“Content-Type”标头表示。格式按照对原始内容的忠实程度排序，最不忠实的排在前面，最忠实的最后。像 Gmail 这样的邮件代理知道他们在做什么，并将
text/html转换为text/plain并将两种替代方案放入电子邮件中，让接收端决定哪种替代方案使用。还有一些邮件代理不知道如何从 html 内容中提取纯文本版本，只是因为开发人员没有费心去实现它，所以他们只发送
text/html出任何替代方案。有时 - 我称他们为疯狂的 - 发送
multipart/alternative，但实际上只放置text/html，没有任何替代方案。这并不是很好，但它并不违反任何规范。multipart/alternativeindicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The formats are ordered by how faithful they are to the original, with the least faithful first and the most faithful last.Mail-agents like Gmail know what they are doing, and convert the
text/htmltotext/plainand put both alternatives into there emails and let the receiving end decide which alternative to use.There are also mail-agents that don't know how to extract a text-only version from the html content, just because the developer did not bother to implement it, so they only send
text/htmlwith out any alternatives.And sometimes - i call them the crazy ones - send
multipart/alternative, but actually only put text/html without any alternatives. Which is not really nice, but it is not against any spec.