バグ:文字化け文字列の対応

Posted: 2013年01月14日

文字化け文字列の対応を紹介します。
以前も多少記載したけれどおさらいという事で
今回はどのようなことを気をつけるべきかを記載していきたいと思っています。

エスケープシーケンス

Shift-JISなどでは、「」(0x5C)で誤って処理されることがあります。
プログラム中に

char szPath = _T(“C:Windows”);

の場合もWと解釈される

char szPath = _T(“C:\Windows”);

を\にする必要があります。
0x5C問題は、もちろんインターネットの世界にも存在し
Shift-JISのページに0x5Cの文字(申,能,表)が存在すると表示がおかしくなることがありました。

今時 Shift-JIS用プログラムを作成する方がおかしいのかもしれません
※C#,Javaなどは、Unicodeが標準で動作する。

0x5Cの文字については、wikipediaを参照したほうが分かりやすいです。
http://ja.wikipedia.org/wiki/Shift_JIS

機種依存文字

携帯のメールがいい例です。
絵文字など各キャリア(docomo等)で割り当てられているため表示できない、関係ない絵が出るなどがありました。
通常は、そこまで機種依存文字に悩まされることはありませんし
今後は、Unicode+画像を送るなどになるため携帯もそこまで悩まされることはないと思います。
機種依存文字には、WindowsやMacなどのOSやソフトウェアにも存在すると思います。
ソフトウェアの場合は、対応仕様がありませんが
OSについては、サポート範囲を見極めるまたは、通信でやり取りが行われる可能性がある等を考えたほうがいい場合があります。

Unicode(UTF-16)

今まで万能と言って来ましたし他のサイトでも基本的に万能と言った感じで入っていますが
ソフトウェアが注意しないといけない場合もあります。
例えばサロゲートペアに関して
サロゲートペアについて
1文字(2byte)+1文字(2byte)=1文字(4byte)
で表現できる文字列を拡張する機能です。

Javaでは、サロゲートペアについてはサポートされていなく
いつの間にかサポートされるようになりましたが
現在は、stringのlengthを用いても文字数ではなくバイト数/2が取得できます。
stringのcodePointCountを使用する必要があるようです(Java 5)

Unicodeも成長しているためJavaの対応が遅れていると言ったほうがいいのか
文字コードが成長されても・・・と思ってしまいますが

カテゴリー: バグ, プログラム | タグ: , , | コメント無し »

コメント