XMLと文字メーリングリスト メッセージ閲覧

はじめまして、小形ともうします。

こちらのＭＬでも話題にしていただいている「文字の海、ビットの舟」という連載
の筆者です。
前寺さんの話題にされている結合文字の話題を、ちょうど今追いかけているところ
で、自分の理解を深めたい意図もあって発言させていただきます。

つい先日W3Cの関係者にお会いしたときも、まさに前寺さんが問題にしたテーマが話
題になりました。まだ話を完全に咀嚼しておらず、しめされた資料にも十分あたっ
ていない時点ですので、迷惑になってしまいますから、この方の名前を出すのはご
勘弁ください（まあ大方検討はつくでしょうが）。

で、この問題に対するUnicodeコンソーシアムの姿勢は、分かりやすい例でいえば「
リサの返信」( http://www.cse.cuhk.edu.hk/~irg/irg/N690_Lisa_JIS.doc )、つま
りUTCリサ・ムーア委員長が芝野耕司JCS委員長にあてた手紙の、以下の記述に見ら
れると思います。
----------
* The UTC strongly discourages encoding further precomposed characters 
which can be represented with combining characters already in the 
standard.  A new normalization form, canonical composition, was defined 
in the Unicode Standard, Version 3, based on the Unicode Version 3 
Character Database. Many companies and organizations (including the W3C) 
are adopting this new normalization form, and it is expected that most 
programs will use normalized data. For stability, the normalized form of 
new precomposed characters will be the decomposition to a base character 
plus combining characters. Thus there is little value in adding new 
precomposed characters. For more information, see Unicode Technical 
Report #15 (http://www.unicode.org/unicode/reports/tr15/).

* UTCは、すでに標準に含まれる結合文字によって表現できる合成済みキャラクタを
これ以上エンコードすることがないよう、強く勧告する。Unicode標準のバージョン
3.0では、Unicodeバージョン3・キャラクタ・データベースに基づいた新しいノーマ
ライゼーション・フォームである正規化コンポジションが定義されている。多くの
企業および組織（W3Cを含む）が、この新しいノーマライゼーション・フォームを採
用しており、ほとんどのプログラムがノーマライズされたデータを用いることにな
ると期待されている。安定性の観点から、新たな合成済みキャラクタのノーマライ
ズド・フォームは、基底文字プラス結合文字に分解されるのが望ましい。したがっ
て、新しい合成済みキャラクタを追加する価値は、ほとんどない。より以上の情報
は、Unicode技術レポート#15を参照されたい（
http://www.unicode.org/unicode/reports/tr15/）。
--------

つまり、前寺さんの指摘される、結合文字を表示する３つの方法、

>  すると、濁点「が」表記形式が
>  (1)「が」、結合完成型
>  (2)「か゛」、「か」＋結合用濁点
>  (3)「か゛」、「か」＋独立濁点

のうち、Unicodeは、〈多くの企業および組織（W3Cを含む）〉同様に、(2)の方法を
とることを〈期待〉している。つまり〈安定性の観点から、新たな合成済みキャラ
クタのノーマライズド・フォームは、基底文字プラス結合文字に分解されるのが望
ましい。〉。――ちなみに、(3)の方法ってすごいですねえ。すごい邪道！　規格を
考えた人は怒るかもしれないけど、確かにそれもあり得ます。“実装”がかかえる
現実問題って深いんだなぁ……。

というわけで、Unicodeとしては、前寺さんのおっしゃるように結合文字符号化に関
しての混乱がUnicode自身のなかにあることを自覚した上で、(2)に統一していこう
という姿勢をとっていると考えられます。これに基づき、日本が提案した非漢字の
半分以上は却下された、そういうことだと僕は理解しています。ちなみに、W3Cの方
は、この混乱を、93年のISO/IEC 10646のDIS1、2とオリジナルUnicodeの合流時点に
遡る、根元的な問題だとも指摘されていました。ここらへんも今後探っていきたい
ところではあります。

ここで検証しなくてはならないのは、以下の点でしょう。つまり、

(a) Unicode（ISO/IEC 10646）規格票では、上記の方針がどのように反映されてい
るのか（もしくは本当に反映されているのか）。

(b) 0213規格票では、上記の方針は反映されているのか。結合文字はどのように定
義されているのか。


実は僕もまだ0213規格票を買えていません（いけませんね）。Unicode3.0はありま
すが、英語の厚い壁に阻まれてすぐに回答をだすことは困難です（ああ自己嫌悪）
。さしあたって、手元にある情報部会に提出された去年秋時点の0213規格票案をと
りあえず参照することにすると、以下のような記述があります。

-------------
6.5.2　漢字集合中の図形文字の種類
a)特殊文字
:
4) ダイヤクリティカル・マーク（合成可能）　ダイヤクリティカル・マーク（合成
可能）32文字の名前及びビット組み合わせは附属書４表２による。
　備考　文字合成を実現する場合には、合成をおこなう前に、ダイヤクリティカル
・マーク（合成可能）を、現在位置の前進を伴わない文字として用いることができ
る。なお、ダイヤクリティカル・マークを用いた文字の合成を想定する場合は、文
字合成の有無にかかわらず、ダイヤクリティカル・マーク（合成可能）を使用する
ことを推奨する。
---------------

これはあくまでも規格票案であることを踏まえて考えねばなりませんが、ここでは
「ダイヤクリティカル・マーク」と「ダイヤクリティカル・マーク（合成可能）」
を区別しており、さらに〈文字合成の有無にかかわらず、ダイヤクリティカル・マ
ーク（合成可能）を使用することを推奨する。〉と、上記Unicodeの方針を踏まえた
ともとれる記述がみられます。


さてさて、ここですこし脱線気味に妄想を広げます。Unicodeの方針はわかりました
。ところで、「リサの返信」では、日本のひらがな、カタカナも、ラテン文字のダ
イヤクリティカル・マークと同列に考えているととれますよね。それゆえに鼻濁音
・アイヌ文字を却下しているんですから。
とするとですね……ひらがな・カタカナの濁点、半濁点も、やがてすべて現在のよ
うなプリコンポーズ（ex.「が」）ではなく、コンポジションで処理する方法（
ex.「か」＋結合用濁点）に移行させる……ってことになりませんか？　これって、
すごいことになるのでは……？？　どうやって移行するの？　もっとも、JISにおい
ては“濁点”“半濁点”はあっても、“結合用濁点”“結合用半濁点”はないです
よね。でもこれはこれで混乱の元になるのか……。ああ、ここで前寺さんの言う
(3)の実装方法が意味をもつのかしら？　ううむ。

ちょっと収拾がつかなくなってきたので、ここらへんでひとまず擱筆します。初登
場なのに、すこし飛ばしすぎてしまいました。どうぞ、これからもよろしくお願い
いたします。

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
小形克宏(うさぱら有限会社)/OGATA Katsuhiro(USAPARA corp)
ogwata@s2.ocv.ne.jp