Email 解析mime电子邮件、outlook问题和差异

我正在学习一个叫做parsec的haskell解析库，为此我需要解析一封电子邮件。我一直在研究规范，比较来自不同客户的不同消息，阅读一些rfc，等等

对于这个练习，我只需要提取“From:”标题和实际的纯文本正文。 现在，所有的客户机似乎都在规范方面产生了合理的或至少是无偏差的信息。唯一的区别是前景（我并不因某些原因感到惊讶）

因此，根据myu reading，标准方法是有一个边界序列，即：

Content-Type: multipart/alternative; boundary=047d7b2e4e3cdc627304eb094bfe

然后，多部分体的所有部分都由这个边界序列分隔，对吗？ 如果我错了，请纠正我。我希望我的解析器与所有可能的客户机一起工作

因此，常见的模式是

--boundary
headers
part

--boundary
headers
part

...

现在，查看outlook生成的消息，我看到了一幅不同的图片。 它使用了一些子边界，我不知道它是否是一个标准？ 这就是前景

Content-Type: multipart/related;
    type="multipart/alternative";
    boundary="----_=_NextPart_001_01CEE199.851D3871"

那么主体是这样分隔的

------_=_NextPart_001_01CEE199.851D3871
Content-Type: multipart/alternative;
    boundary="----_=_NextPart_002_01CEE199.851D3871"

----_=_NextPart_002_01CEE199.851D3871
headers
body part

----_=_NextPart_002_01CEE199.851D3871
headers
body part

------_=_NextPart_001_01CEE199.851D3871

所以它有一个外边界和序列001，然后是一个内边界和序列002。

---

这是什么？这是微软自己的mime规范还是rfc中我错过的？解析起来更复杂。

它实际上不是一个子边界，而是一个多部分节本身可以包含多部分内容

这意味着您必须递归地解析边界，如果内容类型是multipart/alternative，那么它将包含自己的边界字符串和部分。这个字符串与另一个边界非常相似，这正是outlook所做的。它本可以完全分开

两者

及

是有效的结构

如果outlook让它看起来像

Content-Type: multipart/alternative;
    boundary="firstmessage"

--firstmessage
content-type: multipart/alternative;
    boundary="nestedpart"

--nestedpart
content-type: text/plain

nested body one

--nestedpart
content-type: text/plain

nested body two

--nestedpart--
--firstmessage
headers

second part of first message
--firstmessage--

--part
  --part
  --part
--part
--part

Content-Type: multipart/alternative;
    boundary="firstmessage"

--firstmessage
content-type: multipart/alternative;
    boundary="nestedpart"

--nestedpart
content-type: text/plain

nested body one

--nestedpart
content-type: text/plain

nested body two

--nestedpart--
--firstmessage
headers

second part of first message
--firstmessage--