gre*_*emo 8 email mime content-type
为什么网络邮件(如Gmail)使用multipart/alternative子类型(在使用HTML编写时)发送MIME邮件,而其他人则将HTML作为MIME发送,其中包含text/html部分(不使用其他子类型)？
在5.1.4节的RFC 2046定义multipart/alternative的MIME类型,以允许发送者提供的不同的,可互换的表示相同的消息,并离开它的接收器以选择呈现最适合其能力的形式.请注意,虽然应保留用户的每个表示的一般含义,但是从一个表示到另一个表示通常会丢失一些信息(例如text/plain,缺少关于格式化信息的信息text/html).替代品通常应该从最普通的订购到最富裕的,即如果替代品再次出现text/html,text/plain那么text/plain应该先行.这有助于非符合MIME的查看器的用户首先显示最容易解释的部分.通常,符合MIME的查看器应显示它能够查看的最后一个表示,因为它是最优选的.
这种内容类型通常与在单个消息中组合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,但实际上只有文字/ HTML没有任何替代品.这不是很好,但它不违反任何规范.