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

最近、わたしの送ったメールが文字化けして見えない、と多くの苦情が寄せられています。どうもUnicodeで送られた場合に読めないことがわかりました。そこで、送る時には、「メッセージ」メニューの「テキストエンコーディング」から毎回Shift JISにテキストを変換してから送るようにしています。でも、Shift JISにいつでも固定して送るように設定できれば、このようなわずらわしいことをしなくてもすみます。どなたか方法をご存知でしょうか?

投稿日 2006/09/10 06:07

返信: 66

2006/09/12 07:51 Community User への返信

>Subject部はquoted-printableで7bit符号化されていますが、本文はBase64で7bit符号化されています。

あれ?昨日PMG5で送信テストしたときは確かにquoted printableで符号化されていたのですが、今PBG4でテストするとBase64だな・・。これはもう一度確認します。
>ただのテキスト部をわざわざBase64化されている所をみても、Mail.appとしても不本意なエンコードと言う事も出来るのではないでしょうか? 8bitなので、するしかないんだ、と。Base64やquoted-printableで正しく7bit符号化出来て、相手先で正しくデコード出来ても、やはりこれはイレギュラーだとは言えないでしょうか?
そういう意味では、UTF-8だって同じですよね?ことさらSJISはダメという理由にはなりません。JISなら確かに再符号化無しでそのまま通りますし、歴史的に正当というのはわかりますが、JISにしても国際的にはローカル規格でしかなく、相手がデコードできない環境なら文字化けする事に変わりありません。双方が正しくエンコード/デコードできれば、別にSJISだろうが何でも構わない訳です。
基本的にMail.appが勝手にUTF-8に変更して送信してしまうことで問題が広がっているのは間違いなく、これは私も直して欲しい仕様ではあります。Entourageでも、機種依存文字が含まれる場合、警告は出ますが、やはりUTF-8で送信してしまいますね。
ただ、まだUTF-8を自動判定できないメーラが蔓延している現実からみても、SJISは使わずUTF-8にすべき、という意見には疑問を持ちます。決してSJISが良いとは思いませんが、相手がUTF-8を自動デコードできない環境なら、まだSJISのほうがましなのは確かなんですから。インターネットでは、相手の環境は様々であり、それを考慮するのが正当であったはず。今時UTF-8も使えないメーラなんぞ使うな、という意見にも賛成はできません。

2006/09/12 09:10 Community User への返信

>あれ?昨日PMG5で送信テストしたときは確かに
>quoted printableで符号化されていたのですが、
>今PBG4でテストするとBase64だな・・。
推測ですが、「なるべくデータ量が大きくならない方法でエンコードする」という仕様ではないでしようか(ASCIIの範囲内の文字が多ければquoted-printable、そうでなければBase64)。

2006/09/12 09:31 Community User への返信

>あれ?昨日PMG5で送信テストしたときは確かに
>quoted printableで符号化されていたのですが、
>今PBG4でテストするとBase64だな・・。
推測ですが、「なるべくデータ量が大きくならない方法でエンコードする」という仕様ではないでしょうか(ASCIIの範囲内の文字が多ければquoted-printable、そうでなければBase64)。

2006/09/12 09:53 Community User への返信

> JISにしても国際的にはローカル規格でしかなく、
えーと、メールで使うのは、iso 2022 jp で JIS ではありません。bit8 を使わないだけですけど。JIS には半角片仮名が入っています。
しかし、「ローカル規格」という言葉で何を言われたいのか分かりません。そんなこと言えば、どこの国の言葉でもローカル規格です。日本のユーザなら、規格に準拠した欧米語のメールを受けても、フランス語、スペイン語、その他純粋の英語以外のメールだと正しく表示できないパソコンを使っている人はいくらでもいます。
こんな問題と、SJIS、iso 2022 jp とをいっしょくたにしないでください。
> 相手がUTF-8を自動デコードできない環境なら、まだSJISのほうがましなのは確かなんです
> インターネットでは、相手の環境は様々であり
そういうときは、iso 2022 jp を使えばいいです。
SJIS の問題点は機種依存コードです。極端にいえば、相手がパソコンを違うメーカの製品に変えるだけで(同じ Windows であったとしても)意図した通りには表示してくれなくなり得るのです。相手の環境は様々なら、ますます、iso 2022 jp で送るべきです。
Kawabe さんのような方が SJIS メールを勧めるのは理解できません。Kawabe さんもご指摘のように、機種依存文字を受けると utf-8 で返すメーラは今たくさんあります。SJIS メールを使おうものなら、混乱はますます深まるばかりです。

2006/09/12 11:14 Community User への返信

>SJIS の問題点は機種依存コードです。
一般論としてはご指摘のとおりですが、Apple Mailの「日本語(Shift JIS)」は、JIS X 0208:1997が定義しているシフト符号化表現(IANAに登録されているShift_JIS)であり、機種依存文字を含みません。
半角カタカナを含むメールを送信する場合、Apple Mailは「自動」ではISO-2022-JP(もどき)で符号化しますが、それよりはShift_JISを使ったほうが(実用的かどうかはさておき)「正しい」とは言えると思います。

