現在、多くの文字処理系では、文字そのものを扱う代わりに、文字に固有の番 号を振って、その番号で文字を表す手法を用いている。ここで、文字と番号の 対応規則を「符号化文字集合」(Coded Character Set; CCS) もしくは「文字 符号」(character code) と呼び、文字に振られた番号を「符号位置」(code point) と呼ぶ。また、このように、有限の文字の集合を定め、各文字に固有 の番号を振りその番号で文字を表現する手法のことを、ここでは『符号化文字 モデル』と呼ぶことにする。
図 2.1.1に示すように、符号化文字モデルでは文字は 文字に振られた番号で表現される。文字に関する知識は符号化文字集合の定義 の中に存在し、通常、計算機の中には存在しない。このため、計算機は少ない 記憶量で文字を表現できる半面、計算機が扱うことができる文字の種類や文字 の概念は符号化文字集合の定義に束縛される。
符号化文字モデルに基づいて通信を行なう場合、送信者と受信者は文字と番号 の対応規則である文字符号を共有している必要がある。さもなくば文字化けが 生じる。ある文字符合で表現できない文字が存在した場合、両者が合意して通 信手順で用いる文字符合を拡張しなければならない。しかし、インターネット のような不特定多数が参加しさまざまな種類の機材が存在するような大規模開 放システムで用いられる標準的な文字符合を拡張することは極めて困難である といえる。
このため、現実的な方策として、従来、交換可能性をあきらめて外字を用いる
方法や、検索などの符号化文字としての利便性をあきらめて画像を用いる方法
が採られてきた。また、国際的な標準符合として ISO/IEC 10646
(UCS)/Unicode を de jure/de fact standard として制定し、これを全世界で
共有し、また、これを拡張することによりこの問題を解決しようとする努力が
続けられているが、これにも技術的・政治的問題があり容易ではない。
![[*]](/usr/share/latex2html/icons/footnote.png){kind=icon}
前述のように、符号化文字モデルでは、「世の中に存在するさまざまな文字」 と「符号化され符号位置という番号を振られた文字」の間の関係は、符号化文 字集合によって定義されている。この考え方では、文字の持ついろいろな性質 は個々の文字ではなく符号化文字集合が持つことを前提としている。また、さ らに、それぞれの符号化文字集合が似た性質の文字の集合であり、特定の用字 系 (script) や言語で用いる文字の集合であると仮定できるならば、符号化 文字集合の種類を特定することにより、用字系や言語を特定できるといえる。
この仮定がなりたっていれば、個々の符号化文字集合は用字系や言語を近似す るものとして用いることができ、少ない記憶容量で大量の文字を扱うことがで きる。UCS/Unicode のような多数の言語を対象に多数の用字系を収録した符号 化文字集合が利用されるようになるまでは、単一の言語や用字系を想定して作 られていた符号化文字集合が多く、この前提はほぼ満たされていた。
このような仮定を前提に符号化文字集合を追加可能にしたシステムとして
Mule [3] が存在する。
しかし、多くの符号化文字集合は通常の文字だけでなく、句読点のような記号 を含んでおり、また、JIS X 0208 のように複数の用字系を含むような符号化 文字集合や ISO 8859-1 のように複数の言語で利用される符号化文字集合も多 く存在したので、当初からこれはあくまで近似に過ぎなかった。 逆に、同一の文字でも、符号化文字集合が異なれば違う文字として扱われてし まう。例えば、ISO 8859-1 の「á」と ISO 8859-2 の「á」や JIS X 0208:1978 の「あ」と JIS X 0208:1983 の「あ」は別の文字とされる。これ では、検索や文字の性質を定義する上で問題がおこる。西欧と東欧のように、 伝統的には異なる符号化文字集合を使ってきており、近年交流が盛んになりつ つあるような環境では、特に不便である。
文字の重なりがほとんどないことを前提としている従来の Mule 型の文字表現 方法は、記憶資源が高価であった時代には一種の近似解として効果的であった。 しかし記憶資源が比較的豊富になりつつある現在、その利点よりも弊害が多く なってきた。より高度な文字処理やより柔軟な拡張可能性を実現するためにも、 また、現在利用されているさまざまな符号化文字集合をより適切に利用するた めにも、著者らは従来の Mule の方式に代わる新たな文字表現の仕組みを実現 することをめざしている。
符号化文字モデルに基づかずに文字を表現すること、すなわち、固有の番号で 同定することなしに文字を指し示そうとするとしたら、どうすれば良いだろう か？ おそらくその一つの方法は指し示したい文字の性質を列挙することだろ う。例えば、「あ」を指し示すとするならば
漢字の場合には、発
音だけでは不十分である。例えば、「字」を指し示したい時にこのように文字を属性の集合で表現することによって、符号化文字方式に依ら ずに文字（ないしは文字の集合）を表現することが可能である。また、指定す る属性を多くしたり少なくしたりすることによって、表現する文字の包摂規準 を細かくしたり粗くしたりすることができる。
このような属性に基づく文字表現においては、文字の性質に関する情報は文字 属性として文字表現自体に含まれている。よって、特定の処理に必要な情報は 文字属性として文字表現に含めておかなければならない。例えば、表示を行なう には文字の字形を示す情報が必要である。逆に、表示という処理を行なわない ことを前提とした文字表現には、字形という属性は不要となる。
このように各文字をその文字が持つ属性の集合によって表現し、こうした文字 の属性の集合をデータベース化し、それを参照しながら文字を処理する方式を ここでは『UTF-2000 方式』と呼ぶことにする。UTF-2000 方式は文字に関 する知識を直接プログラムするのではなく、データベース化してそれを参照す る方法であるので、計算機が扱うことができる文字の種類や文字の概念は符号 化文字集合の定義に束縛されない。使用する文字データベースを取り換えるこ とによって、容易に文字の種類や概念を変更可能である。このような高度な柔 軟性を持つ半面、多数の文字を扱う場合、多量の記憶量が必要となると考えら れる。このため、文字データベースを柔軟性を損なうことなく効率的に扱うた めの機構が必要となる。
ところで、UTF-2000 方式自体は既存の符号化文字技術と対立するものではな い。符号化文字集合の種類と符号位置は文字属性の一つと捉えることは可能で あり、利用したい符号化文字集合を文字属性に含めることにより、それらの符 号化文字集合の世界と情報交換を行なうことは可能である。
![\scalebox{0.5}{\includegraphics*[0mm,15mm][300mm,155mm]{char-code.eps}}](img1.png)