解析MIME電子郵件，outlook問題和差異

我正在學習一個名爲parsec的haskell解析庫，爲此我需要解析一封電子郵件。我一直在研究規格，比較不同客戶的不同消息，閱讀一些rfc等。解析MIME電子郵件，outlook問題和差異

對於本練習，我需要的是提取「From：」標題和實際的純文本正文。現在，所有的客戶似乎都會產生理智或至少沒有偏離規格的信息。唯一的區別是前景（我不爲某些原因感到驚訝）。

所以standad方式，根據MYU閱讀是有邊界序列說：

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

，然後所有的多體的部分由這個邊界序列界定，對不對？請糾正我，如果我錯了。我希望我的解析器能夠與所有可能的客戶端一起工作。

所以常用的模式是

--boundary 
headers 
part 

--boundary 
headers 
part 

...

現在，看着前景產生的消息，我看到不同的畫面。它使用某種分界線，我不明白它是否是標準的？這是展望變種

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 那麼這是什麼？這是某種微軟自己的默認規格，還是在我錯過的rfc中？這是更復雜的解析。

來源

2013-11-15 r.sendecky

這不是一個真正的子邊界，而是多部分本身可以包含多部分內容。

這意味着你必須遞歸地解析邊界，如果內容類型是multipart/alternative，那麼它將包含它自己的邊界字符串和部分。這個字符串與其他邊界非常相似的事實就是Outlook的做法。它本來可以完全分開。

兩個

--part 
--part 
--part

和

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

是有效的結構。

如果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--

這可能是更明顯

來源

2013-11-18 12:29:20

解析MIME電子郵件，outlook問題和差異

回答

相關問題