2006/09/12 11:45 Community User への返信

ところで,トピ主のTedさんは英語環境ですか? それなら簡単に解決しそうですが,そうではなくて日本語環境なのに文字化けするのでしょうか?

2006/09/12 16:28 Community User への返信

>iso 2022 jp で JIS ではありません
そうでしょうか?一般的にJISコードと言われるのはJIS X 0201 Roman(半角カナを含まない)+JIS X 0208であり、これがiso-2022-jpと理解していますが。
>こんな問題と、SJIS、iso 2022 jp とをいっしょくたにしないでください。
同じと思っています。はにさん自身がおっしゃっているように「「ハーイ」といえば、地球の彼方の電話機の向こうの相手に「ハーイ」と聞こえる、それだけで十分」だと思いますから。iso-2022-jpであろうがSJISであろうが、相手にちゃんと届けば問題ないんじゃないですか?(それが「ローカル規格」と表現した意味です。)現実的に、SJISで送って問題になる場合があるでしょうか?もちろんiso-2022-jpがベストなのはいうまでもありませんが、それは歴史的に確実に全ての日本語メーラが実装しているといえるからであり、iso-2022-jpで送らねばならない訳ではありません。現実には、SJISが広く使われている事から、ほとんどすべての日本語メーラがSJISを正しくデコードできていると思います。
繰り返しますが、私は決してSJISを勧めている訳ではありません。SJISを使うと混乱が深まると仰る理由がわからないだけです。実際にどんな混乱が起こっているというのでしょう?SJISで送って文字化けした方がおられるのでしょうか?
むしろ、まだそれほど広まったとは言えないUTF-8の方が問題を起こしているのが現実だと思いますが。

2006/09/12 20:07 Community User への返信

> 現実には、SJISが広く使われている事から、ほとんどすべての日本語メーラがSJISを正しくデコードできていると思います。
確かめてみましたか?
うちでやってみた限りでは、例えば、本文に丸囲みの数字とかのちょっと怪しい文字(とはいっても x208 に入っています。ことえりの文字パレットでもsjisコードを表示します)を入れてsjis で送ろうとすると、「テキストを指定された文字コードでデコードできません」とエラーになります。うまく送れても異なる文字になっていたりします。しかし、utf-8 ならエラーにならず送れますし、Windows 機であろうが、Linux 機(2年程前にインストールしたシステムで決して新しい物ではありません)であろうがgoogle mail であろうが、このメールを受信して正しく読めます。ただ、Linux の場合には、すべての文字を表示できるフォントが入ってないためか、表示できない文字も出ますが。Windows 機では、さらに、丸囲みの月火水(これらはutf-8 でしか入れられない)とか入れても、全く問題なく正しく表示されます。
これで見ると、Mail.app は皆さんの好きな sjis を正しく扱えないのか、MacOSX の sjis コードが機種依存になっているかどちらか、ということになります。すでに、OS レベルでは、OSX だけでなく、Windows でも、Linux でも、 utf-8 でファイルシステムを構築するのは当たり前になってますし、utf-8 の方がシステムとの相性は良くなっています。
sjis コードとされている文字種も使えないのでは、わざわざ sjis にして使う意味がありません。

2006/09/12 20:59 Community User への返信

PMG5でもう一度、日本語を多くしてテストしてみましたが、やはりquoed-printableになりました。長文の日本語でやってみるとBase64になることもありますし、PGB4でテストしたのは短いメールでしたが、Base64でした。
どうもまだ法則はつかめていません。どなたかご存じないでしょうかね?

2006/09/12 21:09 Community User への返信

論点を些末な方向に持って行こうとされますね。誰も機種依存文字を使う場合の話などしていませんよ。SJISで送った場合の話であって、送ることの出来ない文字についてなど議論の対象にはしていません。なぜSJISはダメでUTF-8にすべきなのか、その理由は丸数字が使えるからなんですか?
どの文字セットを使おうが、(インターネットの規約に違反していない限り)相手が受け取れればそれでいい、というのが私の考えであり、今のところSJISで文字化けするメーラよりUTF-8で文字化けするメーラの方が多いのが現実ではないの?といっているのですが。

2006/09/12 21:35 Community User への返信

>本文に丸囲みの数字とかのちょっと怪しい文字(とはいっても x208 に入っています。
>ことえりの文字パレットでもsjisコードを表示します)を入れてsjis で送ろうとすると、
>「テキストを指定された文字コードでデコードできません」とエラーになります。
U+2460 CIRCLED DIGIT ONEなどの丸付き数字のことでしたら、JIS X 0208にもShift_JIS(シフト符号化表現)にも入っていません。だからこそ、Apple Mailはそれを「日本語(Shift JIS)」では送信せずにアラートを表示するのです。

2006/09/12 22:00 Community User への返信

