素早い応答ができなくて申し訳ありません。
最初にお詫びです。前便ではアンダーラインが長々と付いた不自然な表現になってしまい、すみませんでした。
ソース表示のキーボードショートカットが、そのままアンダーライン用の BB コードと解釈されてしまったようです。
追加の状況説明、ありがとうございました。＞ godmacchi さん
godmacchi さんが書きました:
次にメールのソースを開いて見てみたところ、メールヘッダー部に「h=Fromate:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;」というのがあり、ヘッダー部の後半に「Content-Type: multipart/alternative;」があったのでマルチパートメールだと思います。ただ、次にあるプレーンテキストメールの宣言が「Content-Type: text/plain; charset="iso-2022-jp"」なのですが、2番目のHTMLメールの宣言が「Content-Type: text/plain; charset=utf-8」です。たぶんプレーンテキストで宣言されているのでソース表示になったのですかね。
「たぶんプレーンテキストで宣言されているのでソース表示になったのですかね」と仰っているとおりです。
マルチパートで構成されたメール内の HTML パートの Content-Type が text/plain になっているのであれば、その部分は HTML メールとして解釈されませんから、HTML タグが生のまま表示される（＝ソースのまま表示される）ことになります。
上記のお話からは、トピックタイトルにある「HTMLメールがソースのまま表示される」の直接の原因は、誤った Content-Type にあったと判断してかまわないと思います。
そしてより重要なことは、どの段階で、どんな事情があって、そのような誤った Content-Type になってしまったのか、ということでしょう。
godmacchi さんが書きました:
HTMLソースで表示されるメールのソースをざっと見てみました。全部は見れていないような気がするのですが、Content-Typeを中心に見てみたところちょっと変な感じです。まず、メッセージウインドウにHTMLソースがそのまま出ているので、そこで見てみた所<head>のすぐ下のmetaタグ内でcontent="text/html"; charset=iso-2022-jpとなっていました。
簡潔さのためかなり端折った書き方をしますが...。次のようなメッセージソースがあったとします。
引用:
Content-Type: text/html; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-2022-JP">
</head>
上の２行は、電子メール自体のヘッダで、それ以下のコンテンツの内容を定義しています。
<html> 以下は、上２行で定義されたコンテンツの内容として存在する、HTML そのものの書式です。
このようなメッセージソースを持つメールを受信したとき、メールソフトはまず電子メールとしてこれから読み込むコンテンツの性質を上２行で判断します。
ここに、Content-Type: text/html; という指定があるときは、以降のコンテンツを HTML 形式のメールとして読み込もうとします。そして、<meta http-equiv="content-type" content="text/html; charset=ISO-2022-JP"> などの HTML タグを、HTML の定義に従って解釈・表示していきます。
一方、もし最初の Content-Type が text/plain になっていたら、以下のコンテンツはプレーンテキスト形式として読み込まれますから、HTML タグそのものが解釈されなくなり、単なる文字列としてそのまま（ソースのまま）表示されます。
godmacchi さんが書きました:
また、もう1つ気づいたことがあるのですが、多くの場合に最初に来たメールは普通に受信できることが多いです。それに対してこちらから返信して、更にそれに対して相手から返信が来たメールがHTMLソースになっていることが多いです。こちらのThunderbirdの問題かもしれないです。
「多くの場合に」ということは、少ないながらも「最初に来たメール」でもご質問のようなソース表示になることはあるのですか。
「ある特定の人」以外の相手からのメールは、「最初に来たメール」であれ、返信であれ、ご質問のようなソース表示になることはいっさいないのですか。
godmacchi さんがご自身で作成なさる送信メールの形式は、HTML 形式ですか、プレーンテキスト形式ですか。
HTML の形式の場合は、[HTML のみ] ですか、[テキストと HTML] ですか。
返信として送られてくるメールで発生確率が高いという点にスポットを当てると、godmacchi さんが送ったメールのヘッダ構成等と、それに対して返信をする「ある特定の人」の送信設定の兼ね合いの中で、本来 text/html であるべき部分の Content-Type が間違った text/plain に置き換えられてしまうケースがある、という仮説が立てられそうです。
ただ、具体的にどのような条件のときにそんなことが起こるのかは、いまある情報だけではわかりません。返信の引用部分であれ、返信者が書いた本文であれ、普通にメールのやり取りをしていて、Content-Type が改変されるようなことは、ちょっと考え難いです。
一方、godmacchi さんがプレーンテキスト形式を基準に運用されていて、相手への送信も返信もプレーンテキスト形式でおこなっているのなら、その相手から再返信されてきた HTML メールの Content-Type は、十中八九、相手側の問題だと考えていいと思います。
godmacchi さんが書きました:
上で書いたcharsetがisoだったりutfだったりするのも気になるので、Thunderbirdのオプション→表示→書式→詳細設定のフォント制御やテキストエンコーディングをいじりながら返信して状況が変わるか見てみているところです。
charset に問題があることで発生するのは、いわゆる「文字化け」です。ソース表示になることの直接の原因にはならないと思います。
１通のメールの中に、charset の異なる複数のパートがあっても、それぞれのパートで
Content-Type: text/html; charset=utf-8
Content-Type: text/plain; charset=iso-2022-jp
のようなメールヘッダの指定が適切に存在すれば、どのパートも文字化けせずに表示されるのが普通です。
「HTMLメールがソースのまま表示される」の問題に関しては、Content-Type の付き方に注目してください。
ただし、実際に起こっている問題によっては、不適切な Content-Type が付いてしまうという文脈の中で、charset 指定も間違った内容になるようなケースはあるかもしれません。そのような場合、典型的には「文字化け」をともなうと思います。
時間が経っているので、すでにいろいろ試されているかと思いますが、次の諸点は試されましたか。
フォント制御やテキストエンコーディングではなく、[オプション] -> [編集] -> [一般] の右下段にある [送信テキスト形式] の内容を確認し、可能なら設定を変えて、自分宛の送信、返信、再返信を試してみてください。同じ設定は、メッセージ作成ウィンドウのメニューバーから、[オプション] -> [送信形式] でも切り替えられます。
送信や返信の前には、必ずいったん下書き保存し、そこでメッセージソースを開いて Content-Type を確認しておくと、自分から間違った内容で送信していないかどうかを確かめられるでしょう。
いくつかのパターンで自分宛に送信、返信、再返信をくり返して、HTML パートが Content-Type: text/plain; に変わってしまうケースがないのであれば、少なくとも godmacchi さんの Thunderbird に原因がある可能性はほぼ除外できるかと思います。
あとは、「ある特定の人」の環境条件と具体的なすり合わせばできればいいのですが......。
（補足）
上記は電子メールの文脈で述べましたが、前便でも触れたように、セキュリティ対策ソフトの類が干渉してメールヘッダ（Content-Type）を改変してしまうケースも実際にあります。
一度にあれもこれも点検作業はできないと思いますが、メールソフト以外の影響も念頭に置きつつ、まずは電子メールとしての基本的な点から調べてみてください。
とりあえず以上です。的外れな話だったらすみません。
（おことわり）
現在、健康上の制約により不定期な書き込みしかできなくなっています。すぐに応答できない場面がかなり多くなりますことを、ご容赦ください。
ログイン
ユーザー登録
FAQ
検索
