UTF8とSHIFT-JISコードの特徴

UTF8<->16の変換関数を書いたので、UTF<->SHIFT-JISの変換関数も公開したいところだが、それは出来ない。

なぜかというと、出し惜しみじゃなくて、文字コードにおいて、UTFとSHIFT-JISの間に算術的相関関係がないからである。

(一部のコード範囲を除き)基本的には、１：１で変換テーブルを作るしかないのだ。

だから、変換処理を公開すると言うことはそのテーブルを公開することに等しく、
SHIFT-JISの文字数を考えたら、それは現実的ではない。高速化を考慮するなら、
交互の変換にはそれぞれ別テーブルが必要となるのでなおさらである。

実際に、全ての対応表を載せているHPがあったりするが、その表示はかなり重い。


・・・

さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-ｔurboからX68000、さらには
多くの組み込み機器にも処理を実装してきた。日本でもトップクラスの理解者である、と自負してたりする(^_^;)。
なもんで、両方のコードを理解した今となっては、怖いもん無しである(^_^;;)

いや、それは冗談として、 UTF-8の特徴を少し説明。

UTF-8は、JISコードに対するSHIFT-JISのような物で、UTF16に対して算術演算をかけることでコード範囲を限定している。

双方の特徴をまとめると以下のようになる。


SHIFT-JIS
・前から読まないと正しいコードが得られない
・しかしそれさえ守れば、ASCIIコードと混在可能
・ASCII用に書かれた処理の多くは、簡単な2バイトコード判定の追加するだけで流用可能
・基本的に見た目のバイト数と文字コードのバイト数が一致する
X68000の1/2角・1/4角文字など、例外も存在した（まあその範囲はそもそもJIS規定外だが)。
・第2水準漢字までが2バイトで収まる(第3水準以降は知らない)
・JISコード（＝連続コード)と算術演算による交互変換が可能なため、漢字フォントの位置を求めるのが楽。
JISコード並びの文字フォントはフリーで多数出回っているため、　無償で漢字を表示できるシステムを構築できる(読みやすさは別にして)。
・JISコード第1水準漢字は音読みで並べられているため、音読み漢字変換なら比較的簡単に実装できる



UTF8
・前からだけでなく後ろからでも正しい文字コードを得られる
・そのままASCIIコードとの混在が可能
・しかもASCII用に書かれた処理の多くがそのまま使える
・見た目のバイト数と文字コードのバイト数が一致しない
・第2水準漢字まででも3バイト以上になることがある(というか2バイトで収まる範囲は少ない)


どちらがいいというのではなく、目的さえ間違えなければ、どちらもよく考えられたコードだと言える。が、SHIFT-JISは組み込み機器で使うに有益な特徴を持ったコードで、UTF8はOS上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。

UTF８については次回もう少し解説。