送信したメールが相手が文字化けして読めないというのですが

実は私も同じ問題でまいっています。Search で『文字化け』を探し過去にいろいろ投稿されている文章を読んだのですがなかなか解決策が見つかりません。
私の場合は送信文が返信でもなく標準テキスト、リッチテキストに限らず送信するとＰＣユーザーの方々から「文字化けで読めない」と返事がきます。（マックユーザーの方に送った事はないのですが）
ちょっと前までは eMac で OX10.3でした。それで全く問題なかったのですが、MacBook に替えたとたんこうなってしまいました。
「標準テキストで書いたら」というお薦めも読みましたが、仕事上、リッチテキストで書く必要があります。（今の所どっちでも文字化けするのですが）
いろいろな方々がこの文字化けで投稿されているという事は根本的な問題をはらんでいるのではと悲しくなってしまいます。
どなたか解決策を見つけて頂けませんでしょうか？
“つねお”さん同様、私からもお願い致します。

つねおさん、チェットアンガスさんお二方ともにですが、それだけではどうにも出来ません。　相手のOSとMUA（メールソフト）が何なのか、送信している側のMail.appのバージョン、Mac OS Xのバージョンは最低限、出来れば「文字化けしている」と言われた送信済みメールを「表示」→「ソース」と開いてヘッダの文字エンコード部、マルチパート部等ぐらいは記載して頂かないと。。。
例えばリッチテキスト（テキストのみ）で私自身にテストで送ったメールのソースでは
【ヘッダ】
Content-Type: multipart/alternative;
boundary=Apple-Mail-5-50217076
【ヘッダの下のテキスト部】
--Apple-Mail-5-50217076
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=ISO-2022-JP;
format=flowed
【その下の部分】
--Apple-Mail-5-50217076
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-2022-JP
とありますが、此処がどうなっているかを書かれないことには原因を探ることすら難しいわけです。
ちなみに、私個人ではMail.appでWindowsの方とやり取りしていて（たとえば丸付文字をつかった部分だけが）文字化けしたメールをもらうことはあっても、「文字化けしている」とクレームが来たことはありません。
実際、Windows2000上でOE6.x、Thunderbird1.5.xで受信テストしてみても文字化けはしません。但し、機種依存文字やユニコードの文字（ハシゴの「高」等）を使うとOEでは一部、Thunderbirdでは全体が文字化けします。
という訳でMail.appがWindowsとやり取りしていて必ず文字化けしたりそういう根本的な問題をはらんでいるという訳ではないと思います。（特定条件下で例えばUTFで送ってしまうとかいう問題は別として）どこか送信側に原因があると考える方が自然ではないかなぁと。例えば気付かずにシグネチャにそういう文字を使ってしまっていたりとか、メール作成時にMail.appで作成するのではなくて何か別なアプリケーションを使って作成してMail.appにコピペしているとか、そういう事は無いでしょうか？　

usadii3 さん、早速ご返事頂き有り難う御座います。それと私はオリジナルのメッセージ投稿者ではなく、こういうのを“横レス”というのでしょうか？　つねおさんと同じ悩みだったので追加しています。つねおさん、スミマセン。
さて、失礼をさせて頂き、このコラムを続けさせて頂きたいと思うのですが、私の場合は
MacOS10.4.7
Mail.app バージョン 2.1（752/752.2）
です。
受信相手のは今ちょっと分かりません。
usadii3 さんの言われたソースを調べましたら下記の様になっていました。
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative;
boundary=Apple-Mail-83-1156076
Subject: =?ISO-2022-JP?B?bmV3cyAbJEIlKyVKJUAkTiVTITwlVSVRJUMlKyE8ISIbKEI=?=
=?ISO-2022-JP?B?GyRCP008aklUQi0kS0c6JGAbKEIoGyRCOkZBdyFLGyhC?=
Date: Fri, 25 Aug 2006 18:44:58 -0500
--Apple-Mail-83-1156076
Content-Transfer-Encoding: base64
Content-Type: text/plain;
charset=UTF-8;
delsp=yes;
format=flowed
これで「こんなに化けているぞ」とＰＣユーザーから返ってきたのは全化けでした。
返信メールでもなく署名もなく送っているのですが、そうなります。
ただし気になるのは、此所は米国なのですが、米国内で日本語を送っている分には誰からも「文字が化けているぞ」といわれていないのです。でも何にしましても今迄 eMacユーザーでOS10.3.9 、Mail1.3.11 (v622/624) で問題がなかったのですから海外からの送信だからというのは関係がないのかなと思っています。
如何でしょうか？
つねおさんは私と同様でしょうか？

