送信メールの文字コードをShift JIS固定にするには？

sariさんへ
>本語のテキスト自体が一種のバケモノ…（エスケープ・シークェンスが
>一つ落っこちただけでASCII文字の正体をあらわす）　
>季節を問わず正しく「出る」ようになってほしいものです。
同感です。

>これによれば、UTF-8で文字化けするメーラの方が多いのが現実という認識は誤っているといえそうです。
相変わらず議論のすり替えですね。私は「SJISで文字化けするメーラよりUTF-8で文字化けするメーラの方が多いのが現実ではないの？」と書いています。UTF-8で文字化けするかしないのかを比較しているのではなく、SJISとUTF-8で比較しているんです。
現実にTedさんはSJISで送って苦情が来たことは無いとおっしゃっています。
msg1や4.1.1.1ではにさんは「SJISは使わないでください。SJISを使うぐらいならUTF-8にしなさい。」と明言されています。私はそこに反論しているのです。iso-2022-jpがベストなのは自明です。SJISとUTF-8を比較した場合、使える文字が増えることより、相手側で文字化けしないほうがベターに決まってます。
「SJISを使ってはいけない」というのは、昔本当にSJISを生で流していたメーラが存在していたころの常識であって、少なくともどの文字セットであっても7bit符号化されるMail.appには当てはまらないと思いますよ。

＞どなたかが、MacOSX の SJIS に含まれる文字種には
＞機種依存コードは含まれてない、というコメントがありましたので
それはわたしのコメントだと思いますが、そうは言っていません。機種依存文字を含まないのは、Apple Mailの「日本語（Shift JIS）」であって、MacのShift-JIS（MacJapanwse）ではありません。
＞sjis なんか使うと、よく調べて使わないと、
＞機種依存文字がいとも簡単に紛れ込みます。
繰り返しになりますが、Apple Mailの「日本語（Shift JIS）」は、機種依存文字を含みません。機種依存文字入りのメールを作成して「日本語（Shift JIS）」を指定するとアラートが出て送信できないので、「紛れ込む」ことはありません。
一方、Apple Mailの送信するISO-2022-JPには、（これはISO-2022-JPの規格上の問題ではなくApple Mailの仕様の問題ですが）多くの機種依存文字が紛れ込み、受信者側で（自分で受信した場合さえ）文字化けします。
そのようなわけで、Apple Mailに関しては、機種依存文字は「日本語（Shift JIS）」を否定する根拠にはなりません。なお、ISO-2022-JPよりもShift_JISを使ったほうがいいと主張しているわけではありませんので、念のため。

＞どなたかが、MacOSX の SJIS に含まれる文字種には
＞機種依存コードは含まれてない、というコメントがありましたので
それはわたしのコメントだと思いますが、そうは言っていません。機種依存文字を含まないのは、Apple Mailの「日本語（Shift JIS）」であって、MacのShift-JIS（MacJapanese）ではありません。
＞sjis なんか使うと、よく調べて使わないと、
＞機種依存文字がいとも簡単に紛れ込みます。
繰り返しになりますが、Apple Mailの「日本語（Shift JIS）」は、機種依存文字を含みません。機種依存文字入りのメールを作成して「日本語（Shift JIS）」を指定するとアラートが出て送信できないので、「紛れ込む」ことはありません。
一方、Apple Mailの送信するISO-2022-JPには、（これはISO-2022-JPの規格上の問題ではなくApple Mailの仕様の問題ですが）多くの機種依存文字が紛れ込み、受信者側で（自分で受信した場合さえ）文字化けします。
そのようなわけで、Apple Mailに関しては、機種依存文字は「日本語（Shift JIS）」を否定する根拠にはなりません。なお、ISO-2022-JPよりもShift_JISを使ったほうがいいと主張しているわけではありませんので、念のため。

