1

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

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

所以根据myu阅读的标准方法是有一个边界序列说：

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？这更难解析。

4

1 回答 1

2

它并不是真正的子边界，而是多部分部分本身可以包含多部分内容。

这意味着您必须递归解析边界，如果内容类型是多部分/替代，那么它将包含它自己的边界字符串和部分。该字符串与其他边界非常相似的事实只是 Outlook 所做的。它本可以完全分开。

两个都

--part
--part
--part

和

--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--
于 2013-11-18T12:29:20.997 回答