【特集】
文字化けを出さないメール術
代表的症状の原因と予防法
受け取ったメールを開いてみたら、何やらワケのわからない文字が並んでいた。普通のテキストで送ったのに、文字化けで読めないと言われた…。こんな文字化けによる被害は、インターネットメールを使っている人なら誰でも経験したことがあるはずだ。もちろん、これではメッセージがきちんと伝わるわけがなく、メールを送り直したり、それでもダメなときはFAXを使ったりと、後始末が面倒なことこの上ない。
そこで今回は、メールの文字化けの原因を解説しながら、自分がメールを作成する際、どうすれば文字化けが避けられるのかを紹介していく。
●症状1 本文が文字単位で文字化けしている
まずは、軽い症状から見ていこう。ほとんど正常な日本語で表示されているが、途中の1文字から数文字だけが変な文字(文脈にそぐわない記号や四角いマークなど)になっているという例。文章の意味がわからなくもないが、やはり気持ちが悪い。
原 因 本文に機種依存文字が含まれている
予防法 メール作成時には機種依存文字を使わない
「cm」や「(株)」などを1文字にした省略記号、丸付き数字、ローマ数字などは機種依存文字と呼ばれ、違う機種では正常に表示することができない。例えば、Windowsでメール文中に丸付き数字の「1」を使った場合、Macintoshで受け取ると「(日)」という記号が表示されてしまう。これは、機種によって記号に割り当てられた番号が違うため。その番号に対応する記号がない場合は、四角い記号や空白が表示される。
インターネットメールでは、さまざまな機種で読まれる可能性がある。したがって、メールを書く際は、機種依存文字を使ってはならない。おおまかに言って、記号を使うときは、キーボードから直接入力できないものは使わないほうが無難だ。
●症状2 本文の全部または一部が文字化けしている
次は、もっとも深刻な症状。添付ファイルでもないのに、本文がエンコードされた状態(症例参照)や文字化けになっている場合だ。本文が全部文字化けしてしまうときと、途中から文字化けしてしまうときがある。
■症例1 Shift-JISコードの本文がbase64でエンコードされた例
gXmLxopFk66M/IF6DQoNCkVyaWNzc29ugUFJbnRlbILIgsc1jtCCqoOCg2+DQ4OLkluWloz8gq+W
s5D8kNqRsYtaj3CC8JStlVwNCg0KgaFVUkwNCmh0dHA6Ly93d3cuYmx1ZXRvb3RoLmNvbS8NCmh0
dHA6Ly93d3cuYmx1ZXRvb3RoLmNvbS9uZXdzL3RleHQvcHJlc3M0Lmh0bSCBaZStlVyOkZe/gWoN
■症例2 JISコードの本文がquoted-printableでエンコードされた例
=1B$B!!$5$F!"$U$H;W$$N)$C$F!"?73cJ}LL$K$U$i$C$H=P$+$1$h$&$+$H;W$&$N=1B(J
=1B$B$G$9$,!"$J$s$+$3$N;~4|!"$*$b$m$$$H$3CN$j$^$;$s$+!)=1B(J
■症例3 Shift-JISコードの本文がquoted-printableでエンコードされた例
=81=40=82=b3=82=c4=81=41=82=d3=82=c6=8e=76=82=a2=97=a7=82=c1=8
2=c4=81=41=90=56=8a=83=95=fb=96=ca=82=c9=82=d3=82=e7=82=c1=8
2=c6=8f=6f=82=a9=82=af=82=e6=82=a4=82=a9=82=c6=8e=76=82=a4=82=cc
■原 因 8bitの文字コードで送信された
■予防法 メールソフトで送信する文字コードは「JIS(ISO-2022-JP)」に設定する
本文に半角カナや欧文8bit文字を使わない
パソコンで日本語を扱うための文字コードには、いくつかの種類がある。WindowsやMacintoshで使われている「Shift-JIS」、UNIXで主に使われている「EUC」などだ。一方、インターネットでは7bitの文字コードでやりとりするのが標準なので、日本語の場合は7bitの「JIS(ISO-2022-JP)」という文字コードを使うよう定められている。Shift-JISやEUCは8bitの文字コードなので、送信の際、メールソフトがこれをJISに変換するのが普通だ。
ところが、ソフトによっては、他の文字コードで送信するように設定できたり、本文中に半角カナが含まれているとそれを8bitコードで送信するものもある。半角カナはJISには含まれていないので、変換せずそのまま8bitのShift-JISで送信してしまうのだ。ラテン語やアラビア語など、欧文の8bit文字についても同様だ。
さて、メールが8bitコードで送信されたとき、まず考えられるのは、本文がbase64やquoted-printable形式でエンコードされてしまう現象だ。サーバーの種類や設定によっては、これを8bitコードのバイナリデータと認識するものもあり、メールがこのようなサーバーを経由した場合にエンコードされることがある。base64やquoted-printableは、バイナリファイルを添付する際に使われるエンコード/デコード方式で、通常は本文がこれでエンコードされることはない。したがって、たとえ本文がエンコードされて送られてきても、受信したソフトは、デコードせずにそのまま意味不明の文字列を表示してしまう。
次に考えられるのが、途中で8bit目が抜け落ちてしまうという現象。正常な文字コードで表示できず、文字化けとなる。
もちろん、無事8bitのままでメールが届くこともある。また、無事届いたように思えたが、途中から全部文字化けしてしまうということもある。これは、本文は7bitコードだが、半角カナのみ8bitコードで送信されたときだ。いずれにせよ、8bitの文字コードで送るのは問題があるので、送信する際の文字コードは「JIS(ISO-2022-JP)」に設定し、メール中に半角カナを使わないようにしなければならない。
代表的なソフトの文字コードを見てみると「Outlook Express」や「Netscape Messenger」は、デフォルトで7bitに設定されているので問題はない。「Microsoft Internet Mail」では、JISに設定しても、条件によってはなぜか8bitで送信されてまうことがあるようだ。詳しくは「Microsoft Internet Mailの問題」というページに解説されている。「Eudora Pro 3.0」はJIS以外の文字コードにも対応しているので確認が必要だ。Windows版を例にとると、まず「ツール」メニューから「オプション...」を選び設定ウインドウを開く。その中の「日本語環境」で「JIS7」を選択すればOKだ。また「JIS X 0201カナを黙認する」のチェックは、はずしておく。こうしておけば、もし文中に半角カナを使ってしまった場合でも、送信時に自動的に全角カナに変換される(設定画面)。
なお、文字化けメールを受け取った場合の対処法については「The Web KANZAKI」に詳しい解説がある。この中の「文字化けしたメールの修復」では、ホームページ上のフォームに文字化けしたテキストを入力し「解読」ボタンを押すだけで、元の文章を解読してくれる機能がある。また、複雑な文字化けについても、手作業で解読する方法が紹介されている。ここでは、なぜ、文字化けで「$」や「%」、画数の多い漢字や半角カタカナがよく出てくるのか、その理由もわかる。ほかにも、文字コードやインターネットメールで日本語を扱うときの規格について詳しく解説されているサイトがあるので、いくつか挙げておく。
■The Web KANZAKI
http://www.kanzaki.com/
■文字化けしたメールの修復(The Web KANZAKI)
http://www.kanzaki.com/docs/jis-recover.html
■日本語と文字コード(The Web KANZAKI)
http://www.kanzaki.com/docs/jcode.html
■インターネットでの日本語メール(The Web KANZAKI)
http://www.kanzaki.com/docs/jis-mail.html
■Microsoft Internet Mailの問題(HATのホームページ)
http://www02.so-net.or.jp/~hat/mailer/ms.txt
■インターネットメールの注意点(HATのホームページ)
http://www02.so-net.ne.jp/~hat/imail/cover.html
●症状3 本文の途中にタグが入っている
厳密には文字化けではないが、最近蔓延しつつあるのがこの症状である。本文中になどのタグが挿入されており、文の意味はわかるものの、邪魔で読みにくい。出した本人のソフトは対応しているために気が付かないのだろうが、もらったほうはかなり迷惑する。予防さえすれば確実に解決できるものなので、しっかりと対処しておきたい。
■原因1 HTMLメールで送信された
■原因2 enrichedテキストで送信された
■予防法 通常のテキスト形式で送信する
HTMLメールは、文字の大きさや色、位置、背景の色などを、ホームページと同じようにレイアウトできる形式のメールだ。代表的なソフトでは「Outlook Express」や「Netscape Messenger」がこれに対応している。未対応のソフトでは、タグがそのままテキストで表示されてしまうか、レイアウトが反映されない状態で表示される。
したがって、相手が対応ソフトを使っているのが確実な場合以外は、すべて普通のテキスト形式で送信するようにしたい。特にOutlook Expressでは、レイアウトを指定しないメールもすべてHTML形式で送信するようデフォルトで設定されている。インストールした後、設定を一度も変更しないで使っていると、送信したメールがすべてHTML形式になってしまうのだ。一方、Netscape Messengerでは、レイアウトを指定していないメールは普通のテキスト形式で送信される。また、レイアウトを指定した場合も、送信時にHTMLで送信するかどうかダイアログで確認してくるので、ここでテキスト形式を選択することもできる。ただし、HTMLメールをまったく使わないというのなら、初期設定で機能を切ってしまうのがいいだろう。
Outlook Express(Windows 95版)でHTML送信を行なわないようにするには、まず「ツール」メニューから「オプション...」を選択し、初期設定ウインドウを開く。「送信」の項目をクリックし、その中の「メール送信の形式」で「テキスト形式」を選択し「OK」ボタンを押す(設定画面)。
Netscape Messenger(Windows 95版)では、「編集」メニューから「設定...」を選択し、左側の「カテゴリ」ツリーから「メールとグループ」さらに「メッセージ」をクリック。そこで「メッセージのプロパティ」の中の「常にHTMLメッセージを送信」のチェックを外して「OK」ボタンを押せばよい(設定画面)。
enrichedテキスト形式のメールでは、フォントの種類や大きさ、色などの「スタイル」情報が指定されている。未対応のソフトで表示すると、本文中にスタイルを指定するタグがごちゃごちゃと挿入される。また、タグが入っていなくてもテキストのみが1行おきになって表示されることもある。
enrichedテキスト機能は「Eudora Pro 3.0」に搭載されている。また、互換性はないが、同様の機能は「Microsoft Internet Mail」にも搭載されている。いずれも、デフォルトでenrichedテキストで送信するようになっているので注意が必要だ。
まず、相手が他のソフトの場合は、メール作成時にスタイルの指定は行なわないようにする。こうすれば、通常のテキスト形式で送信される。ただし、他のアプリケーションからテキストをコピー&ペーストしたときになどのタグが入ることが多いようだ。もし、絶対にenrichedテキストを使わないというなら、初期設定でこの機能を切ってしまうのがいいだろう(設定画面)。
Eudora Pro 3.0(Windows版)で設定を変更するには「ツール」メニューから「オプション...」を選び設定ウインドウをオープン、「分類」から「スタイル化文章」を選択する。ここで「メッセージ送信時にスタイルを解除」にチェックを入れる。こうすれば、作成時に間違ってスタイルを指定しても、送信時にテキスト形式で送信される。
●症状4 ヘッダーが文字化けしている
最近では少なくなってきた症状だ。また、ヘッダーが読めなくても、メールを開いて見れば本文は正常に読めることも多いので、あまり気にとめない人もいるかもしれない。しかし、ヘッダーはメールの中身を表わす大切な部分だけに、放っておかないで早めに予防しよう。
■原 因 メーラーがMIMEエンコードに対応していない。またはデコードミス
■予防法 ヘッダーで日本語が使えない相手には欧文で書く
本文は日本語の文字コードにも対応したインターネットメールだが、ヘッダーでは日本語の文字コードがそのままでは使えない。そこで、ヘッダーの日本語はMIME形式でエンコードされて送信されるようになっている。したがって、MIME形式のデコードに対応していないメールソフトは、これを正常に表示することができない。また、エンコード方法の記述の仕方がちょっと違っている(大文字を小文字で記述したなど)だけで、デコードできなくなってしまうソフトもあるようだ。
最近では、ほとんどの日本語メールソフトがMIME形式に対応しているが、ヘッダーで日本語が使えないソフトを使っている人に出すときは、Subject(件名)は欧文で書くようにしたい。また、From(差出人)欄に名前やニックネームも付加されるソフトも多いので、これも欧文表記で設定しておくほうがいいだろう。
●症状5 本文の後に文字化けしたテキストが挿入されている
本文は正常に表示されるが、その後に意味不明の文字列が延々と続くというもの。ひどいときは、何百行/数十通にもわたる場合がある(症例参照)。
■症 例 BinHexでエンコードされた添付ファイルがテキストで表示された例
(This file must be converted with BinHex 4.0)
:$'PZG'9bEQ9d,QGTCJ"#58j"E@4[F`#3"!hr!*!%@AG(58Bi1@&5!&B!prm!rj!
$#*!$%*!$'*!$-C!$1C!$3T!$5T!$8T!$@T!$Bj!$Fj!$Hj!$K*!$M*!$P*!$R*!
$[C!$aVfp)4JB8M%T8N)jBcNKFe)jeS`jM'-aBdSTjk8jYCaVYB`jeU9#lle+R)4
■原 因 添付ファイルがテキストファイルとして認識された
■予防法 添付ファイルは相手のソフトが対応した形式で送る(base64が標準)
この症状は、文字化けと思われてしまうこともあるが、実は文字化けではない。添付ファイルとして送信されたものが、受信側でテキストファイルとして認識されたために起こる現象だ。症例のように、エンコード方法などを示すヘッダーが見られる。
前にも述べたように、バイナリファイルをメールに添付して送る際には、メールソフトがエンコードして送る。このエンコード方式には、現在ほぼ標準となっているbase64、主にUNIXで使用されるuuencode、Macintoshで使用されるBinHexなど、いくつかの種類がある。受信するソフトがその方式に対応していなかったり、どの方式でエンコードされたのかを示すヘッダー情報が間違っていると、正常にデコードすることができなくなる。その結果、エンコードされた添付ファイルであるにもかかわらず、そのまま本文としてテキストで表示されてしまうわけだ。
したがって、添付ファイルは相手のソフトが対応した形式で送るようにしなければならない。現在は、base64がほぼ標準となっており、多くのメールソフトが対応している。とりあえず初期設定では、エンコード方式をbase64にするのが無難だ。ただし、それぞれの方法にしか対応していないソフトもあるので、添付ファイルを送る際には、必ず相手に確認をとるようにしたい。
●おわりに
今回は、よく見かける文字化けメールを例に、その原因と予防法を紹介してきた。ただし、これらはあくまでも、多くの人が問題なく読めるようにするための最大公約数的な設定であり、相手の機種やソフトによっては、あえて別の設定にしないと読めないこともある。
また、HTMLメールやenrichedテキストに対応した最新のメールソフトで、文字化けを避けるためだけに、これらの機能を完全に切ってしまうべきというわけでもない。相手が対応するソフトを使っているのが確実な場合は、もちろん有効な手段になる。
しかし、そういったことを意識していないために起こる文字化けが多いのが現実だろう。誰もが最新のソフトを使っているとは限らないし、さまざまな環境で読まれるのがインターネットメールだ。特に最新のソフトでは、最新の機能をデフォルトで使うように設定されているため、それを知らずに使っていると、無意識のうちに文字化けメールを送ってしまうことになる。なるべく多くの人に、文字化けを起こさないで問題なく読めるようにするため、標準的な設定を知っておく必要があるのだ。
受け取って迷惑な文字化けメールは、極力自分でも出さないようにするのがマナーだ。あらためて、文字コードや送信形式などについて確認しておきたい。
最後に、未だに文字化けを見たことがないという方は、上でも紹介した「HATのホームページ」を一度見ておくことをおすすめする、文字化けしたテキストのサンプルファイルが用意されている。
■色々テキストファイル集(HATのホームページ)
http://www02.so-net.ne.jp/~hat/files/index-j.html
('98/5/25)
[Reported by nagasawa@impress.co.jp / Watchers]
【INTERNET Watchホームページ】
ウォッチ編集部INTERNET Watch担当internet-watch-info@impress.co.jp