一寸整理してみますと、iso-2022-jp を使うのがベストであるのは、みなさん異論のないところです。
次ぎに、果して、sjis でもいいのかどうかです。ここで見解が分かれているわけです。私は、sjis など機種依存コードの関係で混乱の元であるし、わざわざ sjis を使わなくても、sjis で間に合うのなら、iso-2022-jp でも十分間に合う(メーラとの相性でいえば、iso-2022-jp の方がいいとさえいえる)のだから、sjis を勧めるのは害はあっても利はないと考えます。その上で、sjis を使うぐらいなら、utf-8 を使う方がはるかにメリットが多い、といっているのです。
> UTF-8で文字化けするかしないのかを比較しているのではなく、SJISとUTF-8で比較している
論理的に考えればたいして変わらないと思うけど。sjis メールを受けられないメーラは少ないでしょうから、utf-8 が受けられるメーラがどれぐらいあるか見ればいいという論法です。ただ、先に上げたホームページで分かるように、Eudora-J (1.3.8.8r7)は MIME にも対応してないとなると、まともなメーラが送った sjis メールも読めないでしょうね。これを除くと、utf-8 メールを受けられないのは、Netscape の4.x だけです。いまどき、ブラウザとしても問題を生ずるところが多いでしょうから、これを使っている人がそんなに多いとは思えません。というようなことを考えれば、utf-8 メールを受けられないユーザがそれほどいるとは思えません、ということです。
> 現実にTedさんはSJISで送って苦情が来たことは無い
これは Ted さんの特別な事情というか、環境というかそういう、ある意味特殊な事例ではないですか？
Ted さんが使う分には、sjis でもいいのかもしれませんが、ここは不特定多数の人が見る掲示板です。同じ様な悩みを持つ人がこのスレッドを読んで、そうか、sjis にすればいいのだ、とは考えてほしくないのです。
Ted さんが sjis でいいというときに、果して、iso-2022-jp を試した上での話なのか疑問ということもあります。もし、Ted さんのメール相手が iso-2022-jp ではダメで、sjis しかダメということなら、その相手はものすごく特殊、むしろ、まともなパソコン使ってない、と断言していいぐらいと思います。
実際、私は日に何百通というメールを受けますが、sjis メールなんてほとんど見たことありません。それぐらい使われてないのです。そんなものを勧める気にはなりません。
「SJISを使うぐらいならUTF-8にしなさい」というのは、
utf-8 というと反発なさる方が多いですが、現状では、utf-8 もそれほど忌み嫌うべき状況ではないということです。むしろ、多様な文字種が使える、現在では既にかなりのメーラが対応している、ということでメリットが多いのでは、といっているのです。もちろん、これは Ted さんに強要は出来ませんが、ここは不特定多数の人が読むところということなら、現状認識ということで、そういう意見を書いてもよかろう、と思うのです。
多様な文字種が使えるメリットは大変大きいです。例えば100人程度の名簿を作っても、sjis の文字種だけでは必ず不足します。utf-8 なら、これがぐっと減ります。また、外国の人名地名も純粋のアルファベット(us-ascii)だけで対応できることは少ないです。そんなとき、utf-8 は大変有効です。

私も、 OS X 10.4 にバージョン・アップしてから,「返信」メールに限って「文字化けしている」という苦情に悩まされるようになりました。はじめは「テキストエンコーディング」をいじって対策しておりましたが、しばしば忘れて送信してしまうので、「環境設定」の「作成」で「返信レイアウト」の受信メッセージと同じフォーマットを使う」のチェックを外したら、文字化けが起きなくなりました。ご検討下さい。

後藤様、
　ありがとうございます。
　「受信メッセージと同じフォーマットを使う」はチェックになっていました。外してみます。チェックしておいたほうがいいような気がしますから、ちょっと不思議な気がしますが、、、

Tedさん、こんにちは。
>「受信メッセージと同じフォーマットを使う」はチェックになっていました。
私のところは、10.4.7ですが、ずーと、このチェックを外し、テキストで相手にメールを送っています。文字化けの苦情が来たことは、10.0か10.1の初期の頃だけだったように記憶してます。

これは、リッチテキストなどのhtmlフォーマットの場合、Mail.appがテキスト部の文字コードをUTF-8にするためだと思います。WindowsのOutlookやOutlook Expressではデフォルトがhtmlフォーマットになっているという極悪な仕様のため、テキストで十分なメールでも平気でhtmlフォーマットで送って来るWindowsユーザがたくさんいます。こうしたメールに「同じフォーマットを使う」設定で返信すると、UTF-8で送られてしまいます。htmlメールを送ってくるような人は、たいていテキストエンコードについても無知ですから、エンコードをUTF-8に変更すればちゃんと見れる事もわからず、「文字化け」の苦情となる訳です。
こういった事情から、「同じフォーマットを使う」設定はオフにしておくのがMac側の常識となります。
ただし、この設定をオフにしても、機種依存文字が含まれるメールを引用したまま返信すればUTF-8で送られてしまうことに変わりはありません。「全文引用はしない」という対策も重要です。

