TIdMessageParts.CountParts返回0

我試圖拉MIME格式多部分郵件在2010年德爾福使用印10.5.5這些是我遇到的麻煩的代碼行的IMAP服務器都低於，我在那裏instatiate的curMessage對象，檢索消息到它，然後調用CountParts：TIdMessageParts.CountParts返回0

var 
    curMessage: TIdMessage; 
    IMAP4: TIdIMAP4; 
    msgIndex: Integer; 

begin 
    ... 
    curMessage := TIdMessage.Create(nil); 
    IMAP4.Retrieve(msgIndex, curMessage); 
    curMessage.MessageParts.CountParts; 
    //code that checks counts 
    //and 
end;

我然後有一些代碼，檢查curMessage.MessageParts（即TextPartCount）的各個計數特性。然而，CountPart過程不返回任何東西，因爲Count財產的程序塊引用爲0，即使我已經驗證該消息被檢索並放入curMessage。

我注意到的一件事，還沒有到底，還是IsMsgSinglePartMime回來了，儘管服務器上的所有消息都有Content-Type: multipart/mixed;。

任何幫助將非常感激。

我在這裏錯過了什麼？如果需要，我可以提供更多的代碼，

來源

2014-06-12 MCP

沒有看到實際的電子郵件數據，也很難肯定地說究竟爲什麼，你希望它是數據是沒有的。但是，如果TIdMessage.IsMsgSinglePartMime是越來越設置爲True，那麼這意味着，無論是：

TIdMessage.Encoding是meMIME但TIdMessage.MIMEBoundary.Count是0，這意味着在頂級Content-Type頭檢測到任何MIME boundary值。如果Content-Type是'multipart/...'類型，則需要boundary。如果它存在，它可能會以妨礙Indy解析它的方式變形。
TIdMessage.Encoding是mePlainText但TIdMessage.ContentTransferEncoding要麼'base64'或'quoted-printable'。

在任一情況下，如果存在體內容存在，那麼這將最終在TIdMessage.Body屬性如果是文本數據，否則將在TIdMessage.MessageParts作爲附件，而不是結束。由於TIdMessage.MessageParts.Count在你的情況下爲0，所以數據要麼在TIdMessage.Body，要麼被丟棄。

你可能要考慮upgrading to a newer Indy version。隨D2010的版本是很老，而且已經出現了近年來TIdIMAP4和TIdMessage（及其內部解析器）做出修正/改變。

來源

2014-06-13 03:26:09

謝謝，這有很大的幫助。有一個可處理的邊界，今天上午的一些進一步測試表明，一些消息正在被正確處理。只是發生在我正在處理的文件夾中的前幾條消息都有同樣的問題。我在導致問題的消息的標題中發現了換行符。 IdMessageClient.ReceiveHeader僅在換行符之前返回標題的行。我不確定這是否在後來的Indy版本中處理得更好，但聽起來像IMAP具有POP不一致的一致性問題，也許我只是遇到了這些問題。 – MCP

電子郵件標題和正文內容是由一個空行（更精確地，通過一個'CRLF + CRLF'序列，儘管印還支持'LF + LF'，'CRLF + LF'和'LF + CRLF'）分離。如果標題有額外的錯誤換行符，那麼Indy（或任何其他電子郵件解析器）都無法做到這一點。這就是電子郵件的工作原理。 –

TIdMessageParts.CountParts返回0

回答

相關問題