2

在使用MimeKit将.eml文件转换为.msg文件时，我遇到了一个似乎与编码有关的问题。

例如，使用包含以下内容的 EML 文件：

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

添付ファイル名テスト

结果是正文内容中的垃圾：

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

此外，读取 EML 文件时ü会显示base-64 编码字符。??我已经下载了最新版本的 MimeKit，但似乎并没有什么不同。

.eml 文件可以使用 Outlook 2016 正确打开，但使用 MimeKit 似乎无法正确读取和解码文件。

4

1 回答 1

2

您的上述 MIME 片段存在一些问题 :(

Content-Transfer-Encoding: 7bit显然不是真的，尽管这不太可能是问题（MimeKit 忽略7bitand的值正是8bit出于这个原因）。

然而，最重要的是，charset 参数是iso-2022-jp，但内容本身显然不是iso-2022-jp（看起来像utf-8）。

当您获取该TextPart.Text值时，MimeKit 通过使用Content-Type标头中指定的字符集转换原始流内容来获取该字符串。如果这是错误的，那么该Text属性也将具有错误的值。

好消息是它TextPart具有允许您指定字符集覆盖的GetText方法。

我建议尝试：

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

看看这是否有效。

FWIWiso-2022-jp是一种将日文字符强制转换为 7 位 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
    }
}
于 2017-03-27T18:27:26.690 回答