丸囲み数字は機種依存文字でしたね。どなたかが、MacOSX の SJIS に含まれる文字種には機種依存コードは含まれてない、というコメントがありましたので、そうか、と思っていたのですが、そうじゃないですね。ことえりの文字コードで JIS X 208 と表示されていても、機種依存コードがたっぷり含まれてますね。(x208 には自由に定義できる領域がある)
> なぜSJISはダメでUTF-8にすべきなのか、その理由は丸数字が使えるからなんですか?
文字種を気にせずに自由に使えることはいいことじゃないですか?丸囲み数字、文字なんて使いたい人はとても多いのではないでしょうか?全角の1文字分に「平成」、「昭和」「(株)」などと入れた物とか。文字化けが問題になるときにはいつもこういう文字が原因ですから。utf-8 ならどれでも自由に使えます。
utf-8 で文字化けするメーラというのは基本的にバージョンが大分古いのではないですか?新しいバージョンに限れば、文字化けしない物の方が圧倒的と思いますが。
sjis 使うぐらいなら、iso-2022-jp を使いなさい、というのが主張です。sjis なんか使うと、よく調べて使わないと、機種依存文字がいとも簡単に紛れ込みます。機種依存文字を使わないのなら、iso-2022-jp でもほぼ同じ文字種が使えます。

2006/09/13 03:49 Community User への返信

>「なるべくデータ量が大きくならない方法でエンコードする」という仕様ではないでしょうか(ASCIIの範囲内の文字が多ければquoted-printable、そうでなければBase64)。
和文テキストに関しては、私もそうではないかと思います。abcdefgさんが紹介されていたWebページ(『連載:インターネット・プロトコル詳説』)にも、8ビットデータの7ビット変換後のサイズ変化に関する言及がありましたね。:
「ASCIIコード以外のデータが多少混ざる程度のデータであれば(Quoted Printableが)効率的だが、通常のバイナリであればBase64の方がサイズは格段に小さくなる。(注:元データの約1.3倍)そうした理由から、Quoted Printableは欧米でよく使われるが、日本ではあまり使われない傾向にあるようだ。」
ヘッダは本文に比べて短いので(つまり変換後もデータサイズはそれほど増えないので)時にはQPで符号化されることもあるのでは?

2006/09/13 04:21 Community User への返信

abcdefgさんへ
>少し調べたところ、こんな記事がまとめられていました。

上の記事、よく探して下さいました。電子メールの歴史から現行のメールソフトが抱える諸問題(山本さんの「ああWindows」や「ああ文字化け」にもらい泣き)まで、教えられたことがいっぱいです。
 
 1. かしこくないメールプログラム → 文字化け
 2. 互換性のないメーラ → 同上
 3. 不適切な文字セットと文字コード → 同上
 4. 厳密には仕様違反のデータ形式(8ビットやバイナリ)をはねつけるサーバ → 同上
 5. 配送システムの誤動作 → 同上
[化け止め策]
* 優れたMIMEメールリーダ(ソフト)と信頼できる配送システムを使う。
* 化け元かもしれぬ怪しい字の心当たりがあれば、文字パレットの〈コード表〉ペインなどで実体をつきとめておく。(そして使わない。どうしても使いたければ、受信側で問題なくデコードできるような適切なエンコード形式を選ぶ。)
[推奨メール形式]
ぽん太さんのスレッド参照
[非常事態:ある日突然ヘッダや本文テキストの文字化けが始まったら?]
1.〜5.をチェックして思い当たる節がなければ、一時的にPDFでしのぎながら災厄が過ぎるのを待つ。(i.e. 和文メールの場合、見た目がプレーンなテキストメッセージであっても、敢えてメール本文としては送らず、受信者がまちがいなく開けるとわかっている形式の添付ファイルとして送ってみる。)
個人的には上のように対処しようと考えています。
見方によっては日本語のテキスト自体が一種のバケモノ…(エスケープ・シークェンスが一つ落っこちただけでASCII文字の正体をあらわす) 
季節を問わず正しく「出る」ようになってほしいものです。

2006/09/13 06:45 Community User への返信

> UTF-8で文字化けするメーラの方が多いのが現実ではないの?
unicode(UTF-8)への各種メールソフト対応調査というページがありました。
これによれば、UTF-8で文字化けするメーラの方が多いのが現実という認識は誤っているといえそうです。
このページによれば、Windows 98 の Outlook Express ですら、自動だと化けますが、手動で utf-8 にすれば問題なく読めるということです。しかし、Windows ME 以上であれば、Netscape 4.6 という一寸古いのを除けば、自動認識で、まったく問題ないことになっています。MacOS 9.2 でも、Netscape 4.7 以外は問題ないということです。Eudora-J (1.3.8.8r7)は余りに古いということで調べられていません(MIME 対応もないということですから、多分ダメでしょう)。
このページの作者は、すでに、2004 年に、20 種以上のメールソフトを調べて、ほぼ対応できているという結論を出しています。
ウェブメールの対応は悪い、としてますが、今ならもっと対応していることでしょう。少なくとも、google mail は utf-8 メールに対応しています。

このスレッドはシステム、またはAppleコミュニティチームによってロックされました。 問題解決の参考になる情報であれば、どの投稿にでも投票いただけます。またコミュニティで他の回答を検索することもできます。

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

Apple サポートコミュニティへようこそ
Apple ユーザ同士でお使いの製品について助け合うフォーラムです。Apple Account を使ってご参加ください。