ブラブラしていたら見つけた記事：“情報化時代”に追いつけるか？　審議が進む「新常用漢字表（仮）」

こんな事書くと、また安岡氏に降臨されるのではないかと冷や冷やしながら、おもしろがって書いてみる。

依然として、「全角 半角 判別」による検索からの参照が、高い割合を占めています。いい加減、そういう考え方やめようよ...とぼやいても、仕方がない。んな考え方、すでに実情にあっていないんだぞ～！と書き続けることで、考え方が変わってくれることを祈ります。

「全角 半角」以上に困るのが・・・いや、その問題の本質は、文字コード体系間での文字コードの変換ではないでしょうか。「全角 半角」の判別で困るのは、Windows 2000 から Unicode が使えるようになって・・・じゃなくて、VC6 あたりから Unicode が使えるようになって、VC7 から Unicode が既定の文字コードになっているから、ではないでしょうか。-DUNICODE -D_UNICODE が、コンパイラのオプションに既定で追加されており、VC6 の -D_MBCS とは異なっています。VC7 を先にさわった私は、驚きました。。。

掲示板などに出されている質問を見ていると、どうも、（特に C/C++ で）文字と文字列が区別できていなかったり、コンピュータ内部では文字であっても数値であるということがわからないのか、はたまた数字と数値を同じように考えているのではないか？と思われる質問を散見します。数字と数値の混同は、特に VB 使いに多く、これは「暗黙の型変換」による弊害なんだろうなぁ、と思います。

はてさて。「全角 半角 判断」がしたい人は、なぜ、判断をしなければならないのか、理解しているでしょうか？

比較的新しい言語では、文字列を「数える」と、文字数が返ってきます。しかし状況によっては、特にデータベースが絡んでくると、文字数ではなく「バイト数」が欲しくなります。

Oracle では、9i の頃だったと思いますが、VARCHAR2 に対して文字数で幅を指定できるようになりました。この辺に罠が潜んでいます。

データベースの文字セットを Unicode にして、VARCHAR2 の列を「200文字」と設定したとします。すると、内部的には「VARCHAR2で400バイト」に変換されます（9i 当時。10g 以降は知らない）。

これは、おおよそ正しいのですが、Unicode には“サロゲートペア”というやっかいなものが潜んでいます。これが、Unicode における“全角文字”の様な存在で、4バイトで1文字となります。そうすると、もし、サロゲートペアの文字だけでこの列を埋めると、200文字と指定したのに、100文字しか保持できないということになります。

従って、Unicode で判別するべきは、一般に考えられている「全角 半角」ではなく、サロゲートペアか、そうでないか、ということではないでしょうか。もっとも、これだけでは不十分で、合成文字というものありますから、これを使うと1文字が何バイトあるのか、予想できないのですが...

もちろん、Shift_JIS で保存するから「全角 半角」が知りたい、ってこともあるでしょう。ここで、システム全体を通して Shift_JIS しか扱わないなら、それもありです。そうではなく、他のコード体系も扱うなら、果たして Shift_JIS だけに絞った判別が必要なのかどうか、疑問です。

コンピュータの文字をややこしいものにしているのが、コード体系が複数あって、それぞれの体系に完全な互換性がない、ということです。こっちの体系には定義されているが、あっちの体系には定義されていない。すると、こっち→あっち→こっちと、体系を移したとき、最後の「こっち」には違う文字が表示されることになります（これを利用したセキュリティ インシデントもあります）。

そして、タイトルからどんどん離れていくワナ...orz

今でさえ面倒なのに、これ以上面倒なことをさせるか。いっそ、日本語使うのやめるとか（ぉぃ