マルチビタミン さんが書きました:
調べている中で「mail.server.default.mime_parts_on_demand」はどうだろうかを試しましたが、これもダメでした。
マルチビタミン さんの Thunderbird のメールアカウントは IMAP なのでしょうか。
あとついでに、どこのメールサービスなのかも伺っておいた方がよさそうです。
mail.server.default.mime_parts_on_demand というのは、IMAP の特にGmailのサーバーにあるメールの添付ファイル部分をダウンロードする挙動に関する設定だったと思います。
true なら添付ファイルにアクセスする際にオンデマンドでダウンロードし、false なら常に添付ファイルも含めてダウンロードする、という感じだったかと。
したがって、POPなら（推測ですが）関係ない気がします。
マルチビタミン さんが書きました:
ちょっと理解が乏しいので恐縮なのですが、上記のメール3を見ると、「filename」に「iso-2022-jp」ではなく「UTF-8」が入っていると思いますが、そういったことから最初からテキストエンコードを「UTF-8」を使用すれば回避できるとかそういうことではないのですかね。
繰り返しになりますが、構文の問題かと思われます。
リンクを記載しました別トピックは読んでいただけましたでしょうか。
まあ、長くなりますが改めて説明するとしましょう。
まず、日本語を含む短くないファイル名「マウスコンピューター(ST007070437).pdf」を添付した場合の実際のソースはこのようになります。
Thunderbird:
コード:
Content-Type: application/pdf;
name="=?UTF-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3?=
=?UTF-8?B?KS5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=UTF-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%28%53%54%30%30%37%30%37;
filename*2*=%30%34%33%37%29%2E%70%64%66
Outlook:name="=?UTF-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3?=
=?UTF-8?B?KS5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=UTF-8''%E3%83%9E%E3%82%A6%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94;
filename*1*=%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%BC%28%53%54%30%30%37%30%37;
filename*2*=%30%34%33%37%29%2E%70%64%66
コード:
Content-Type: application/pdf;
name="=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?="
Content-Description:
=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?=
Content-Disposition: attachment;
filename="=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?="; size=14512772;
creation-date="Wed, 09 Sep 2020 00:36:33 GMT";
modification-date="Wed, 09 Sep 2020 00:44:45 GMT"
Content-Transfer-Encoding: base64
name="=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?="
Content-Description:
=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?=
Content-Disposition: attachment;
filename="=?utf-8?B?44Oe44Km44K544Kz44Oz44OU44Ol44O844K/44O8KFNUMDA3MDcwNDM3KS5w?=
=?utf-8?Q?df?="; size=14512772;
creation-date="Wed, 09 Sep 2020 00:36:33 GMT";
modification-date="Wed, 09 Sep 2020 00:44:45 GMT"
Content-Transfer-Encoding: base64
Content-Type フィールドの name パラメータに関しては改行位置が少し異なるだけで基本は同じです。
注目すべきは Content-Disposition フィールドの方で、filename パラメータの構文が全く異なるのがわかるかと思います。
Thunderbird は RFC 2231 準拠のファイル名エンコーディングを行っています。
それに対し、Outlook は残念ながら、従来からの RFC違反のファイル名エンコーディングを行っています。
ここでは仮に、前者をRFC 2231方式、後者をMIME方式と呼ぶことにします。
非アスキー文字ファイル名のエンコーディングの対応状況ついて、いくつかのメールソフトを調べてみました。
結果は上記の表のとおりです。
Becky! と Sylpheed は設定でどちらの方式で送信するか選択可能で、規定はMIME方式になっています。
Outlook の RFC 2231方式の受信に関しては、私のところではできていますが不具合報告が上がってますので「？」にしています。
ちなみに、なぜMIME方式がRFC違反なのかについては下記のサイトを読んでみてください。
添付ファイルにおける日本語のファイル名に関して (Last modified: Thu Feb 8 07:22:14 2001)
マルチビタミン さんが書きました:
実際、「UTF-8」にすると、他の日本語が化けたりして困ってしまうのですが。
それは本件とは別の話です。
というか全くの初耳ですし、正直どういう状況なのかが呑み込めません。
マルチビタミン さんが書きました:
結局、Outlookユーザーのシェアを考えると無視できない点と、Outlookユーザーには、送信側のせいにされることもあるので困っちゃいますね。
Microsoft や Google などの圧倒的なシェアを持ってる側が、標準仕様を軽んじるような行動をすることがあるのは残念なことです。
しかし一方で、Mozilla などももう少しユーザー本位に融通を利かせた方がいいのではと思うこともありますね。