集合と符号化

前回説明したように情報を伝達するためには、必要な文字を洗い出して一覧を作り、そ れらすべてに一つづつ文字コードを付け、そのコード体型を送り手と受け手が使うこと で正しく伝達できる。では、とにかくすべての文字にコードを付けていけば良いのであ ろうか？

ASCIIでは"A"という文字には0x41というコードが割り当てられている。同様に"B"は 0x42、"C"は0x43と続いて、"Z"は0x5Aとなる。同様に小文字の場合"a"は0x61、"b"は 0x62で"z"は0x7Aだ。ここでこのアルファベットをそれぞれ大文字から小文字に変換す ることを考えてみると、"A"の文字コードに0x20を加算すると0x61となり"a"の文字コー ドになる。同様に全角の『Ａ』はJISコードで0x2341だが、0x0020を加算することで 『ａ』の文字コード0x2361になる。日本語のひらがなの『あ』はJISコードで0x2422だ が、0x0100を加算することで『ア』の文字コードになる。これが何を意味するかという と、検索などでキーワードを指定するとき、大文字と小文字や全角と半角を区別せずに 検索させるとき、単純な加減算の後に比較するだけですむため簡単で高速に処理が出来 る。

索引や用語集、辞書のような物を作ることを考えてみると、英語の場合大文字か小文字 のどちらかに統一しておけば単純に文字コードで並べ替えると辞書順に並ぶ。ところが 日本語の場合はそうはいかない。これは『雨』がアメやウと読むように複数の読み方が あるため文字コードを辞書順並べることがそもそも不可能なことや、足りない文字を後 から追加したときに離れた区画のコードが割り当てられているため、文字コード順には 意味がないためだ。このため日本語の場合は『ふりがな』が必要となる。それも注意が 必要で、カタカナだと『ヴ』や『ヵ』のようなカタカナ特有の文字が『ウ』の次ではな く末尾の『ン』の次のコードになっているため、意図しない結果になる場合もある。ま た、五十音順でなく、いろは順に並び替えようとすると専用のプログラムを作成するか、 手作業が必要になってしまう。

余談だが、もし筆者がいろは順の辞書のような物作ることになったとすると、手作業な んかはとんでもないので、おそらく関数インデックスが使えるデータベースを使うだろ う。もし、良くありがちな並び替え順のような番号を振って対処した場合、後から仕様 を変更することは並び替え順の再採番が必要となり大変な手間が予想されるが、関数イ ンデックスのような機能を使えば濁音を無視し『ふ』と『ぶ』を同一視するかどうかと か、『ウ』と『ヴ』のような問題も、間違えてカタカナとひらがなを混在させてしまっ たりとか、様々な問題に対し、ふりがなを振り直したりすること無く、関数定義を変え るだけで済む。

ここまで文字コードと表記してきたが、文字コードは『文字集合』と『符号化方式』の 二つで定義される。文字集合としてのJIS X 208では、0x2422と言っていた『あ』は4区 2点という区点コードで表せる。これを特定の文字コードへマッピングした物が符号化 形式で、JISコード、シフトJISコード、EUC(Extended Unix Code)コードなどがある。 『あ』はJISでは0x2422、シフトJISでは82A0、EUCでは0xA4A2となる。JISとシフトJIS の関係は半角カナが使えるように2バイト文字の１バイト目が半角カナと重ならないよ うに「シフト」されている。またJISとEUCの関係は見ての通りJISコードのそれぞれの バイトに0xA0を足せばEUCコードとなる。半角カナの領域を避けていないためEUCでは JIS X 201で定義されている半角カナは利用できない。

JISコードという標準規格がありながら、同じ文字集合のシフトJISやEUCなどの符号化 方式が生まれたのは、JISコードは文字を表現する2バイトの1バイト目も2バイト目も ASCIIコードと重なってしまうため、「これから漢字が始まる」「これで漢字が終了す る」という文字集合の切替符号であるエスケープシーケンスが必要なため、文字列のあ る1バイトに注目した場合、それが漢字かASCIIか判別がつかない。また1バイト文字と2 バイト文字が混ざり合うとエスケープシーケンスの分データ量が増えてしまう。これを 回避するためMicrosoftが当時のパソコンでも十分高速に処理できるようにJISコードで 定義されていない領域にずらす(=シフト)方法を考え出し実装した。EUCも同様にAT&Tで 定められた。JIS X 213の第3,4水準文字を表すためには１バイトのシングルシフト文字 で文字集合を切り替える必要がある。切り替えは直後の1文字のみ有効のため第3水準の 文字はEUCでは3バイトで表されることになる。

なおインターネット・エクスプローラでは「表示」メニューの「エンコード」で現在の ページの文字コードがわかる。もし文字化けしている場合は、このメニューで正しいと 思われるコードを選択すれば大抵の文字化けは解消されるだろう。インターネットのホ ームページの場合、本来WebサーバがMIMEヘッダの中でcharsetパラメータにより文字コ ードを指定するべきで、それが出来ない場合にHTMLファイルでMETAタグによるContent- typeを指定しても良い事になっている。文字化けするページはこれらのどちらの指定も ないか、指定コードと実際の文字コードが合っていないため発生する。 インターネット・メールの場合、通常日本語はISO-2022-JPでやりとりすることなって いる。ISO-2022-JPを期待しているメーラが別のコードで受信すれば文字化けする事に なる。

さて、文字で表現された情報を伝達するために、文字集合を定義し符号化するというこ とを見てきたが、文字だけでなくデータをやりとりするためには同様な手法が必要だ。 たとえば商品コードのような物。商品コードが自社独自の物であれば他社とのデータ交 換が出来ないため統一コードのような物が必要だ。このようなコード付けをする場合、 コードは符号にすぎないのかコードそのものにも意味を持たせるのか、どのように分類 するのかなど、とにかく初めによく考えて分類しておかなければ、あとから様々な問題 が発生する可能性があるということに注意してほしい。