基于 rfc 2231 的 Mime 标头中解码字符集 iso-2022-jp 的文件名时出现问题

Question

在javamail中，我将mail.mime.decodeparameter 设置为true。我有附件的 Mimeheader，如下所示。

Content-Type: image/png;
 name*0*=ISO-2022-JP''%1B%24B%24%22%24%24%24%26%24%28%24*%24%22%24%24%24%26;
 name*1*=%24%28%24*%24%22%24%24%24%26%24%28%24*%24%22%24%24%24%26%24%28;
 name*2*=%24*%1B%28B.png
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename*0*=ISO-2022-JP''%1B%24B%24%22%24%24%24%26%24%28%24*%24%22%24%24;
 filename*1*=%24%26%24%28%24*%24%22%24%24%24%26%24%28%24*%24%22%24%24%24;
 filename*2*=%26%24%28%24*%1B%28B.png

使用 part.getFileName（） 获取文件名时，文件名未正确呈现。文件名呈现如下。

あいうえおあいう$&$($*$"$$$&$($*$"$$$&$($*.png

但实际文件名是あいうえおあいうえおあいうえお

あいうえお.png。

当我调试javamail的源代码时，在参数列表中.java在decodeBytes（）方法中，当编码的字符串被拆分时，返回值pf继续参数的损坏字符串。我认为当拆分双字节字符集（例如 iso-2022-jp）时，它会在 javamail 中返回损坏的字符串。我是否正确？或者请建议我解决此问题的解决方法。

Answer 1

虽然在

RFC 2231 规范中并不明确，但由于参数的每个部分都可以控制该部分是否编码，这意味着每个部分的编码独立于其他部分的编码，因此可以独立解码这些部分。 在与规范的作者核实后，我确定这不一定是真的。 因此，这看起来像JavaMail中的一个错误。 该修复看起来并不平凡。