Indy返回某些消息的奇數內容類型。如何解決？

Question

有這種特殊類型的亞馬遜消息，似乎拋出Indy的MessagePart解析器。

該消息被構造（強烈刪節版，當然）爲這樣：

Content-Type: multipart/mixed; 
     boundary="----=_Part_853547_18414509.1354745829993" 

<some irrelevant header stuff> 

------=_Part_853547_18414509.1354745829993 
Content-Type: multipart/alternative; 
     boundary="----=_Part_853548_20128671.1354745829993" 

------=_Part_853548_20128671.1354745829993 
Content-Type: text/plain; charset=UTF-8 
Content-Transfer-Encoding: quoted-printable 

<the message in plain text> 

------=_Part_853548_20128671.1354745829993 
Content-Type: text/html; charset=UTF-8 
Content-Transfer-Encoding: quoted-printable 

<the message in HTML> 

------=_Part_853548_20128671.1354745829993-- 

------=_Part_853547_18414509.1354745829993-- 

現在，當我執行

imap.UIDRetrieve(UID,Msg) 

然後

Msg.ContentType = "multipart/mixed" 

和個人Msg.MessageParts將此作爲內容類型：

Msg.MessageParts[0].ContentType = "multipart/alternative; boundary="----=_Part_853548_20128671.1354745829993"" 

Msg.MessageParts[1].ContentType = "text/plain" 

沒有跟蹤text/html部分。

會有人知道這裏發生了什麼嗎？

（現在用最新的印地構建）

Answer 1

當我運行電子郵件數據直接作爲-是通過TIdMessage使用當前印10 SVN快照，它解析就好了。如預期的那樣，生成三個MessageParts條目 - multipart/alternative,text/plain和text/html。

對於同一主題的your recent post to the Embarcadero forum，您遺漏了一條關鍵信息 - 您正在使用TIdIMAP4來檢索那些不適合您的電子郵件。這一點很重要，因爲您認爲不相關的部分電子郵件必須包含的數據會碰到一段Indy代碼，這些代碼具有Indy 10中已知的設計限制（但已經標記爲Indy 11需要）但影響TIdIMAP4。

在內部，TIdIMAP4.UIDRetreive()將原始下載的電子郵件原樣傳遞到TIdMessage.LoadFromStream()。 TIdMessage中的核心解析器期望使用IMAP實際不使用的SMTP樣式點透明度來轉義輸入數據。 TIdMessage目前沒有任何方式可以知道輸入電子郵件數據的來源，因此也無法知道轉義數據的格式。高級協議傳輸的責任是根據需要解析和解碼轉義數據，然後將未轉義的數據傳遞給TIdMessage以供進一步解析。但現在情況並非如此。在Indy 10中，邏輯的分離並沒有達到應有的程度。 TIdMessage使用直接訪問源數據，該數據在TIdSMTP和TIdPOP3中正常工作，但在TIdIMAP4中不正常。

在IdMessageClient.pas單元，有一個名爲TIdIOHandlerStreamMsg具有公共EscapeLines屬性，它是專門爲幫助解決在需要它的情況下，這個問題（即通過非轉義的數據TIdMessage.LoadFrom...()方法）一個輔助類。而不是直接調用TIdMessage.LoadFromStream()，目前的解決辦法是實例化一個TIdMessageClient，分配TIdIOHandlerStreamMsg其IOHandler財產，其EscapeLines屬性設置爲True，並把它傳遞源TStream分析和目的地TIdMessage輸出到。這允許Indy僞造核心解析器期望忽略的轉義格式。

但是， TIdIMAP4目前尚未使用此解決方法。現在我想到了這個，應該很容易添加，所以我會研究它。與此同時，您可以使用 TIdIMAP4.RetrieveNoDecodeToStream()或 TIdIMAP4.UIDRetrieveNoDecodeToStream()，當寫入目標 TStream（另一個已知的需要修復的設計限制）時，它將間接地轉義數據，然後您可以將該 TStream傳遞給 TIdMessage.LoadFromStream()以正常解析。

更新：我剛纔已經檢查了一個更新的TIdIMAP4的AppendMsg()和InternalRetrieve()方法不再依賴SMTP式的點的透明度。這已經在Indy的TODO名單上有好幾年了，所以最終解決它是很好的。