Fatal编程技术网
  • email/
  • Email 来自邮件客户端的电子邮件格式设置

Email 来自邮件客户端的电子邮件格式设置

email

Email 来自邮件客户端的电子邮件格式设置,email,format,standards,rfc2822,Email,Format,Standards,Rfc2822,我一直在对标准化的电子邮件格式进行研究/测试。最终，我希望为应用程序开发一个电子邮件解析器。我注意到电子邮件的格式有一些不同，主要是在电子邮件客户端（gmail、mac mail等）和电子邮件营销服务（持续联系、邮件黑猩猩等）之间 我对格式（）的理解是，\n\n将标题与正文分开。这些似乎与从电子邮件营销服务收到的电子邮件一致。然而，电子邮件客户端似乎有一组额外的邮件标题或说明。请参阅下面的电子邮件字符串示例。请注意，我通过电子邮件管道拉这些字符串。还要注意，这些只是标题/正文拆分的片段 电子邮件

我一直在对标准化的电子邮件格式进行研究/测试。最终，我希望为应用程序开发一个电子邮件解析器。我注意到电子邮件的格式有一些不同，主要是在电子邮件客户端（gmail、mac mail等）和电子邮件营销服务（持续联系、邮件黑猩猩等）之间

我对格式（）的理解是，
\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%;}
您可以看到，在本例中，还有一组额外的“标题”，它们似乎是关于Mac Mail如何格式化电子邮件的说明

我想我的问题是，这是一种有效的格式吗？上面有什么规格吗？在不知道接收到哪种类型的格式的情况下，是否有任何已知/记录在案的方法来检查和分析这种格式？

[扩展评论中的观点]

这是有效的格式吗

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

上面有什么规格吗

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

是否有任何已知/记录的方法来检查和分析此问题 不知道接收的格式类型的格式类型

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

这说明了为什么您可能应该重新考虑编写自己的邮件解析器。实际上，您看到的2种格式并不是这样，它们只是MIME格式框架的不同应用程序。MIME比RFC2822（顺便说一句，RFC2822本身已经过时）要古老得多，并且有许多成熟而健壮的解析器可用。编写一个适用于大多数邮件的MIME解析器很容易，编写一个适用于几乎所有有效邮件的MIME解析器要稍微困难一些，编写一个能够安全处理现实邮件世界的MIME解析器也很困难，因为现实邮件世界往往不完全正确，在某些情况下，它的设计目的是以恶意方式破坏幼稚的解析器。利用在你之前工作了几十年的程序员的经验：使用现有的解析器

您需要查看多个其他RFC，如RFC2045-2047（MIME编码），以及它们如何描述多部分消息。我假设您的第二个片段不包括内容类型：multipart/mixed；boundary=苹果邮件=_28DD752B-7960-48 8D-994F-DA9408FCA880，我希望看到这是其中的一部分（您可以有多个子部分，每个子部分都符合RFC2822规则）。正确和完整的电子邮件解析是困难的。允许的内容遍布各地。请注意此链接，它引用了许多与电子邮件相关的RFC:@Joe-Content Type:multipart/alternative。我不确定这是否有什么不同，但我正在浏览您提供的RFC参考资料，看看是否可以了解更多。作为几个强大的电子邮件解析器（GMime、MimeKit、Camel等）的作者-请不要实现您自己的解析器/生成器，除非您致力于正确实现所有内容，而不是另一个又快又脏的解析器，这只会让编写真正的解析器的工作变得更加困难，因为有太多人编写的解析器/生成器出错得太厉害。 
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.