2017-03-27 127 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