> charset=UTF-8;
と、しっかりUTF-8になっていますね。これでは相手先で化ける可能性が高いと思います。化けないよーにするにはここがcharset=ISO-2022-JPとなるべきです。
やはりどこかにUTF-8になるよーな文字が紛れ込んでいるのではないでしょうか？

このBoard内を文字化けで検索すると、いくつかヒットしますよ。
mail文字化け対策　教えて下さい
奇妙な文字化け
Mailで送信したメッセージの文字化け
Bccメールで文字化け
とか。

Content not available

> Content-Type: multipart/alternative
上記の人へのメールは、
初めのメッセージ( 作成日 2006/8/26 7:32 am )で
「標準テキストにしている」と書かれているのに、
リッチテキストになっています。
NO9さんがリンクを貼られているトピックを確認されましたか？
相手のHTMLメールに対して「返信」されてませんか。

> NO9さんがリンクを貼られているトピックを確認されましたか？
相手のHTMLメールに対して「返信」されてませんか。
ですね。ついでに勝手に補足すると、相手のHTMLメールは見るからにHTMLメールとは限りません。テキストだけのHTMLメールもあります。テキストだけなのに設定がHTMLメールで送ることをデフォルトになっていたりすると、送っている本人も気がつかずに（というかテキストメール・HTMLメールという種類があることすら知らないのかも）送ってきているカモしれません。

追記です。
> 如何でしょうか？
> つねおさんは私と同様でしょうか？
つねおさんのソースが出たので追記しますが、つねおさんの事例とはちょっと違うようです。で、最初記事を読んだときにはつねおさん、チェットアンガスさんそれぞれに、今までの事例と違うのかもとも思いましたがソースを見る限りでは、NO9さんがリンクをしてくれた今まででた内容のウチのどれかにあてはまるような気がします。もいちどNO9さんが貼ってくれたリンク先を良く読んで見ると良いかと思います。
チェットアンガスさん：前に大丈夫でIntel Macに変わってから、というのはタイミングに過ぎないのかもと考えられたら如何でしょうか。

usadii3 さん
本当に色々と有り難う御座います。今晩（日本時間の明朝）様々な形でｅメールを送ってみて、以前のデスクトップからも送ってみて又反応を見ようと思います。
結果はまた此所でお知らせ致します。
こう種類の悩みは結構多くの方々が持たれると思うのですが、このディスカッション・ボードは非常に頼れる味方です。周りで特にコンピュータに結構詳しい人でも「マック？マックじゃちょっと分からないかも」とか言われるので此のディスカッションボードはよりどころです。
お答え頂く方に感謝しております。

