我一直在对标准化电子邮件格式进行一些研究/测试。最后，我希望为应用程序开发一个电子邮件解析器。我注意到电子邮件格式的一些差异，主要是电子邮件客户端（gmail，mac mail等）和电子邮件营销服务（Constant Contact，Mail Chimp等）。
我对格式（RFC2822）的理解是\n\n将标题与正文分开。这些似乎与从电子邮件营销服务收到的电子邮件一致。但是，电子邮件客户端似乎有一组额外的标题或消息说明。请参阅以下电子邮件字符串示例请注意，我通过电子邮件管道提取这些字符串。另请注意，这些只是标题/正文拆分的片段。
电子邮件营销服务：
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<head>
<title>Welcome to Banana Republic. Enjoy 25% off! </title>
<STYLE type="text/css">
.ReadMsgBody
{ width: 100%;}
.ExternalClass
{width: 100%;}
在这里，您将看到将标题与正文分开的换行符。根据格式都很好。现在看一下电子邮件客户端。
电子邮件客户端：
Mime-Version: 1.0 (Mac OS X Mail 7.0 (1816))
X-Mailer: Apple Mail (2.1816)
--Apple-Mail=_28DD752B-7960-488D-994F-DA9408FCA880
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Testing Mac Mail. This is the body.
在这种情况下，您会看到另外一组“标题”，这些标题似乎是关于在这种情况下Mac Mail如何格式化电子邮件的说明。
我想我的问题是，这是一种有效的格式吗？它有什么规格吗？是否有任何众所周知/记录的方法来检查和解析这种类型的格式，而不知道正在接收哪种格式？
答案 0 :(得分：0)
[在评论中提出要点]
这是一种有效的格式吗？
是。邮件消息的整体框架比严格的7位ASCII文本更复杂，称为MIME。它包含第一个示例中“Content-Type”标头的规范，该标头通知客户端整个消息是HTML而不是纯文本。这些天的许多（可能是大多数）消息在最外层都是“multipart / alternative”类型，封装了消息体的2个（或更多！）版本，最常见的是text / plain表示和text / html版本，它本身就是通常在包含嵌入图像的多部分/混合容器内。
有没有任何规格？
是。 RFC的2045-2049中描述了MIME的基础知识，并且在许多后来的RFC和类型注册文档中描述了许多扩展和更正。 MIME还提供了HTTP文档规范的核心组件，因此许多扩展几乎与电子邮件无关。
是否有任何众所周知/记录的方法来检查和解析此问题 不知道正在接收哪种格式的格式类型？
是。虽然几乎所有现代电子邮件都是MIME格式，但正式地，您可以通过查找“MIME-Version”标头来检测它。有关详细信息，请参阅RFC2045。请注意，您的第一个示例并未显示该标题，但它必须已存在于完整原始标题中，否则您显示的标题将毫无意义。
这说明了为什么你应该重新考虑编写自己的邮件解析器的想法。您看到的2种格式实际上并不是这样，而是它们只是MIME格式框架的不同应用程序。 MIME远远超过RFC2822（顺便提一下，它本身已被RFC5322淘汰），并且有许多成熟且强大的解析器可用。编写一个适用于大多数邮件的MIME解析器很容易，编写一个适用于几乎所有有效邮件的MIME解析器，并且编写一个能够安全地处理邮件真实世界的精通版本也很容易。完全正确，在某些情况下旨在以恶意方式打破天真的解析器。充分利用数十年前编码器的撕裂头发：使用现有的解析器。