添付書類名の文字化け

長らくご無沙汰しております。
ソフトウェアーアップデートでMacOS X 10.4.7にしたところMailのバージョンは2.07から 2.1に変わりました。
この結果、相談致しました添付書類の文字化けは解消しました。
添付書類名の扱いはWindowsやMac版Thunderbird1.5と同様にエンコードされているようです。
メーラーの規格に対する厳格な準拠の問題は有るかもしれませんが、現状では添付書類名の文字化けは解消しました。
無節操なようですが、Mac版Thunderbird1.5をバックアップとしてMail2.1をメインに使用しようと思います。
取り敢えず状況報告を致します。

私トピですが、以下ご参照ください。私は当初別問題と考えてトピを立てましたが、根っこは同じかもしれません。
"添付ファイル名に使えない文字（長文）" #4, 2006/06/30 1:36pm

便乗で失礼いたします。
Windows Outlook やWindows版Eudoraなどから送信されたメッセージに添付されている書類はどうでしょうか？
つまりMac OS X Mailアプリケーションで「受信」する場合です。
最近、10.4.7のMail 2.1で受信した、Windowsユーザーの
Microsoft Outlook Express 6.0から送ってきたメッセージに添付されていた
書類が化けていました。
ファイル名は
=?iso-2022-jp?B?MDYuNS4xNhskQiU4JWclcyEmJSslSiVqJSIlYBsoQi5wZGY=?=
となっていました。
ISO-2022-jpのエンコードの問題でしょうか？

こちら
http://discussions.info.apple.co.jp/WebX?128@@.efd9e9f
が参考になるでしょう。
他にも「添付書類　文字化け」で検索すると、いくつか出てきます。

Hit-Cさん、ありがとうございます。
MIME-B-Decoder
をダウンロードしてみます。
ちなみに、当該ファイル(PDF)はリネームしなければ開くこともできませんでした。
私も、「ああ、Macで受信したのですかぁ〜」と言われて肩身の狭い思いをしている状況です。といっても、外資系企業に日本語のファイル名で送りつける取引先も困ったものです・・・

> =?iso-2022-jp?B?MDYuNS4xNhskQiU4JWclcyEmJSslSiVqJSIlYBsoQi5wZGY=?=
これをデコードすると、「06.5.16ジョン・カナリアム.pdf」となりますが、同じ名前のファイルを試しにWindows OE6.0から添付して送ってみても、Mail.appでは正しく添付ファイル名をデコード出来ています。
このときのメールソースは
Content-Type: application/pdf;
name="=?iso-2022-jp?B?MDYuNS4xNhskQiU4JWclcyEmJSslSiVqJSIlYBsoQi5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?iso-2022-jp?B?MDYuNS4xNhskQiU4JWclcyEmJSslSiVqJSIlYBsoQi5wZGY=?="
でした。
森岡さんの場合のメールソースではどうなっているでしょうか？

Y.Kawabeさん
すみませんContent-Typeしか、Long Headerを表示しても見つかりませんでした。前後の表示も含めると下記のようになっています。
なぜか"filename="の表示が出てきません・・・
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
Content-Type: multipart/mixed; boundary="Boundary_(ID_pRoh/Du8v+fzZugc8TMc+A)"
X-Priority: 3
X-Msmail-Priority: Normal
こちらも、MIME-B-Decoderではそのようにデコードできます。
（人事ファイルなので人名になっています）

filenameはメールヘッダではなく、メール本体内にあります。Long Header表示ではなく、Source全体を表示して探してください。

すみません。下記のようになります。
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
name*0="=?iso-2022-jp?B?MDYuNS4xNhskQiU4JWclcyEmJSslSiVqJSIlYBsoQi5wZGY=";
name*1="?="
Content-Disposition: attachment;
filename*0="=?iso-2022-jp?B?MDYuNS4xNhskQiU4JWclcyEmJSslSiVqJSIlYBsoQi5wZGY=";
filename*1="?="

というか、皆さんそのまま添付してるんですねぇ。。。
メール本文に添付書類の書類名と圧縮形態を明記し、書類は（事故防止の為にも）圧縮して圧縮ファイル名自体は（トラブル防止の為にも）英字にする。場合によっては当方の制作環境とソフトのバージョンも明記する、というような事をずっとやってます。それとコンピュータの書類ならどれもみな同じで必ず読める、だなんてパソコン教室に入りたての生徒のよーな事を思っている人は企業では少ないと思いますので、事前に送受信に関する情報交換を必ずします。また、生で添付する事自体にも抵抗があって。
> 「ああ、Macで受信したのですかぁ〜」と言われて肩身の狭い思いをしている状況です。
そんな発言をしている時点で詳しく無い方なのですから、気にしないことです(^^

なるほど。ファイル名のエンコード結果が２行に分割されると、正しくデコード出来ないようですね。OEのバージョンは全く同じなので、どういう場合にOEが２行に分けるのかがよくわかりませんが。
いずれにせよ、OEのファイル名エンコードの方法は、RFC規約に沿っていません。Content-typeのnameフィールドを２行に分けるのもおかしいし、Content-Dispositionのfilenameフィールドのエンコード方法も間違いです。Mail.appがどちらのフィールドをファイル名としているのかわかりませんが、Mail.appの動作自体の誤りではなさそうです。

Y.Kawabeさん、Usadii3さん
便乗質問にもかかわらず、コメントありがとうございました。
ひとまず、Mac OS X Mail applicationがおかしいのではないという
ことで安心しました。

usadii3さんへ
>パソコン教室に入りたての生徒のよーな事を思っている人は企業では少ないと思います
会社が大きくなると、社員にパソコンの設定をいじらせませんので、大企業の社員ほど、パソコンとその利用法には無知です。ただ、与えられたソフトを使っているだけです。
残念ですが、usadii3さんのような方法でファイルを受け取ったことは皆無です。powerpoint を持っていませんが、平気で送って来ます。

>...というような事をずっとやってます
仕事柄、海外を含め添付書類を送ってもらうことは多いですが、「制作環境とソフトのバージョンも明記」とリクエストしてあっても、そうしてくる人の方が少ないですね。このような場合、受け取った文書の一部が文字化けしたりしていても知らんぷりして印刷に回したりしますけど ;-)
というわけで、相手の環境を気にしていない人に対しては、こちらも気にしない対応をすることにしてます(昔は色々気を使っていたけど、面倒になったというのが正直なところかな)。