特殊文字を送りたい（丸数字、はしご高など）
2008/07/21
特殊文字、拡張文字と文字コードセット
はしご高（髙）や機種依存文字の①などの丸数値を送りたい時があるでしょう。まずは、特殊文字と対応文字オードを示します。
参考:
文字コードの基本-IT Pro以下はあくまでもPHPの文字コードセット指定の場合です。
文字コード規格の基礎-IT Pro
使ってはいけない文字(β版)
PHPで「髙（はしごたか）」「﨑（たつさき）」が文字化ける（２）-yossy.blog
文字コードの話
| 7bit | 8bit | |||||
| iso-2022-jp | utf-8 | shift_JIS | sjis-win | euc-jp | eucJP-win | |
| IBM拡張文字（髙﨑黑神福など） | × | ○ | × | ○ | × | × |
| NEC拡張文字（①②㈱㌍ⅠⅡ伹侚など） | × | ○ | × | ○ | × | ○ |
| 半角カナ | × | ○ | ○ | ○ | ○ | ○ |
また、-winとついている文字コードセットは、基本的にwindows用なので、Macでは文字化けすると思います（ただし、私はMacを持っていないのでテストしていません。Macにも-winの文字フォントが入っていればたぶん表示できるでしょう）。
特殊文字をメールで送信する時の文字コードセットと本文エンコード
文字コードセット ：UTF-8具体的な手続としては、QdmailでのUTF-8,BASE64の指定方法をご参照下さい。
本文エンコード指定：Base64
ただし、au携帯の一部では、UTF-8のヘッダーをデコードできない場合があります。
その時は、ヘッダーはiso-2022-jp(特殊文字は使えないけど）、本文はUTF-8(特殊文字が使える)というのはいかがでしょう。
このヘッダーと本文の文字セットを変える方法は、「ヘッダ、本文に別々のCharsetを指定する 」をご参照ください。
どうして本文エンコードは、base64なのか？
そして、UTF-8 + 8bit という指定もあり得るのですが、現状では、 8bit を受け付けないSMTPサーバーもある以上、文字化けのリスクは残ります。貴方の環境でうまくいっても、他の人に送信した場合に文字化けするかも知れません。一方で、base64エンコードであれば、SMTPサーバーはもちろん大丈夫、クライアントであるメーラーも、対応していないメーラーは珍しい部類かと思います。
単純に言いましょう
| 組み合わせ | 規格（RFC1652-MIME）*1的に | SMTPサーバー対応 | メーラー |
| 文字コードセット ：UTF-8 本文エンコード指定：7bit | 間違っている*2 | - | - |
| 文字コードセット ：UTF-8 本文エンコード指定：8bit | 正しい | 対応していないサーバーもある | auの古い携帯では未対応らしい |
| 文字コードセット ：UTF-8 本文エンコード指定：Base64 | 正しい | すべて大丈夫 | auの古い携帯では未対応らしい |
特殊文字を送るのは UTF-8 + Base64 が最もお薦めです。
インターネットメールの世界はまだまだ7bit
7bitである、iso-2022-jp,utf-7などは、本文エンコードを7bitにして送信することができますが、本文エンコード8bitで送らなければならない8bit文字コードセットは、まだまだ対応していないSMTPサーバーがあるようで、そのまま送信するのは、お薦めできません。8bit文字コードセットを送信する場合には、本文をbase64エンコードして送るのがよいでしょう。
Base64エンコードとは、8bitの文字コードセット*3を、6bitにするエンコード方式なので、インターネット経路上は絶対に安全なのです。
インターネット経路上は安全であっても、受け取った人のメーラーがBase64に未対応の場合には、文字化けしますが、古いau端末以外はまず大丈夫だと思います。
それにしても、auは、デコメも特殊だし、utf-8対応は不完全だし、どうにもわがまま？なキャリアですね。
UTF-8 か Shift-JISか
私としては、国内ローカルのShift-JISよりも、全世界共通のUTF-8がいいと思います。海外在住の日本人の人が、Shift-JIS対応の端末を入手できるかどうかわからないからです。一方で、国内の携帯端末のほんの一部は、UTF-8に対応していないのもあるようなので、難しいところです。
特殊文字は使わないのが一番
確かに、特殊文字を使わないのが一番いいです。しかし、WEBサービスではそうも言ってられない場合もあるでしょうね。。。。でも、現状ではやっぱり、特殊文字を送らない方策を探るのが、もっともトラブルが少ないような気がします。