[quote="緑の狸"]
なお、2回目以降は「’08．4．[color=red]_[/color]14　　日報①[color=blue]-1[/color].doc」のように一時ファイル名とアプリケーションへ渡される名前が一致するため開けるようになりました。[/quote]
全く気がつきませんでした。２度目のチャンスにかけるのも大切でした。
こちらの方が、デスクトップにドラッグするより操作も簡単です。

ありがとうございました。

[quote="緑の狸"][quote="あ"]この問題は既に分かっている話なので、改めて Bug 報告する必要はないかも。[/quote]
どの Bug でしょうか？
Bugzilla-jp と bugzilla-org を検索したのですけど、添付する場合の話はありましたが、開く場合の話は見つけられませんでした。[/quote]
「この」が何を指すつもりなのかがはっきり書いていなくて、すいません。
現在のコードページでは表せないファイル名等を扱えない(ここで言う「扱う」というのは、ファイルを開くとか OS に渡すとかそういったレベルの話)ということで、例えば [url=https://bugzilla.mozilla.org/show_bug.cgi?id=38122]Bug 38122 – eliminate nsFileSpec and nsIFileSpec[/url] とか [url=https://bugzilla.mozilla.org/show_bug.cgi?id=418703]Bug 418703 – reduce narrow windows API calls.[/url] とかが該当します。
SJIS で表せない文字を含むファイル名の添付ファイルがそのままでは開かなかったりする場合があるのもこういったところが原因で、根本的に問題があることはわかっているのですが、影響範囲も大きくてそう簡単には直りません。
これが、「改めて報告する必要はないかも」と書いた内容です。

ただし、今の状態で起こる問題が大きくて、根本的な修正を待っていられないから、こういう場合には扱える文字に置き換えてから処理する等の Workaround を入れてほしい、という報告であればアリかもしれませんね。

実験した結果、一時ファイル名とアプリケーションへ渡される名前が異なっているために開けないようです。
（Unicode アプリケーションでも 非Unicode アプリケーションでも同じです。）

一時ファイル名:
’08．4．[color=red]�[/color]14　　日報①.doc
（U+FFFD も含めて元のまま）

アプリケーションへ渡される名前:
’08．4．[color=red]_[/color]14　　日報①.doc

なお、2回目以降は「’08．4．[color=red]_[/color]14　　日報①[color=blue]-1[/color].doc」のように一時ファイル名とアプリケーションへ渡される名前が一致するため開けるようになりました。

[quote="あ"]この問題は既に分かっている話なので、改めて Bug 報告する必要はないかも。[/quote]
どの Bug でしょうか？
Bugzilla-jp と bugzilla-org を検索したのですけど、添付する場合の話はありましたが、開く場合の話は見つけられませんでした。

[quote="緑の狸"]
（文字化け（しているように見えるの）は問題ない／しょうがないと思います。）
[/quote]

こちらでも、次のWebツールを利用して 同じファイル名に変換されることが確認できました。

　http://fesc.abell.co.jp/tool/

回答ありがとうございました。

[color=darkred][size=100]# 引用部のタグを編集しました　Ｂy Hide[/size][/color]

[quote="緑の狸"]おそらく、送信側で UCS-2 や UCS-4 では表現できない何らかの文字が未定義文字記号に置き換えられ、受信側の Thunderbird がそれをうまく処理できないということではないかと思います。
（文字化け（しているように見えるの）は問題ない／しょうがないと思います。）[/quote]
U+FFFD も、それはそれで一応文字なのでそのまま表示されるのは問題ないです。
デコード前のヘッダで既に U+FFFD になっていますので、仮に(送信側の状況が不明なので、あくまで仮に、です)これが文字化けだとすれば、送信側で既に文字化けしているか何かであって、受信側の Thunderbird で文字化けしているわけではありません。

Thunderbird 側の問題としては、例えば日本語版 Windows のデフォルト環境であれば、ファイル名にいわゆる SJIS では表せない文字(U+FFFD もそうです)を含んでいるとうまく扱えない場合がある、というところでしょうか。
この問題は既に分かっている話なので、改めて Bug 報告する必要はないかも。

[quote="K.Ika"]Content-Type: application/octet-stream;
name="=?UTF-8?B?4oCZMDjvvI4077yO77+9MTTjgIDjgIDml6XloLHikaAuZG9j?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?UTF-8?B?4oCZMDjvvI4077yO77+9MTTjgIDjgIDml6XloLHikaAuZG9j?="
[/quote]
あら、UTF-8 でしたか。Bug 5934 は直接は関係なさそうですね。
Unicode のことはよく知らないのですが、調べた所問題の文字は、未定義文字記号 [url=http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=fffd]U+FFFD[/url] （UCS-2 や UCS-4 では表現できない文字を表すために用いられる）のようです。
おそらく、送信側で UCS-2 や UCS-4 では表現できない何らかの文字が未定義文字記号に置き換えられ、受信側の Thunderbird がそれをうまく処理できないということではないかと思います。
（文字化け（しているように見えるの）は問題ない／しょうがないと思います。）

対策は…今のところ調査不足でわかりませんが、Bugzilla に登録して修正するしかないような気がします。

回答ありがとうございます。

[quote="緑の狸"]添付ファイルを開けないとか文字化けする場合は、添付ファイルのヘッダー部がわからないと原因を特定するのは困難だと思います。
デコード前の添付ファイルのヘッダー部はどうなっていますか？
[/url][/quote]

デコード前の添付ファイルのヘッダー部です。

Content-Type: application/octet-stream;
name="=?UTF-8?B?4oCZMDjvvI4077yO77+9MTTjgIDjgIDml6XloLHikaAuZG9j?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="=?UTF-8?B?4oCZMDjvvI4077yO77+9MTTjgIDjgIDml6XloLHikaAuZG9j?="

自分ではデコードできませんでした。
宜しくお願いします。

添付ファイルを開けないとか文字化けする場合は、添付ファイルのヘッダー部がわからないと原因を特定するのは困難だと思います。
デコード前の添付ファイルのヘッダー部はどうなっていますか？
（デコード前のメールデータは[表示]→[メッセージのソース]メニューで見れます。）

他のメーラーでは文字化けしないということから推測すると、件名の文字化けと同じ理由かもしれません。
[url=http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5934]Bug 5934 – 2.0.0.6で問題ないSubjectが、2.0.0.9で文字化けするメールがある[/url]

別のメールクライアントソフトを利用して送られてきたメールを受信すると
添付ファイル名が文字化けして開くことができません。

デスクトップにコピーして開くことはできるのですが受信したファイル名が
正しく保存されるようにはできないでしょうか。

送信する場合しか関係なさそうですが次の設定はしています。
mail.strictly_mime.parm_folding = 0

送信したメールクライアントソフトと同じメールクライアントソフトやBecky!で
受信した場合は添付ファイル名はそのままで、ファイルを開くこともできます。

・送られたときのファイル名
　　’08．4．14　　 日報①.doc

・ThunduerBirdが表示するファイル名
　　’08．4．?14　　日報①.doc

・デスクトップにコピーしたときのファイル名
　　’08．4．_14　　日報①.doc

　＃最初見たとき、完全に文字化けかと思いました。

利用環境
　　Thunderbird: バージョン 2.0.0.12 (20080213) Windows 版
　　OS : Windows 2000 SP4