基于 rfc 2231 从 Mime 标头中使用 charset iso-2022-jp 解码文件名的问题答案

【问题标题】：Issue in decoding filename with charset iso-2022-jp from Mime header based on rfc 2231基于 rfc 2231 从 Mime 标头中使用 charset iso-2022-jp 解码文件名的问题
【发布时间】：2013-01-11 22:31:25
【问题描述】：

在 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 中返回损坏的字符串。我是否正确？或者请建议我解决此问题的解决方法。

【问题讨论】：

标签： java jakarta-mail mime

【解决方案1】：

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

【讨论】：