1

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などの2バイトの文字セットを分割すると、javamailで破損した文字列が返されると思います。私は正しいかどうか？または、この問題を解決するための回避策を提案してください。

4

1 に答える 1

1

RFC 2231 仕様では明確ではありませんが、パラメーターの各セクションはそのセクションがエンコードされているかどうかを制御できるため、各セクションのエンコードは他のセクションのエンコードとは無関係であることを意味し、したがって、そのセクションは独立してデコードされます。仕様の作成者に確認したところ、必ずしもそうではないことがわかりました。したがって、これは JavaMail のバグのように見えます。修正は簡単ではないようです。

于 2013-01-28T22:34:44.623 に答える