■日本語の表現(2)■

多バイト方式

さて、前文書で２バイト系の日本語コードについて見て来たのだが、結局、アルファベットの大文字・小文字・１バイト系カタカナ・日本語を全て丸くおさめて、統一的に扱うことのできる体系はシフトＪＩＳのみであった。

つまり、２バイト(16bit)系のシステムにおいては、シフトＪＩＳが最も優秀なコードということになる。しかし、実は以前から一部のワープロ専用機などでは、３バイトの日本語コードが使用されていた。これは先頭１バイトで文字の種別を指定し、残りの２バイトに実際のコードを入れる。

この方法を使うと、シフトＪＩＳでサポートしている字種に加えて、１バイト系ひらがななども問題なく使用できる。実は似たようなことをしているのが、新ＥＵＣである。

新ＥＵＣ

EUC(Extended Unix Code) は UNIXの世界で日本語を扱うために1985年に定められたコード表現体系である。この EUC の規格の策定にあたっては色々な所の思惑が交錯して、難航し、そのこと自体がこのコードの普及を疎外した。

結果的にはこのコードはUNIXの世界のローカルコードという形になってしまい、純粋なUNIX以外では、UNIXの直系OSともいうべきLinuxくらいでしか使われていない。

当初からEUCには、１バイト系カタカナが扱えないという困った問題があった。これに対して、それを扱わざるを得ないミニコン／ワークステーションメーカーでは、独自の拡張をして、１バイト系カタカナを使用した。

新ＥＵＣは1991年に草案がまとめられた。

これは主として1990年に登場したJIS補助漢字(JIS-X0212)を処理するために定められた規格である。

結果的にこの新しい規格では、JIS補助漢字はシフトコードを使って３バイトで表現することにした。そして、ついでに１バイトカタカナも組み込むことにし、これもシフトコードを使うことにした。結果的に新ＥＵＣは次のような構成になる。

　　ＡＮＫ　　　　そのまま　　　　長さ１バイト
　　JIS基本漢字　 MSBを反転させて　長さ２バイト
　　半角カタカナ　0x8E+該当コード　長さ２バイト
　　JIS補助漢字　 0x8F+MSB反転　　長さ３バイト

EUC自体は日本語だけを扱うコードではなく、多国語に対応したものなので、EUCのこの新しい規格自体には長さ４バイトの文字まで使用できるようになっている。しかし現在の日本語EUCでは３バイトまでしか取り扱わない。

この改訂の結果ＥＵＣはますますいびつなものになってしまった。しかし1999年秋の時点で、JIS補助漢字を処理できているメジャーなコード体系は、EUCのみなのである。（ただし、まだこの新ＥＵＣで動いてるシステムは少なく、いまだにUNIXを基盤にしている人たちが「半角カタカナをインターネットで使うな」などと主張している）

新ｕｎｉｃｏｄｅ

最初のｕｎｉｃｏｄｅは、多言語環境において、１バイトの文字と２バイトの文字が混在しており、更にその２バイトの文字が国によって異なった文字を表していた現状を憂い、英語の文字を含めた全ての文字を２バイトで統一的に扱い、全世界の文字を統一されたコードで表現しようとするプロジェクトであった。

しかしｕｎｉｃｏｄｅが定められた時のマシンの事情はこの統一コードを２バイト(16bit)で処理させざるを得なかったが、実際には世界中の文字をコード化しようとすると、とても２バイトでは足りないのである。

実際問題として、２バイトでは全部のコードを使ったとしても 65536文字までしか定義できないが、漢字は康煕字典に載っているものが47000文字。これに日本語の新字体や中国の簡体字、更には色々な俗字や、仏教などの特殊な分野のみで使用する文字を加えていくと、どう考えても数十万文字ある。こんなものを含めてコード化するためには、やはり４バイト欲しかった。

しかしそういう事情に熟知したメンバーがｕｎｉｃｏｄｅを定めるメンバーにいなかったか、或いはいて主張しても通らなかったのであろうか。また当時のマシン事情においては、１文字を統一的に４バイトで扱うのはメモリーなどの資源上困難であった。

そういうわけで、ｕｎｉｃｏｄｅもver.2以降は「全ての文字を同じ桁数で表す」という理想が崩れてしまったのである。

現在、ｕｎｉｃｏｄｅ2.0では、文字を次のように捉える。

　●縦２５６個（区,row）、横２５６個（点,cell）の「面(plane)」というものを考える。１つの面に最大65536文字が定義できる。
　●この面を２５６個集めたものを群(group)と呼ぶ。
　●ｕｎｉｃｏｄｅでは１２８個の群を使用する。（つまりunicodeは31ビット）

そして、基本的に文字は群番号・面番号・区番号・点番号という４バイトで表現されることになる。ただし、０群・０面だけは特別視して BMP (Basic Multi-lingal Plane) と呼び、先頭の 0.0. を省略して２バイトで書いてもよいとする。

つまり、新しいｕｎｉｃｏｄｅは２バイト又は４バイトのコード体系なのである。

さて、ここで問題。

このようにして、２バイトコードと４バイトコードが混在してしまった場合、またまた最初にＡＮＫと日本語コードの問題のところで言ったように、両者の区別がつかなくなってしまうという問題が起きる。

そこでｕｎｉｃｏｄｅ2.0ではこの問題を次のように解決している。

・当面ｕｎｉｃｏｄｅの中で使って良いのは、群0.面0～16(0x10) の17面のみとする。
・この内、面0のデータ(BMP)はそのまま２バイトで処理する。
・この時BMPの一部を空けておく。実際には 0xd800～0xdbff, 0xdc00～0xdfff の1024+1024文字を確保する。
・1～16面の16x65536=1048576文字を上記確保したエリア2文字の1024x1024=1048576文字に埋め込む。

要するに、シフトＪＩＳと似たようなことを、４バイト→２バイトの埋め込みに使用する訳である。これによって、２バイトのｕｎｉｃｏｄｅと４バイトのｕｎｉｃｏｄｅが混在しても構わないようになる。

このシフト方法をＵＴＦ－１６と呼び、BMP上に確保した領域をサロゲート・ペアと呼んでいる。

なお、現在のBMPの確保状況は次のようになっている。

区番号	幅	00～FF
00	256	Latin-1互換(ASCII互換)	Alphabet
01～33	13056	その他各種アルファベット・かな・ハングル部品など
34～4D	6656	（完成型ハングルが定義されていたが移動して空）
4E～9F	20992	漢字(CJK統合.約21000文字)	Ideograph
A0～AB	3072	reserved	Open
AC～D7	11264	完成型ハングル
D8～DB	1024	上位サロゲート
DC～DF	1024	下位サロゲート
E0～F8	6400	私用予約領域	Restricted
F9～FF	1790	互換用文字(半角カタカナ,全角英数字など)	Restricted

(2001.5.1)