つねおさん、チェットアンガスさん、こんにちは。ちょっと混ぜて下さいね。
>Content-Transfer-Encoding: base64
>charset=UTF-8
このコンビネーションの時にWin PC側で大化けしていることが多いです。（但し例外もあります。）今のところ、送信前に100％回避する手段はありません。が、メールサーバ／ISPを変更することで改善する場合もあります。私のケースでは、ISPのアカウントはそのままで送信メールサーバのみ変更した結果、メールを受信するWin XP Outlook Express側での文字化けがなくなりました。
用語の確認をしてもよろしいですか？（ダメでもやっちゃう！）
Base64:
MIME (Multipurpose Internet Mail Extension) Base64 はデータ変換方式の一つで、Eメールを送る際にバイナリデータをテキストデータに置き換える（=encodeする）ものです。Eメールではテキストデータしか扱えないため、画像／オーディオ・ファイルやワープロ文書などのバイナリデータは、例えばこのBase64方式に従って文字列のデータに置き換えて送信し、受信側のメールソフトは、送信側のメールソフトが実行した文字列へのエンコード手順を逆にたどって、再び元のデータに復元（=decode）します。エンコード手順は、まず6bitごとに分割したバイナリデータのそれぞれの先頭部分に「00」を付け加え、8bit単位のデータに編集した上でこれを読み取り、読み取った値に対応する文字をBase64の表（英数字と「＋」と「/」の64文字で構成）から取り出して並べ、これを最終的な送信データとします。送信データのエンコード過程または受信データのデコード過程でまちがいが起こると当然文字化けします。
multipart:
メールメッセージにバイナリデータが含まれている時にはヘッダに「Content-Type: multipart/alternative」のように記載されます。「multipart」はMIME規格の拡張仕様で、一つのEメールに複数の異種形式のデータを格納する方式のこと。画像や音声ファイルを添付したり、リッチテキスト形式でメッセージを送信する場合などに使われます。
私自身の経験では、特定のエンコード方式（Base64）とキャラクター・セット（UTF-8）の組み合わせの時にPC側で文字化けする頻度が高かったとはいえ、同じ宛先に同じBase64とUTF-8で送信したメールが正常に表示される場合もあるという事実から、伝送途中でのエラー（デコードに必要な文字情報が一部抜け落ちるなど）の可能性も疑っています。いずれにせよ、
＞Mac Bookに変えた
＞海外からの送信
この２点は文字化けの根本原因ではないと思います。むしろ、Eメールを中継するサーバのどれかが、Mail.appで作成した特定のデータ形式のメッセージを、何らかの理由で（一時的にせよ）正しくリレーできないタイミングがあるのではないでしょうか？　例えば、OS X のアップデートの直後など？
文字化けが頻繁に、かつ長期間続いて起こるような場合、ISPによってはメールアカウントを作り直すことを勧めてくれることもあります。メールサーバに選択肢があれば変更してみるのも手です。
（何か違っていたら、皆さん奮って訂正をお願いいたします。）

どうも皆さん　色々とありがとうございます。(_ _;)
ぼくが以前このボードに送った文字化けしたメールのソースはリッチテキストで送信したものを貼り付けてしまいました。
標準テキストでも文字化けするのです。
ともあれ、皆さん色々ご指摘を頂き本当にとてもうれしいのですが、
現在少々多忙にて、皆様の書き込みの内容を良く読む時間がないため、
しばらくした後 No9 様などのリンクなども参考し検証を行った後に出直します。
皆様本当にありがとうございます。
また、ダメだったら出て参りますので教えてください。よろしくお願いいたします。

今いろいろやって分かりました。
僕の場合、環境設定でフォントを選び其の中の『標準テキストメッセージに等幅フォントを使用する』を『選ばない』と選択すると文字化けを避ける事が出来ました。
工場出荷が『選ぶ』だったので分かりませんでした。
これで同じ悩みの方々を救えると良いのですが.....。
usadii3 さん本当に有り難う御座いました。
つねおさんも解決される様に米国よりお祈りしています。
また、問題の時にお願い申し上げます。

今いろいろやって分かりました。
僕の場合、環境設定でフォントを選び其の中の『標準テキストメッセージに等幅フォントを使用する』を『選ばない』と選択すると文字化けを避ける事が出来ました。
工場出荷が『選ぶ』だったので分かりませんでした。
これで同じ悩みの方々を救えると良いのですが.....。
usadii3 さん本当に有り難う御座いました。
つねおさんも解決される様に米国よりお祈りしています。
また、問題の時にお願い申し上げます。
macbook; Mac OS X(10.4)

＞環境設定でフォントを選び其の中の『標準テキストメッセージに等幅フォントを使用する』を『選ばない』と選択すると文字化けを避ける事が出来ました。
これ（↑）は正解かもしれない。
「使用する」とチェックを入れておく場合は、等幅フォントを「Osaka-Mono」に指定してみるとどうでしょう？
Safariでも表示の等幅フォントをCourierなどに設定すると、Webページによっては日本語が文字化けすることがあります。日本のWebサイトを閲覧する時は、Safariの環境設定＞表示で
　「等幅フォント：Osaka 13」
　「デフォルトエンコーディング：日本語Shift JIS」
にしておくと、ほとんどのページは文字化けなく表示されるようです。