2017-03-27 181 views
1

雖然使用MimeKit.eml文件轉換爲.msg文件,但我遇到了似乎與編碼有關的問題。MimeKit字符編碼/解碼問題

,用含有如下EML文件,例如:

--__NEXTPART_20160610_5EF5CF91_471687D 
Content-Type: text/plain; charset=iso-2022-jp 
Content-Transfer-Encoding: 7bit 

添付ファイル名テスト 

結果是垃圾中的主體內容:

・Y・t・t・@・C・・・シ・e・X・g 

此外,基64編碼ü字符被顯示爲??當EML文件被讀取時。我已經下載了最新版本的MimeKit,但它似乎沒有什麼區別。

使用Outlook 2016可以正常打開.eml文件,但使用MimeKit似乎無法正確讀取和解碼文件。

+0

編輯是非常... nitpicky? 我不介意,但如果我們要挑剔,我們至少可以讓挑剔一致嗎? 換句話說,MimeKit被編輯爲「MimeKit」一次,但另一個實例保留在原始字體中。 另外,。在一個實例中,eml被挑選爲'.eml',但在隨後的實例中沒有。 謝謝 –

回答

1

有與你上面MIME片段:(

Content-Transfer-Encoding: 7bit幾個問題顯然是不正確的,本書雖然這不太可能是問題(MimeKit忽略的7bit8bit值這個原因)。

最重要的,然而,這是事實,charset參數是iso-2022-jp但內容本身很顯然不是iso-2022-jp(它看起來像utf-8)。

當你拿到TextPart.Text值,MimeKit通過使用Content-Type標頭中指定的字符集轉換原始流內容來獲取該字符串。如果這是錯誤的,那麼Text屬性也將具有錯誤的值。

好消息是,TextPartGetText方法,允許您指定字符集覆蓋。

我會建議您嘗試:

var text = part.GetText (Encoding.UTF8); 

看看是否能工程。

FWIW,iso-2022-jp是一種強制日語字符變成7bit ascii格式的編碼,看起來像完整的亂碼。這是你的日文文字會是什麼樣子,如果它實際上是在iso-2022-jp

BE:IU%U%!%$%kL>%F%9%H 

這就是我知道這不是iso-2022-jp :)

更新:

最終,該解決方案將可能是這樣的:

var encodings = new List<Encoding>(); 
string text = null; 

try { 
    var encoding = Encoding.GetEncoding (part.ContentType.Charset, 
     new EncoderExceptionFallback(), 
     new DecoderExceptionFallback()); 
    encodings.Add (encoding); 
} catch (ArgumentException) { 
} catch (NotSupportedException) { 
} 

// add utf-8 as our first fallback 
encodings.Add (Encoding.GetEncoding (65001, 
    new EncoderExceptionFallback(), 
    new DecoderExceptionFallback())); 

// add iso-8859-1 as our final fallback 
encodings.Add (Encoding.GetEncoding (28591, 
    new EncoderExceptionFallback(), 
    new DecoderExceptionFallback())); 

for (int i = 0; i < encodings.Count; i++) { 
    try { 
     text = part.GetText (encodings[i]); 
     break; 
    } catch (DecoderFallbackException) { 
     // this means that the content did not convert cleanly 
    } 
} 
+0

謝謝。 .eml文件是由第三方程序創建的,所以我會跟進他們;聽起來像是他們的應用程序的問題。 –

+0

FWIW,我剛剛更新了我的答案,爲您的問題提供了一種可能的通用解決方案。 – jstedfast