基于RFC2231的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的源代码时，在decodeBytes()方法的ParameterList.java中，当编码的字符串被拆分时，对于pf延续参数值，返回损坏的字符串。我认为当像iso-2022-jp这样的双字节字符集被拆分时，它会在javamail中返回损坏的字符串。我说的对不对？或者，请建议我解决此问题。

Answer 1

虽然在RFC 2231 spec中并不是很清楚，因为参数的每个部分都可以控制是否对该部分进行编码，但这意味着每个部分的编码独立于其他部分的编码，因此可以独立地对部分进行解码。在与规范的作者核实后，我确定这不一定是真的。因此，这看起来像是JavaMail中的一个错误。修复看起来不是那么简单。