|
▽ 2026/7/18 (土) 20:24:24 ▽ 平蔵 |
|
softbank126220225067.bbtec.net / Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 |
| 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*= 側を優先してデコード表示する挙動となっています。 |
|
|