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

# MacBookをバラシてたりしてたら読み逃してました。遅replayすみません。
> そういう意味では、UTF-8だって同じですよね？ことさらSJISはダメという理由にはなりません。
当然そうも言えますね。が、Shift-JISをBase64やquoted-printableで7bit符号化して送っている、という意識があればそれはその人の考えという事で「ふむ。」と思えるのですけれど、そうで無かったり、iso-2022-jpであれば良いだけなのに、その辺の背景無しにShift-JISをつかっちゃうのはどうかとも思う訳です。歳なモノで
> 歴史的に正当というのはわかりますが
という事です。正直に言うとどうも違和感があるんですよねぇ。
> 双方が正しくエンコード／デコードできれば、別にSJISだろうが何でも構わない訳です。
7bit符号化して外に出ている事を確認出来て、相手がデコード出来る事を確認取れていれば、という条件では「そうですね」と思います。基本的に7bitで出ていって、相手がちゃんと解釈できる方法で送るべき、という事が大前提です。その為のiso-2022-jpです。（これはhtmlメールにしても、UTF-8にしても、私は同じ事と思います。）
> 決してSJISが良いとは思いませんが、相手がUTF-8を自動デコードできない環境なら、まだSJISのほうがましなのは確かなんですから。
この辺になると個人の考え方ひとつ、って感じもしますね。私個人的にはUTF-8もShift-JISもどちらももらいたくないなぁ。だったらまだhtmlメールの方がいいなぁ、必然性があればですけれど。何度も書きますが、テキストだけならiso-2022-jpで送るべき、それを前提に日本語MUAは設計されているから、と思います。Shift-JISに「わざわざ」する必要性が私には理解出来ません。（だからといってUTF-8とは私は思いませんが。使った事も無いし必要性も感じないし）

> 私個人的にはUTF-8もShift-JISもどちらももらいたくないなぁ。
今はテキストだけのメールでも、utf-8 になっている物はそこそこありますよ。外国（英米で必ずしも utf-8 にする必要がない場合でもそうなっているのがあります。向こうの連中の人名は英米国内でも、移民の子孫とかだと、特殊な文字が使われていたりして、アルファベットだけでは間に合わないからかな？）から来るのでもそうなっているのがあります。OutLook Express （アップデートを当てて最新にしているWindows）を設定すると、テストメールを送信しますが、これも utf-8 でした。utf-8 は出したくなくても、受けられるようにしておくのは必須と思います。
まあ、普通のメーラなら、最近の物なら、何もしなくても utf-8 のテキストメールは何のトラブルもなく表示してしまいますので、意識してないと分かりませんけど。

>その辺の背景無しにShift-JISをつかっちゃうのはどうか
背景を知る必要があるのでしょうか？私が調べた限り、SJISを送信charsetに使えるメーラは（Win/Macを含め）Mail.appだけでした。その意味ではSJISを使うことは特殊と言えますが、使えるということはメーラがちゃんと7bitエンコードしているからであり、普通のユーザがそこまで知る必要は無いと思います。
といって生でSJISが送られることはないのかというと、通常のメーラを使っていない場合、例えばwebのCGIでメールを送信したり、迷惑メールなどのように独自にメールを大量に作成するなど、sendmailを直接使って送信する場合には、まだそうともいえません。私の迷惑メールを調べたところでは、いくつか生のSJISが（ヘッダにすら）使われていることがありました。でも、これは今回のような一般ユーザに対しての場合とは別問題でしょう。
usadii3さんが「違和感」とお感じのように、（私もそうですが）文字コードについて意識している人ほど、SJISで送信する、と聞いただけで「そればダメ」と思ってしまいます。でも、それはMail.appの仕様を正しく認識していないからと思います。Mail.appを使用している限り、「SJISエンコーディングで送信してはならない」というのは独断／偏見だと考えます。
>だったらまだhtmlメールの方がいいなぁ
NAOIさんと私のやりとりでわかるように、Mail.appでは空行が入ったリッチテキストメールにリッチテキストで返信すると、UTF-8になってしまうようです。テキストメールで返信するか、新規に作成した場合には、空行があってもiso-2022-jpになるので、問題ないのですが。
Windowsの古いメーラでは、UTF-8を手動デコードは出来ても自動認識出来ないのが多いのも問題なのですが、現状では全てのWindowsユーザが最新バージョンを使うことを期待するわけにはいきません。マイノリティーであるMail.app側がエンコードをis-2022-jp固定にできるようにすべきでしょう。機種依存文字が文字化けしたとしても、メールの内容は把握出来るでしょうから、苦情が来ることはあまり無いと思います。

