名前 題名 ▼ 平蔵さん > MIMEマルチパートメールの添付ファイル名（Content-Dispositionヘッダ）の処理に関しまして、 > 特定の条件においてファイル名が正しくデコードされずに表示される現象を確認いたしましたので、 > ご報告をさせていただきます。 > > 1. 現象の概要 > Content-Disposition ヘッダにおいて、慣習的にMIMEエンコードした filename= パラメータと、 > filename*= パラメータの両方が同時に指定されている場合、ファイル名がデコードされず、 > エンコードされた文字列（=?UTF-8?Q?...?=）のまま表示されます。 > ※filename= だけ、あるいは filename*= だけの単体指定の場合は、どちらのパラメータであっても > 正常にデコードされて表示されます。 > > 2. 再現するヘッダのパターン > 以下のように両方のパラメータが記述されているメールを受信した際に現象が発生します。 > (UTF-8, Qエンコードの例ですが、ISO-2022-JP、Bエンコードでも状況は同じで、パラメータの順序や折返し改行の有無も無関係です) > > Content-Disposition: attachment; > filename="=?UTF-8?Q?=E3=83=86=E3=82=B9=E3=83=88?="; > filename*=UTF-8''%E3%83%86%E3%82%B9%E3%8 > 3%88 > > (投稿の制限で途中改行されるようですが、実際は3行です) > > 3. バージョンごとの確認結果（再現環境） > 各バージョンにおける挙動を確認いたしましたところ、v2.82.00 のアップデートを境に動作が変化している模様です。 > > ・正常にデコードされるバージョン： > v2.81.08 以前 > ※ filename= の値が、デコードされ表示されていました。 > > ・デコードされずエンコード文字列のまま表示されるバージョン > v2.82.00 / v2.82.01 / v2.83.00 / v2.83.01 / v2.83.02 / v2.83.03（最新） > > 4. 他のメーラーでの挙動（参考） > Gmail、Outlook、Thunderbirdなどで確認した限りでは、両パラメータが混在する場合、 > filename*= 側を優先してデコード表示する挙動となっています。 削除キー Pre