●半角カナと機種依存文字(4回目: 半角カナの不利)
前回は、半角カナが嫌われるようになった歴史的な理由について考察してきまし
た。今回は、仕様的、歴史的な理由に加え、実利的な面から半角カナが嫌われる
原因について検証していきましょう。
まず、半角カナ文字が潜在的に持っている問題として、字形の重複があります。
文字コードというものは、本来文字そのものを表すもので、1つの文字に1つのコ
ードが割り当てられなければなりません。しかしカタカナについては、JIS X
0208で既に定義されているので、半角カナを追加するとカタカナだけ字形が重複
する、という事態に陥ります。そもそも、文字の幅はフォントによって異なるも
ので「全角」と「半角」に分けて考えること自体がナンセンスであると言えます。
ではこのことがどういった問題を産むのでしょう? まず第一には検索性の低下が
挙げられます。例えば半角カナ混在のテキストから「ウェブ」という語句を検索
する場合、JIS X 0208のカタカナとJIS X 0201カタカナのどちらか、あるいは両
方が混在しているパターンを想定しなければ、確実な検索は行えません。このこ
とはアプリケーションの性能はもちろん、開発そのものにも大きな負担をかける
ことになってしまいます。
なお、同様の問題は、JIS X 0208英数字に関しても指摘されています。いわゆる
全角英数字のことですが、これらはすでにASCII中に存在しているため、同じ字形
が混在してしまっているのです。
他にも、半角カナに「が」などの濁点文字がないため、半角カナを許すと「か」
の濁音を表現するのに「が」「か゛」の2種類の表記を許すことになってしまうな
どの問題が生じます。
Web特有の問題点としては、ゲートウェイの問題があります。最近は見なくなりま
したが、日本におけるWebの黎明期には、OSやアプリケーションによって扱える文
字コードが異なる場合があったため、ブラウザとサーバーの間に文字コード変換
ゲートウェイを噛ませるといったことがよく行われていました。
このゲートウェイで文字コードを変換する際、JIS X 0208にある文字ならどの文
字コードへも変換できますが、半角カナはShift-JISとEUC-JPの間でしか交換でき
ません。半角カナ混在のテキストは、ISO-2022-JPへの変換が不可能なのです。
他には、比較的ポピュラーな問題として、文字の自動判別の問題があります。
Shift-JISの半角カナのコードは、
[0xA6-0xDF]
となっており、EUC-JPは、1バイト目、2バイト目とも
[0xA1-0xFE]
という領域になっているため、半角カナ2文字分は、必ずEUC-JP文字列1文字分と
全く同じコードになってしまいます。このため、半角カナを多く含む文字列は
EUC-JP文字列と誤認しやすい、という問題が生じます。極端な話、半角カナのみ
からなる文字列は、EUC-JP文字列と全く見分けが付きません(文字数が偶数の場合)
。
よく、Webの入力フォームなどで「半角カナは使わないでください」となっている
のは、この文字コード誤認問題があるからなのです。
なお、半角カナを使わない場合でも、
1バイト目[0xE0-0xFC] 2バイト目[0xE0-0xFC]
の領域はShift-JISともEUC-JPとも取れ、この領域のみからなる文字列は文字コー
ドの判別が不可能です。しかし、この領域はたったの500文字前後。しかもJIS第
二水準漢字の画数の比較的多い部分なので、重複する可能性はあまりありません。
今回は、仕様的な問題から離れて、仕様上正しくてもなお生じる問題について検
証してみました。特にWebの入力フォームに関しては、入力フォーム中の文字コー
ドが何であるかを送信する仕組みの整備が遅れたため、今でも半角カナ文字列は
うまく送れないという状態が続いています。このことが半角カナの悪名を高めた
という部分は多分にあると思います。
次回は、一旦まとめをして、いわゆる機種依存文字に関しての検証にうつってい
きたいと思います。