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

小形さん、はじめまして、前寺です。
長文なのでいろいろコメントすべき場所があるのですが、
とりあえず気付いた部分からコメントします。

> >  すると、濁点「が」表記形式が
> >  (1)「が」、結合完成型
> >  (2)「か゛」、「か」＋結合用濁点
> >  (3)「か゛」、「か」＋独立濁点
(中略)
> ましい。〉。――ちなみに、(3)の方法ってすごいですねえ。すごい邪道！　規格を
> 考えた人は怒るかもしれないけど、確かにそれもあり得ます。“実装”がかかえる
> 現実問題って深いんだなぁ……。

いえ、実装者も意図して(3)のような劣悪な実装はしないと思います。
ただ、意図しないケースがいろいろあるもので、例えば、銀行にある膨大な
濁点付き半角カナのデータを全角カナに変換するときに、
(3)のようなデータが意図せずに生成される可能性もあります。
(2000年問題も閏年問題も似たようなものです。)

> さてさて、ここですこし脱線気味に妄想を広げます。Unicodeの方針はわかりました
> 。ところで、「リサの返信」では、日本のひらがな、カタカナも、ラテン文字のダ
> イヤクリティカル・マークと同列に考えているととれますよね。それゆえに鼻濁音
> ・アイヌ文字を却下しているんですから。

彼らの立場上、収録モラルを維持するためには、こう出張するしかないと思いま
す。
インド文字は、１２文字が連なって合成表記されるケースもあります。
そういうのを個々に対応していたらとても収集がつきません。
濁点付き平仮名だけ特別扱いするわけにはいかないのです。

> とするとですね……ひらがな・カタカナの濁点、半濁点も、やがてすべて現在のよ
> うなプリコンポーズ（ex.「が」）ではなく、コンポジションで処理する方法（
> ex.「か」＋結合用濁点）に移行させる……ってことになりませんか？　これって、

多分、そうなると思います。しかも今後は、Unicodeのライブラリを使用する
場合、それが必ずしも made in Japan なわけではありません。
インドの技術者が、Unicode Book のプロパティシートを見ながら作る場合も
十分ありえます。仮名だけ、つねに合成完成型で扱うなんて例外処理を
期待することは不可能です。

> すごいことになるのでは……？？　どうやって移行するの？　もっとも、JISにおい
> ては“濁点”“半濁点”はあっても、“結合用濁点”“結合用半濁点”はないです
> よね。でもこれはこれで混乱の元になるのか……。ああ、ここで前寺さんの言う

だからガイドラインを早く決めるほうがいいと思います。
しかも仮名についてガイドラインを決められるのは他ならぬ日本人
だけなのです。そして、皮肉にも Unicode だけで閉じた世界では
問題は発生しないので、Unicode派はこの問題に時間を割かないと思います。

したがって、この問題で主導権をとるのは JISX0213側であるべきなんです。

そのうち、各メーカーは必要に迫られ、そんなことお構いなしに、
勝手に JISX0213への変換表を定義しはじめると思います。
それは新たなる混乱に発展するわけです。

例えば、Unicodeコンソーシアムは、XML等で使うべきでない文字コードを
Unicode側自ら示しています。(言語タグ、ルビタグ、一部の記号が該当、
これはまだ検討段階なので、まっとな意見をいえば、追加、削除は
可能です。) 一見自分と関係のない XML のことを気に掛けてまで、
安心して Unicode を使ってもらうための努力をしているのです。

なんか、技術的な話からそれてしまいましたね。
ただ、そこから始めないで、勝手に実装すると
結局はバベル倒壊してしまうんです。

--
  2000/03/10 前寺正彦