＞これは、リッチテキストなどのhtmlフォーマットの場合、
＞Mail.appがテキスト部の文字コードをUTF-8にするためだと思います。
フォーマットとcharsetは基本的には独立ではないでしょうか。たとえば、自分宛に本文が「1」のリッチテキスト・メールを送った場合、以下のようになります。
　　Content-Transfer-Encoding: 7bit
　　Content-Type: text/html;
　　　　charset=US-ASCII
また、「受信メッセージと同じフォーマットを使う」にチェックを入れた状態で、上のメールを全文引用した上で「あ」と返信した場合、以下のようになります。
　　Content-Transfer-Encoding: 7bit
　　Content-Type: text/html;
　　　　charset=ISO-2022-JP
ただし、Apple Mailの作成するhtmlでは、行頭の半角スペースをNO-BREAK SPACE（U+00A0）で表現するため、本文が「 あ」のような（行頭のスペースを含む）リッチテキスト・メールでは、以下のように（htmlパートのみ）UTF-8になります。
　　Content-Transfer-Encoding: quoted-printable
　　Content-Type: text/html;
　　　　charset=UTF-8
つまり、リッチテキスト・メールでは一律にUTF-8になるわけではなく、意図せずUTF-8になる場合があるということだと思います。

私がいくつかのhtmlメールに返信テストしてみたところでは、すべてcharset=UTF-8、encoding=QPでした。
これもchaset=SJISの場合のencoding方法同様、何らかの法則に基づいているのでしょうか？仕様がよくわかりませんね。ただ、テスト結果からみて、普通のhtmlメールに返信すると、UTF-8になる場合の方が多い気がしますが。

＞私がいくつかのhtmlメールに返信テストしてみたところでは、
＞すべてcharset=UTF-8、encoding=QPでした。
おそらく、実際に受け取るhtmlメールは、しばしば企業発のものであるため、デザイン上の要請からISO-2022-JPにない文字を含みがちなのではないでしょうか。
たとえば、iTunes Music Storeからのhtmlメールはcharset=ISO-2022-JPですが、毎回U+00A0 NO-BREAK SPACEとU+2022 BULLETが実体参照で使われており、これを引用してリプライすると、（実体参照のままではなく、再符号化されて）charset=UTF-8となります。
また、他の企業からのhtmlメールでは、U+00A9 COPYRIGHT SIGNやU+00AE REGISTERED SIGNなどが、実体参照で使われていました。
このような実体参照のケースに加え、行頭のスペース、ISO-2022-JPにおける機種依存文字など、（他にもあるかもしれませんが）複数の原因により、htmlメールを引用して返信した場合にcharset=UTF-8となることが多いのだと思います。

私が返信テストしたメールは、いずれも友人からのもので、単にデフォルトと知らずにhtmlで送ってきたものや、一部文字に色付けしただけの、ごく普通の文字メールであり、機種依存文字なども含んでおりません。
多分私が見落としている原因がどこかにあるのでしょうが、あの程度のメールに返信してUTF-8になるのなら、ほとんどすべてUTF-8になりそうな印象です。

わたしが友人からのhtmlメールに返信してcharset=UTF-8となった原因は、空行の行頭スペースでした。返信メールのソースに「=C2=A0」（NO-BREAK SPACE）は含まれていませんか？　これがハズレなら、あとは現物でも見ないとわかりません。

もう一度チェックしてみました。確かに先頭に空白が入ってますね。というか、私がテストしたhtmlメールは全部Outlook Expressで作成されてますが、Outlook Expressでは、テキストで空行になっている部分は、すべて空白一文字の「<DIV> </DIV>」に変換されているようです。これでは空行を含むメールは全部該当してしまうことになりますね。
多くの方が文字化け（UTF-8送信）に悩まされるのは、この辺りに理由があるのかも。