【发布时间】：2012-01-09 08:18:47
【问题描述】：
为什么网络邮件（如 Gmail）使用 multipart/alternative subtype（在 HTML 中撰写时）发送 MIME 邮件，而其他邮件作为 MIME 发送 HTML，其中包含 text/html 部分（不使用替代子类型）？
【问题讨论】：
标签： email content-type mime
【发布时间】：2012-01-09 08:18:47
【问题描述】：
RFC 2046 的section 5.1.4 定义了multipart/alternative MIME 类型，以允许发送者提供相同消息的不同、可互换的表示，并由接收者选择形式最适合其功能的演示文稿。请注意，虽然应该保留每个表示对用户的一般含义，但通常会从一种表示到另一种表示中丢失一些信息（例如，text/plain 缺少与text/html 相关的格式信息）。替代品通常应该从最简单到最丰富的顺序排列，即如果替代品再次是text/html 和text/plain，那么text/plain 应该排在第一位。这有助于不符合 MIME 标准的查看器的用户，其中最容易解释的部分将首先显示。通常，符合 MIME 的查看器应该显示它能够查看的最后一个表示，因为它是最可取的。
这种内容类型通常与multipart/mixed 形成对比，multipart/mixed 将许多不同资源组合在一条消息中。
一些邮件服务提供multipart/alternative消息的主要原因是为了在接收端支持不同类型的查看应用程序。例如，一些查看器缺乏呈现 HTML 的能力，并且需要text/plain 表示才能使消息完全可读。同时，其他查看器确实具有呈现 HTML 的能力，并且当消息以text/html 传递时可以提供更好的用户体验。在支持广泛的观众和为更有能力的观众增强用户体验之间进行权衡的最灵活的解决方案是通过提供包装在multipart/alternative 消息中的两种表示。
详情见RFC 2046。
【讨论】：
multipart/alternative 表示每个部分都是相同（或相似）内容的“替代”版本，每个部分都采用不同的格式，由其“Content-Type”标头表示。这些格式按照它们对原作的忠实程度排序，最不忠实的在前，最忠实的在后。
像 Gmail 这样的邮件代理知道他们在做什么，并将 text/html 转换为 text/plain 并将两种替代方案放入其中的电子邮件中，让接收端决定使用哪个替代方案。
还有一些邮件代理不知道如何从 html 内容中提取纯文本版本，只是因为开发人员没有费心去实现它，所以他们只发送 text/html 而没有任何替代方案。
有时 - 我称他们为疯狂的 - 发送 multipart/alternative，但实际上只放置 text/html 而没有任何替代方案。这不是很好，但它不违反任何规范。
【讨论】：