格式化电子邮件最合适的方式是什么？答案

【问题标题】：What's the most appropriate way to format an email?格式化电子邮件最合适的方式是什么？
【发布时间】：2014-10-15 07:51:03
【问题描述】：

使用 JavaMail，我正在构建具有以下格式的消息

+------------------------------------------------+
| multipart/related                              |
| +---------------------------+  +-------------+ |
| |multipart/alternative      |  | attachments | |
| | +-----------+ +---------+ |  |             | |
| | |text/plain | |text/html| |  |             | |
| | +-----------+ +---------+ |  |             | |
| +---------------------------+  +-------------+ |
+------------------------------------------------+

ASCII 艺术归因于该问题的 OP：http://www.coderanch.com/t/503380/java/java/Java-Mail-text-html-attachment

我觉得这将是正确的格式，因为附件（图像/gif、应用程序/pdf 等）对于理解整个消息很重要。但是，我一直在做一些研究，发现经常使用multipart/mixed。

我应该用multipart/mixed 替换multipart/related 部分吗？如果是，为什么？

此格式的示例消息如下：

Content-Type: multipart/related; 
    boundary="----=_Part_6818257_562311419.1408632937947"

------=_Part_6818257_562311419.1408632937947
Content-Type: multipart/alternative; 
    boundary="----=_Part_6818256_1953685207.1408632937947"

------=_Part_6818256_1953685207.1408632937947
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This is my message!
------=_Part_6818256_1953685207.1408632937947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html><strong>This is my message!</strong></html>
------=_Part_6818256_1953685207.1408632937947--

------=_Part_6818257_562311419.1408632937947
Content-Type: application/pdf;name="document.pdf"
Content-Transfer-Encoding: base64
Content-ID: <attachment0>
X-Attachment-Id: attachment0

< insert lots of base64 encoding here >
------=_Part_6818257_562311419.1408632937947--

【问题讨论】：

这是一道编程题吗？
@Nabin 假设我们程序员在许多方面都是问题解决者，我会说，是的 :)

标签： email jakarta-mail html-email email-attachments

【解决方案1】：

经过一番搜索，我找到了这个post，这实际上符合我的关注。

根据 RFC 规范，构建电子邮件消息的最佳方式似乎是以下格式：

+-----------------------------------------------------------+
| multipart/mixed                                           |
| +--------------------------------------+  +-------------+ |
| | multipart/alternative                |  | attachments | |
| | +------------+ +-------------------+ |  |             | |
| | | text/plain | | multipart/related | |  |             | |
| | |            | | +---------------+ | |  |             | |
| | |            | | | text/html     | | |  |             | |
| | |            | | | image/gif     | | |  |             | |
| | |            | | +---------------+ | |  |             | |
| | +------------+ +-------------------+ |  |             | |
| +--------------------------------------+  +-------------+ |
+-----------------------------------------------------------+

通过这种消息配置，电子邮件客户端可以决定要显示的替代消息类型。此外，multipart/related 构成与电子邮件的消息部分相关的内容，不包括附件。

如需更多关于multipart/related 的说明，请联系from Wikipedia：

multipart/related 用于表示每个消息部分是一个聚合整体的组成部分。它用于复合对象，包括几个相互关联的组件 - 无法正确显示通过单独显示组成部分来实现。讯息由引用其他的根部分（默认情况下，第一个）组成部分内联，这又可以引用其他部分。留言部分通常由“Content-ID”部分标题引用。的语法引用未指定，而是由编码或部分使用的协议。

此子类型的一个常见用法是发送一个完整的网页单个消息中的图像。根部分将包含 HTML 文档，并使用图像标签来引用存储在后者中的图像零件。

在 RFC 2387 中定义

另一个 great article 引用 Microsoft Exchange 的解决方案。

【讨论】：