個人情報のマスク処理、お疲れ様でした。＞ kiyo4_k さん
【本題】情報のご提示、ありがとうございました。
ですが、どうも要領を得ないので、以下大胆な書き方をします。大筋を理解していただくことを優先しますから、細部の表現に技術的な正確さを欠くことは大目にみてください。
felsendorf さんが書きました:
なお「200名以上の他の人では文字化けがない」と言いましたが、そのうち約100名には、同窓会の案内を同じ文章、署名で出しております。文字化けは全文章に起っていますので、それがあれば当然文句がくるはずです。
同一条件で作成した同一文章のメッセージを 100 人に同報送信したとして、その内の 1 人から文章全体が文字化けすると返信があったとしても、他の 99 人のところで同じように文字化けしているとは限りません。送信者が作成・送信した条件に、受信側のメールソフトが自動的に合わせられる限り、文字化けは起こりません。
しかし、クレームがないから文字化けしていない、とも言い切れません。
受信時に文字化けを起こしていても、手動操作で修復できるなら、文字化けしているという用件だけをわざわざ連絡してくる几帳面な人は、そんなに多くないからです。
電子メールにおける文字化けの考え方は、大きく言って次のようになります。
（1）送信者が、電子メールの標準規格に忠実にメッセージを作成・送信すれば、どのような環境条件の受信者のところでも、まず文字化けは起こりません。（もちろん稀な例外はあります。）
（2）送信者が、電子メールの標準規格から外れた内容でメッセージを作成・送信してしまった場合、受信者側でその変則部分に自動対応できるなら、文字化けは起こりません。対応できない受信者のところで文字化けは発生します。
（3）文字化けが発生した受信者のところでも、メールソフトのエンコーディング設定を手動で変更するなどして、修正できるケースがあります。
（4）文字化けが発生した受信者のところで、どんな文字化けの仕方をするかは一様ではありません。文章中の特定の文字だけが化けるケースもあれば、文章全体が化けてしまうケースもあります。文章は正常だが、件名（Subject）だけが化けたり、その逆もあります。添付ファイルに異常が起こるケースもあります。
【1】送信側の条件を検討します（引用は、環境依存文字を置き換え、見やすさを考慮して整理させていただきました。）
felsendorf さんが書きました:
ケース1.最新メール：署名も含め「絵fAX」なし。→文字化けなし
Subject: =?ISO-2022-JP?B?GyRCSjg7ejI9JDEbKEJQUzI=?=
Content-Type:text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding:7bit
このヘッダ情報からは、Thunderbird が日本語標準のエンコーディング方式である ISO-2022-JP で送信できると判断し、その条件で送信されていることがわかります。
おそらく、本文、件名などに、ISO-2022-JP では取り扱えない文字は含まれていなかったと推測できます。
結果的に、この条件なら当該受信者は正常に表示できることが報告されています。
felsendorf さんが書きました:
ケース2.最新メール-1：署名に「絵fAX」使用。→すべて文字化け
Subject: =?UTF-8?B?5paH5a2X5YyW44GRUFM=?=
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
このヘッダ情報からは、Thunderbird が日本語標準のエンコーディング方式である ISO-2022-JP で送信できない文字があると判断し、送信可能な UTF-8 を選択して送信したことがわかります。
おそらく、本文、件名などに、ISO-2022-JP では取り扱えない文字が含まれていたためだと推測できます。
結果的に、この条件なら当該受信者の環境ではエンコーディングの自動選択がうまく働かず、文字化けを起こしてしまうことが報告されています。
こういうテストでは、比較したい部分以外を同じにするのですが、どうも [ケース1] と [ケース2] での違いは署名部分の fax が絵文字どうかだけではないようです。
しかし、明確な違いは fax が絵文字かどうかなので、ここでは他の部分に目をつぶっておきます。そうすると、[ケース1] と [ケース2] の違いは、fax の表現が普通のアルファベットか絵文字かの違いですから、UTF-8 での送信になったのは、fax の絵文字が原因だった可能性が推測できます。
可能性としか言えないのは、このテスト以外で送信したメッセージにおいて署名以外の本文の詳細が不明だからです。もし、本文にも環境依存文字が含まれていたら、UTF-8 での送信になった原因は複数あることになります。
【2】受信側の条件を推測しますfelsendorf さんが書きました:
ケース3.最新メール-2：長文。相手からのメールに返信。署名に「絵fAX」使用。→文字化けなし。
Subject: Re: =?UTF-8?B?5paH5a2X5YyW44GR44Gu6Kq/5p+744Gr5Y2U5Yqb5L6d6aC8?=
Content-Type: multipart/mixed;
boundary="------------020705050303060703070807"
This is a multi-part message in MIME format.
--------------020705050303060703070807
Content-Type: multipart/alternative;
boundary="------------050004070004080904030103"
受信側のメールソフトは Microsoft Office Outlook 2007 であることがわかっています。OS は Windows と推測できますがバージョンまでは確定できません。
これはおそらく Outlook 既定の HTML 形式での返信なのでしょう。
Subject は UTF-8 でエンコーディングされているので本文もそうなのかと推測しますが、必要なヘッダが提示されていないため、これ以上はわかりません。
「相手からのメールに返信」の相手とは、誰のことでしょう。
件名が「Re: 文字化けの調査に協力依頼」なので、「文字化けの調査に協力依頼」というメッセージを送った felsendorf さん宛に、相手の方が返信してきたもの、つまり「相手からの返信メール」という意味でしょうか。
User-Agent や X-Mailer もありませんが、存在しなかったということも書いてないので、追加でわかることは何もありません。
「文字化けなし」というのは、felsendorf さんのところでこのメッセージが文字化けしなかった、という意味ですか。それとも、この返信の元になった felsendorf さんから送った「文字化けの調査に協力依頼」のメッセージ（署名に「絵fAX」使用）が、相手の人のところで「文字化けなし」という意味ですか。
前者だとすると、felsendorf さんから送ったメッセージに使われていた "署名に「絵fAX」使用" を引用として含んだ返信メッセージが、そのまま UTF-8 で返信されてきて、felsendorf さんの Thunderbird はこれを正しく解釈して表示した、ということになりましょうか。
後者だとすると、[ケース1] [ケース2] の関係からみて、状況がよくつかめません。
受信側で文字化けが発生したのは [ケース2] です。[ケース1] では起こっていません。
文字化けの症状としては、特定の文字だけで起こっているのではなく、メッセージ全体に及んでいるようです。
ということは、自動選択されたエンコーディング方式のミスマッチによるものである、と考えてほぼ間違いないと思われます。
実際、受信者からは "『「メッセージ」ー「その他のアクション」―「エンコード」―「Unicode」』で一応読めるようになる" との返答があるので、エンコーディング方式を手動で切り替えれば、文字化けせずに表示できるようです。
この状況証拠からは、受信者の Outlook が、felsendorf さんから送られた UTF-8 のメッセージを自動的には認識できていない、という結論が導かれます。
なぜ Outlook のエンコード自動選択が正常に働かないかは、受信側の環境条件や Outlook の設定内容などが不明なため、これ以上は検討できません。
可能性として考えられるのは、先に挙げた Microsoft Support の記述です。
Microsoft Support さんが書きました:
補足 : バージョン 2002 以前の Outlook から、バージョン 2003 以降の Outlook にアップグレードしている場合、Outlook データ ファイル (.pst) が Unicode に未対応であることが原因で文字化けが発生している可能性があります。この場合、エンコードを [日本語 (自動選択)] に変更してから [Unicode (UTF-8)] を選択しなおすことで文字化けを一時的に回避することができますが、根本的に文字化けが発生しないようにするためには、Unicode に対応した Outlook データ ファイルを新規作成し、必要なデータを古いデータ ファイルからインポートします。詳しい方法については 非 Unicode データ ファイル (.pst) を Unicode データファイル (.pst) に変換するを参照してください。
（お礼）meeyar さん、補足情報、ありがとうございました。
【3】その他の受信者の状況具体的な情報が皆無なので推測の域を出ませんが、いちおう言及しておきます。
felsendorf さんから送られたメッセージで文字化けが起こった受信者と、同じような環境条件の受信者のところでは、文字化けが起こっている可能性が考えられます。
ただし、手動でエンコード設定を切り替えれば文字化けを解消できるユーザーは、いちいち felsendorf さんに文字化けしていることを連絡していないだけかもしれません。
逆に、felsendorf さんと同じような環境条件の受信者のところでは、文字化けを起こさなかった可能性が高いです。
両者の割合はわかりません。
また、文字化けが全文に及ぶのではなく、特定の環境依存文字だけが文字化けしていて、本文は普通に読めている受信者がいるかもしれません。この場合、文字化けしているのは絵文字部分ぐらいでしょうから、文字化けに気がついていないか、気づいても些末なことなので無視しているケースが考えられます。
【4】どう解決するか方向性は２つあります。
（a）送信者側での対策
（b）受信者側での対策
（a）は、冒頭で述べた（1）の条件を felsendorf さんが実行することです。
（b）は、受信者の環境条件によって変わります。問題の受信者のところに限っていえば、Outlook の設定の見直し、上述の Microsoft Support の情報の確認と、それに該当するのであれば指示されている作業の実行が挙げられます。
大勢に同じメッセージを送信することを前提に考えれば、客観的に見て道理があるのは（a）の対処法でしょう。
Outlook で問題の回避策をとれたら、今後も環境依存文字を使ってメッセージを作成・送信していい、ということにはなりません。そういう我流の運用方法をとればとるほど、受信側で文字化けなどのトラブルが起こる確率が上がるからです。
少なくとも現状では、メッセージの件名や本文内（署名含む）に環境依存文字を使わなければいいわけです。そしてそれは、Microsoft IME（ATOK なども）が変換時に注意を促してくれるので、判別はシロウトでもできます。現実的に、電子メールをきちんと扱おうという多くのユーザーは、そのあたりをわきまえてメッセージを作成・送信しているはずです。
以上です。
根本的な部分での誤認・説明不足などがありましたら、訂正・補足をお願いします。＞ みなさま
ログイン
ユーザー登録
FAQ
検索
」は、Unicodeでは「
」になり、これは「