满足HTML、电子邮件、图像和纯文本的MIME类型是什么?

26
答案:

Mail multipart/alternative vs multipart/mixed的答案建议附件应该作为 multipart/alternative 消息的对等项,例如:

  • multipart/mixed
    • multipart/alternative
      • text/plain
      • text/html
    • 一些内容 (disposition: attachment)
    • 一些内容 (disposition: attachment)
    • ...

我想发送包含一些内联图片和纯文本替代方案的html部分电子邮件。各个部分的首选MIME布局是什么?示例代码和其他问题中出现了几个选项,但哪个在实践中表现最好?我的倾向是这样的:

  • multipart/alternative
    • text/plain
    • multipart/related
      • text/html (通过cid引用图片)
      • image/gif
      • image/gif
      • ...

这样,图片就清楚地用于呈现html部分。这种布局的完整实例如下:

From: Rich Example <rich-example@example.org>
To: A Recipient <recipient@example.org>
Subject: An example of email with images and a plain alternative
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="outer-boundary"

This is a MIME-encoded message. If you are seeing this, your mail
reader is old.
--outer-boundary
Content-Type: text/plain; charset=us-ascii

This message might make you :) or it might make you :(

--outer-boundary
MIME-Version: 1.0
Content-Type: multipart/related;
  type="text/html"; start="<body@here>"; boundary="inner-boundary"

--inner-boundary
Content-Type: text/html; charset=us-ascii
Content-Disposition: inline
Content-ID: <body@here>

<html>
 <body>
  This message might make you
  <img src="cid:smile@here" alt="smile">
  or it might make you
  <img src="cid:frown@here" alt="frown">
 </body>
</html>

--inner-boundary
Content-Type: image/gif
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-ID: <smile@here>

R0lGODlhEAAQAKEBAAAAAP//AP//AP//ACH5BAEKAAIALAAAAAAQABAAAAIzlA2px6IBw2
IpWglOvTahDgGdI0ZlGW5meKlci6JrasrqkypxJr8S0oNpgqkGLtcY6hoFADs=

--inner-boundary
Content-Type: image/gif
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-ID: <frown@here>

R0lGODlhEAAQAKEBAAAAAAD//wD//wD//yH5BAEKAAIALAAAAAAQABAAAAIzlA2px6IBw2
IpWglOvTahDgGdI0ZlGW5meKlci75drDzm5uLZyZ1I3Mv8ZB5Krtgg1RoFADs=

--inner-boundary--

--outer-boundary--

1
似乎是一个精确的重复问题,它引用了以下链接:https://dev59.com/hG865IYBdhLWcg3wQMWW - james.garriss
3
意图上的轻微差异(无论我是否明确传达)可能与附件的目的有关。如果它们是用于丰富渲染(例如标志,装饰符等),它们应该在丰富替代品中吗?所引用的问题也未提及“相关”。 - Rob Starling
1个回答

10

你说得对。内联图像应该存储在一个 multipart/related 的mime实体(RFC 2387)中,并且提供多个内容类型选项可以使用 multipart/alternative(RFC 2046)来完成。
添加附件时,可以将整个结构放入 multipart/mixed 中并添加附件。

  • multipart/mixed
    • multipart/alternative
      • text/plain
      • multipart/related
        • text/html
        • image/gif
        • image/gif
    • some/thing (disposition: attachment)
    • some/thing (disposition: attachment)

你也可以在 text/plain 消息中使用内联图像,但不是所有 MUA 都支持此功能。(使用 none 或 disposition: inline)

  • multipart/mixed
    • text/plain (图像上方的文本)
    • image/gif
    • text/plain (图像下方的文本)

我不知道如何与 multipart/alternative HTML-email 结合使用。


抱歉,我认为这不正确。在multipart/alternative中只有两个项目:文本和HTML。备选项在multipart/related中。请参见:https://dev59.com/-Zzha4cB1Zd3GeqPAymI#40420648 - guettli
@guettli - 不是这样的。根据RFC1341,您可以拥有任意数量的备选项 - 您可以包含PDF版本、视频版本等等。 - dsz

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接