Question

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

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

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

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

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

所以常见的模式是

--boundary
headers
part

--boundary
headers
part

...

现在，看一下outlook生成的消息，我看到了不同的画面。它使用某种子边界，我不明白它是否是一个标准？这是outlooks变种

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？解析起来比较复杂。

Answer 1

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

这意味着你必须以递归方式解析边界，如果内容类型是multipart / alternative，那么它将包含它自己的边界字符串和部分。这个字符串与另一个边界非常相似的事实就是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--

解析哑剧邮件，前景问题和差异

1 个答案: