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 前寺正彦

At 10:44 AM +0900 00.3.10, OGATA Katsuhiro[小形克宏] wrote:

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

ノーマライゼーション・フォームは、1 種類ではなく、プリコンポーズドを優先す
る方式も定義されていたと思います。ただ、基本的な考え方として、「新たに」プ
リコンポーズド・キャラクタを増やしたくはない、ということだと思います。

> というわけで、Unicodeとしては、前寺さんのおっしゃるように結合文字符号化に関
> しての混乱がUnicode自身のなかにあることを自覚した上で、(2)に統一していこう
> という姿勢をとっていると考えられます。これに基づき、日本が提案した非漢字の
> 半分以上は却下された、そういうことだと僕は理解しています。

規格としての整合性・安定性を重視する視点からは、おのずとおっしゃるような方
向性が出てくるとは思いますが、それほど性急に「統一」に向かうでしょうか？

--
直井@Glamour Profession, Inc.