> まあ、普通のメーラなら、最近の物なら、何もしなくても utf-8 のテキストメールは何のトラブルもなく表示してしまいますので、意識してないと分かりませんけど。
私、前からの癖で通常のヘッダの他に「Content-Type:」「Content-Transfer-Encoding: 」とかも必ず表示して確認してるんです（まるで、窓枠の埃を指でチェックする姑みたいですね（苦笑））。
# EmacsでMew,Gnus使ってました。WindowsではWinBIFFから始まりBecky!が出てからずっとそれ。

> それはMail.appの仕様を正しく認識していないからと思います。Mail.appを使用している限り、「SJISエンコーディングで送信してはならない」というのは独断／偏見だと考えます。
「Mail.appの仕様を正しく認識」しているのかどうか、という事を言いたいわけです。そういう仕様なのだとわかった上で【敢えてShift-JISエンコードで送る】のと、そうでないのとでは違う。Mail.appでShift-JISエンコードで送れるけれど、それがトピ主さんの言うようにベストの選択肢ではない、他のMUAでは通常それは出来ないし、一般的ではない、Mail.appで出来るからとそれがベストと思ってはいけない、他のMUAに乗り換えた時にもShift-JISエンコードをしたいそれがベストだからと思い込まないで欲しい、と。独断かつ偏見でもあるかもですが。私はそう思う、というぐらいにとどめておきます m(__)m　
ただ、ホントにそれが「仕様」なのか？とはちょっと思います。
> その意味ではSJISを使うことは特殊と言えますが、使えるということはメーラがちゃんと7bitエンコードしているからであり、普通のユーザがそこまで知る必要は無いと思います。
ほんとに仕様であれば、です。個人的には、これはたまたまでは無いかともちょっと思うのです。後者であればたまたまShift-JISエンコード出来て（しまい）、Mail.appが後付け的に7bit符号化して送っているんだとすると、これは注意しなくてはいけない事では？と。そうで無くても無理やり送信時にShift-JISを指定しなくてはいけない作業をしているのは既に普通のユーザーではなくて、敢えてShift-JISを指定しているユーザーと言えましょう。普通のユーザーは単に返信したら、文字化けしたと言われた、と思うだけです。で、iso-2022-jpに固定できたら良いのに、と言われた、と相談するだけではないかと。
> マイノリティーであるMail.app側がエンコードをis-2022-jp固定にできるようにすべきでしょう。機種依存文字が文字化けしたとしても、メールの内容は把握出来るでしょうから、苦情が来ることはあまり無いと思います。
激しく同意。この様な内容のフィードバックを送ってはいるのですが。どぉかなぁ。まぁ、それに我慢できない人は（私みたいな）他のMUAを使えば良い事で。みんなでフィードバックいれれば動いてくれるんじゃぁないかなあと。。。

＞向こうの連中の人名は英米国内でも、移民の子孫とかだと、特殊な文字が使われていたりして、アルファベットだけでは間に合わないからかな？
US-ASCIIだけでは間に合わないヨーロッパ言語の時は、7bitのUTF-8どころか8bitエンコードのメールが来ます。（Content Typeはtext/plain）それでも誤りなく中継してくれるメールサーバとそれを表示できるMail.appはありがたいですね。
文字化けに困惑するのは「昨日までだいじょうぶだったのに急に化けだした」という時です。エンドユーザが使用しているメーラの互換性のなさだけが原因だったら、初めからメッセージをやり取りできない（読めない）はず。メールを中継するサーバ／配送システムのエラーやメインテナンスの不備も結構多いのではないかと思いますが。