特殊文字を送りたい(丸数字、はしご高など)

2008/07/21 文字コード spok

特殊文字、拡張文字と文字コードセット

はしご高(髙)や機種依存文字の①などの丸数値を送りたい時があるでしょう。
まずは、特殊文字と対応文字オードを示します。

参考:
文字コードの基本-IT Pro
文字コード規格の基礎-IT Pro
使ってはいけない文字(β版)
PHPで「髙(はしごたか)」「﨑(たつさき)」が文字化ける(2)-yossy.blog
文字コードの話
以下はあくまでもPHPの文字コードセット指定の場合です。
7bit8bit
iso-2022-jputf-8shift_JISsjis-wineuc-jpeucJP-win
IBM拡張文字(髙﨑黑神福など)××××
NEC拡張文字(①②㈱㌍ⅠⅡ伹侚など)×××
半角カナ×
ただし、上記で○だからといって文字化けしない訳ではなく、例えば、OutlookExpressは、eucJP-winのメールは正しく表示できないようです。gmail,秀丸メールはOKでした。このようにインターネットの中は正しく通っても、最後のメーラーで文字化けすることもあるようです。
また、-winとついている文字コードセットは、基本的にwindows用なので、Macでは文字化けすると思います(ただし、私はMacを持っていないのでテストしていません。Macにも-winの文字フォントが入っていればたぶん表示できるでしょう)。

特殊文字をメールで送信する時の文字コードセットと本文エンコード

文字コードセット :UTF-8
本文エンコード指定:Base64
具体的な手続としては、QdmailでのUTF-8,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サービスではそうも言ってられない場合もあるでしょうね。。。。
でも、現状ではやっぱり、特殊文字を送らない方策を探るのが、もっともトラブルが少ないような気がします。

*1 : RFC1428等も

*2 : CakePHP1.2RC2はこれなんだよな~

*3 : 別に8bitでなくても、文字コードセットでなくてもいいのだけれど