0

我一直在对标准化的电子邮件格式进行一些研究/测试。最终，我希望为应用程序开发电子邮件解析器。我注意到电子邮件格式存在一些差异，主要存在于电子邮件客户端（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 如何格式化电子邮件的说明。

我想我的问题是，这是一种有效的格式吗？有什么规范吗？是否有任何众所周知/记录在案的方法来检查和解析这种类型的格式而不知道正在接收哪种类型的格式？

4

1 回答 1

0

[评论中的扩展点]

这是有效的格式吗？

是的。比严格的 7 位 ASCII 文本更复杂的邮件消息的整体框架称为 MIME。它在您的第一个示例中包含“Content-Type”标头的规范，通知客户端整个消息是 HTML 而不是纯文本。如今，许多（可能是大多数）消息在最外层属于“multipart/alternative”类型，封装了消息体的 2 个（或更多！）版本，通常是 text/plain 表示和 text/html 版本，它本身就是通常在包含嵌入图像的多部分/混合容器中。

有什么规范吗？

是的。MIME 的基础知识在 RFC 的 2045-2049 中进行了描述，并且在许多后来的 RFC 和类型注册文档中描述了许多扩展和更正。MIME 还提供了 HTTP 文档规范的核心组件，因此许多扩展几乎与电子邮件无关。

是否有任何众所周知/记录在案的方法来检查和解析这种类型的格式而不知道正在接收哪种类型的格式？

是的。虽然几乎所有现代电子邮件都是 MIME 格式，但正式地您可以通过查找“MIME-Version”标头来检测它。有关详细信息，请参阅 RFC2045。请注意，您的第一个示例没有显示该标题，但它必须存在于完整的原始文件中，否则您显示的标题将毫无意义。

这说明了为什么您可能应该重新考虑编写自己的邮件解析器的想法。您所看到的两种格式实际上并不是这样，它们只是 MIME 格式框架的不同应用。MIME 比 RFC2822 早得多（顺便说一下，R​​FC5322 本身已经过时）并且有许多成熟和强大的解析器可用。编写一个适用于大多数邮件的 MIME 解析器很容易，编写一个适用于几乎所有有效邮件的 MIME 解析器有点困难，而编写一个能够安全处理现实世界的邮件的程序是一个挑战t 完全正确，并且在某些情况下旨在以恶意方式破坏幼稚的解析器。利用在您之前数十年的编码人员被撕毁的头发：使用现有的解析器。

于 2013-12-31T03:03:01.297 回答