[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode, or die
> From: "T.SHIOZAKI" <AoiMoe@imou.to>
> それなら、wchar_t は現状のままで放っておいて、これとは独立な Unicode
> 前提の API セットを作ったほうが、互換性の観点から正しいことは彼らも
> 分かってるはずなのだけど、何でそうしないのでしょうね。
現在の CSI model の一つの弱点になりつつある XPG5 の API が弱いことと、
それを埋めるための新たなXPG5 ベースの API set を開発し普及させる力が、
現在の ISO や ANSI 等の Standard organization にあるとは思えないことか
ら、wchar_t とは独立な Unicode 前提の API セットは、ICU をベースに、
li18nux-lade という、Li18nux subgroup の main charter の一つとして実際
に作っています。
> 互換性を考えたら、なし崩し的に互換性のない wchar_t の使い方をされるよりも、
もう一つ私の言葉が足りなかったのですが、現実として glibc では、wchar_t
が既にUCS-4/UTF-32 に固定されてしまっていて、すべての locale が、Tru64
UNIX で言う、@ucs4 付きの locale と同じ状態にあります。
> ISO C locale まわりを全部「obsoleted」にして、使わないよう勧告をしてくれた
> 方がはるかにマシなんですが、時間なくてそこのところを質問しそびれたのが残念。
この場を借りてお答えしますと、それも一つの選択肢として残っていないわけ
ではありません。
ただ、樋浦の先見性および力が足りなかったため、Li18nux を設立してこの問
題にあたった時には、glibc の骨格は UCS normalization 方式でできており、
empty contbainer 方式に変更するには少し遅すぎた、とは言えると思います。
glibc が locale にかかわらず、wchar_t を UCS-4/UTF-32 固定に
している点に関して、考えうる選択肢はあまり多くありません。
1. glibc と決裂して、別の解を、他の libc 実装に求める。
2. glibc が真の意味での CSI を実装するまで、その release を妨害する。
3. disagree and commit.
で、1. も 2. も、現実的にはほぼ不可能です。
ここで少々思いだしていただきたいことがあります。
wcahr_t が UCS-4/UTF-32固定であることを認めるからと言って、CSI を捨て
ることになるのか、と言うと、現実的には、そうとも言えないところがあると
考えます。CSI compliant な system/appliaction では、wchar_t の
representation が変わっても困らないはずです。
実際に、wchar_t の representation が変わって困るのは、全てを自前で
持っている X と、wchar_t の representation まで規定した MNLS (および
それを実装したシステム)です。
前者は、本来は、I18N 未実装システム救済のための実装のはずだったもの
が結果として足を引っ張ることになったわけで、wchar_t の representation
を仮定した実装の X を修正するのは理にかなっています。<= 自己批判です。
また、wchar_t の format を規定した MNLS 系実装も同様に、もともと CSI
compliant ではありませんから、MNLS 前提の実装を修正するのも理にかなっ
ていないわけではありません。
別の言い方をすると、現在の X を認めること自体 CSIを捨てているとも言え
てしまうと思います。
ただ、wcahr_t が UCS-4/UTF-32 であることを無条件に保証するかのように
聞こえる私の発言は、たしかに舌足らずでした。
> また、「新しい Rendering & Printing Model」なんて話が出てて、
> 私の興味と重なるところだし、そこはなかなか興味深かった。
Free Standard Group として、明示的に Linux 以外をも標榜したことですし、
この activity にぜひ参加をご検討ください。
> 実質的に CSI は棄ててるのに、それを明言しなかったのは言い訳じみてて残念。
> あと、ああいう「強者の理論」は単なる反感の元にしかならないので残念。
誤解だとよいのですが...
Hideki HIURA, hideki.hiura@Sun.COM
Sun Microsystems Inc. Mountain View, CA.