いろいろなところで陰に陽に使われるようになってきました。NTの内部コードがUnicodeであるのはよく知られています。BeOSでは、内部だけでなく全面的にUnicodeが使われています。Javaのchar型もUnicodeです。入出力においては、当分は従来の文字コードと共存することになります。意識するしないに関わらず、Unicodeと従来コードの変換が頻繁に行われます。特定の文字だけが正しく表示されないなどの現象を生むことになります。いくつか具体例を挙げて考察します。問題を引き起こさないような実装に役立ててください。Unicodeなどについて基本的な知識があることを前提としています。手元にあるとなおよいでしょう。実際には、それは漢字だけの話といっても過言ではありません。役割や用途が違うものは積極的に別の文字として扱おうとしています。これに拍車をかけています。ギリシア文字のμと百万分の一を意味するμも別の文字になっています。(ちなみに「空白」はもっとあります)。こんなに細かく区別をして、はたしてどうやって入力するのでしょうか。入力できたとしても、入力する人がちゃんと適切な記号を使い分けられるのでしょうか。そのうち、スペルチェッカーやスタイルチェッカーが教えてくれるようになるかもしれません。人によって解釈が違ってくる可能性があることは否定できません。それは(漢字を除いて)あくまで参考にすぎませんし、改訂されることもあります。さまざまなしがらみや思惑によって微妙な違いが生じることは十分考えられます。特定の文字が表示されなかったりという事態が起こりえます。0208の中で、実際に問題になりそうなものを拾うと、以下のようなものがあります。妥当なようにも思えます。印刷されているグリフが上下逆になっているのが気になります。LINEでしょうかね、やっぱり。CIRCLEとされています。0208-1983/1990/1997)の違いは厄介な問題ですが、ここでもまた顔を出します。新JISとの対応づけは(少なくとも漢字については)明確に規定されています。旧JISとの対応づけを考えると、やはり問題があります。旧JIS漢字の一部は、新JISで字体変更や字体交換が行われました。それとも新旧JISを区別せずに新JISと同じ対応づけをするか、という問題があります。旧JISの字体がUnicodeに収録されていない場合、以下のような選択肢があります。新JISのコードで対応づけする。以下のような選択肢があります。字体を重視してそちらに対応づけする。フォントがなくて表示されないといった問題が発生しえます。新JISのコードで対応づけする。この場合、当然ながら、違う字体(新JISの字体)で表示されることになります。迷いの種が増えるだけであるということはいうまでもありません。各メーカーがそれぞれに日本語文字コードを策定していました。各メーカーはJISに独自の文字を追加した製品を提供しています。ベンダー独自文字」などと呼ばれるものです。ここでは、「ベンダー固有文字」と呼ぶことにします。6226に追加する形のベンダー固有文字集合としては、次の二つが有力です。6226でカバーされない文字を選んだもの。6226に対応しない領域(FA40〜)に収容されている。NEC拡張文字(NEC特殊文字・NEC選定IBM拡張文字)NECが、IBM拡張文字に加えて、さらに記号類や半角文字を追加したもの。俗に言う「98文字」。6226の空き領域に収容されている。(ただし、NEC拡張文字の罫線や半角文字は除く)。IBM拡張文字は、NEC拡張文字と重複していることになります。0212とも一部重複しています。これらとUnicodeとの対応を考えると、以下のような問題点があります。新JISをもとにしているUnicodeとの整合性が悪い。0212などの間で一部の文字が重複している。25区23点)があります。」という字体(U+6602)があります。」がIBM拡張文字(FAD0)に収録されました。」がないという奇妙な事態になりました。いずれにしても混乱すること間違いなしです。Ideographsに収容されています。2バイトコードである後者を「全角」とする実装が広く存在しています。「半角カタカナ」と「全角英数字」を収容しました。どれに対応するのかが不明な文字がいくつかあります。「全角」を別途用意する必要はないはずです。何に使うのでしょうか。最初の3つは、おそらくコードページ942/943との変換に使うためのものと思われます。IBMがこれを拡張したコードページ942/943というものがあります。これは、以下のように、シフトJISで使わないコードに1バイト文字を割り当てたものです。0208の方と対応するFULLWIDTH文字が必要となります。Formsがあるから「半角」「全角」の区別が容易に保たれる、と考えるのは早計です。それが「全角」であるという属性は失われることに注意が必要です。例として、ktermのような等幅フォントの端末エミュレータをJavaで作ったとしましょう(別にJavaでなくてもいいですが)。これを表示するのに全角フォントを使うことは可能です。仮名や漢字は当然全角フォントになるでしょう。8859などと一緒の(おそらくは半角の)フォントで表示されることになるでしょう。8859などからきた文字も全角で表示されてしまいます。いずれにしても、素のUnicodeだけではどうにもならない問題です。property)を定義することにしました。ここで参考として挙げられている分類はいささか疑問なものもあります。0201ローマ文字があります。両者の違いは05/12と07/14の2か所だけです。2か所の違いが、他の文字の対応づけに少なからぬ影響を与えます。0212)を併用した場合について考えてみます。SOLIDUSとTILDEに対応します。TILDEに対応することになります。PunctuationのOVERLINEに対応づけられます。(注意すべきところは強調表示にしてあります)。0212)を併用した場合について考えてみます。PunctuationのOVERLINEに対応づけられます。OVERLINEというのはありません。やむをえずこれに対応づけることになるでしょう。SOLIDUSとTILDEに対応します。これを上の表に書き加えると、下のようになります。0212の関連する文字の対応づけが大きく変わってしまうことがわかると思います。ここまで厳密に対応づけを調整しても、実際はあまりメリットはありません。2バイト文字がFULLWIDTHになったりならなかったりするなど)。どちらの場合にも適用可能な単一の対応づけによって運用することになるでしょう。そのような対応づけの一例を下表に示します。FULLWIDTHを多用することになるという問題が残ります。0208の円記号を使うことにしています。SIGNにマップされてしまいます。SIGNはまったく使われないのです。変換されるとまったくおかしなものになってしまいます。円記号については、他にも問題となるケースが考えられます。ASCIIのバックスラッシュの代わりに05/12というコードを表現するために使われる場合もあります。Cのソースコードなどは後者の例です。SIGNに変換するわけにはいきません。以下のソースコードは、両者の用法が混在しています。このようなものは、単純にコードコンバーターにかけるだけでは済みません。従来JISとの相互運用にまつわる問題点として担当者の方から解説があったものです。本稿を書いた一番の動機です。Unicodeの問題点というと、漢字統合が真っ先にとりあげられます。漢字統合の問題が意識される機会はそれほど多くないことと思います。本稿でとりあげたような雑多な問題でしょう。最近はシフトJIS的な符号空間を使って文字数を増やすのがはやりのようです。韓国では統合ハングルコード(UHC)といって、同様に韓国語EUCの周辺にハングルの不足分を押し込んでいます。JIS第3・第4水準と称する文字集合の策定が行われようとしています。聞くところによると、香港ではBig5をさらに増やそうという動きすらあるとか。自国の要求を満たすためにはなりふりかまわぬといった感じです。reserved.伊藤隆幸のホームページへ。