アカウント名:
パスワード:
それよりも、数ある文字コードのひとつにすぎない UTF-8 を特別扱いすることへの批判が大きかったような。
つまりは、いつもの Unicode 派と CSI (Code Set Independent) 派の論争っ
というのは、Unicode 派は、CSI でいう Unicode サブモジュール部分だけを実装すれば いいからです。逆に言えば、Unicode hardcode 手法だったら完成品ができてしまうくらいの手間を かけて、ようやくサブモジュールがひとつ完成します。
もちろん、それだけの手間をかけるだけの価値が あればいいわけですが、CSI のほうが絶対的に有利に なる場面って、漢字の扱いしかないんですよね。 もちろん、われわれ東アジア人にとってはそれは 非常に大きなことですが、漢字以外のほとんどの文字、 とりわけアルファベット文字圏にとっては、 ほとんど同じ文字が収録されている ISO-8859-1 とか 2 とか 3 とか 15 とか 16 とかを使い分けたり ISO-2022 に基づいた同時使用をしたりするよりは Unicode の ほうがずっと素直です。みんな、Unicode に移行したくて うずうずしてると思いますよ。
漢字にしたって、各国の漢字を同時使用しない限りは Unicode でいいわけで、でもそれはだめだと主張したのが 日本人しかいなくて、中国人も韓国人もそんなに異体字には こだわらない人が多いっぽいから、けっきょくUnicodeに 反対するのは日本人だけの孤立無援状態になってしまってる、 というのが現状だと思います。
それから、話は戻るけど手間というのが、いちど ライブラリを作ってしまってあとはそれを使うだけ、 というのならいいけど、アプリケーションレベルでも それなりに気を使ったプログラミングをしないといけない わけで、そうすると、現在の、国際化されていないソフトが どんどん作られ、それに対して国際化パッチを作って対応 しないといけないという状況は改善されません。 理想としては、たとえば素人プログラマが作っても自動的に 国際化されてるというようなのがいいわけで、CSIでは ちょっとしんどい。といっても、Unicodeに基づいていても、 8ビットフォントを扱うAPIとかを用意しているようじゃ、 だめなんだけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
Xutf8 (スコア:2, 参考になる)
コミュニティとしてやばいなぁと思ったので、あまり驚きはないです(^^;)
あの時も分裂の話があったと思いますが、結局Xutf8ってどうなったんでしょう?
当時はまともに日本語が使えないという話もあったようですが、
今は特に問題ないようなので…。
Re:Xutf8 (スコア:2, 参考になる)
それよりも、数ある文字コードのひとつにすぎない UTF-8 を特別扱いすることへの批判が大きかったような。
つまりは、いつもの Unicode 派と CSI (Code Set Independent) 派の論争っ
Re:Xutf8 (スコア:2, 参考になる)
これって実装が簡単だったからですか?
ちょっと前に多言語化に興味を持って色々調べたことがあるんですが
Code Set Independent 用のライブラリってあるんだろうか…。
(当時)Code Set Independent 派の主張が絵に書いた餅だったのなら、
UTF-8 を選択した XFree86 を安易に責めるわけにもいかないような。
// 個人的には Keith 派かなぁ。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Unicode vs CSI (スコア:3, 参考になる)
いまだにモノが出てこないというのは、
仕方がない部分もあります。
というのは、Unicode 派は、CSI でいう
Unicode サブモジュール部分だけを実装すれば
いいからです。逆に言えば、Unicode hardcode
手法だったら完成品ができてしまうくらいの手間を
かけて、ようやくサブモジュールがひとつ完成します。
もちろん、それだけの手間をかけるだけの価値が
あればいいわけですが、CSI のほうが絶対的に有利に
なる場面って、漢字の扱いしかないんですよね。
もちろん、われわれ東アジア人にとってはそれは
非常に大きなことですが、漢字以外のほとんどの文字、
とりわけアルファベット文字圏にとっては、
ほとんど同じ文字が収録されている ISO-8859-1 とか
2 とか 3 とか 15 とか 16 とかを使い分けたり ISO-2022
に基づいた同時使用をしたりするよりは Unicode の
ほうがずっと素直です。みんな、Unicode に移行したくて
うずうずしてると思いますよ。
漢字にしたって、各国の漢字を同時使用しない限りは
Unicode でいいわけで、でもそれはだめだと主張したのが
日本人しかいなくて、中国人も韓国人もそんなに異体字には
こだわらない人が多いっぽいから、けっきょくUnicodeに
反対するのは日本人だけの孤立無援状態になってしまってる、
というのが現状だと思います。
それから、話は戻るけど手間というのが、いちど
ライブラリを作ってしまってあとはそれを使うだけ、
というのならいいけど、アプリケーションレベルでも
それなりに気を使ったプログラミングをしないといけない
わけで、そうすると、現在の、国際化されていないソフトが
どんどん作られ、それに対して国際化パッチを作って対応
しないといけないという状況は改善されません。
理想としては、たとえば素人プログラマが作っても自動的に
国際化されてるというようなのがいいわけで、CSIでは
ちょっとしんどい。といっても、Unicodeに基づいていても、
8ビットフォントを扱うAPIとかを用意しているようじゃ、
だめなんだけどね。
Re:Unicode vs CSI (スコア:1, 参考になる)
> いまだにモノが出てこないというのは、
> 仕方がない部分もあります。
X の locale model は昔から CSI ですけど。
Solaris は CSI モデルの上でうまく Unicode を扱ってますけど。
実際のところ、ISO C locale の実装に限れば、
CSI でも UCS Normalization でも手間は大して変わらないか、
CSI のほうが楽でしょう。ISO C locale 以上となると話は別ですが。
あの時 Xutf8 に反対した一人として言うと、Xutf8 の駄目な
ところというのは、現状の Xmb* でできるようなことしかできず、
また全く拡張性もない中途半端な API だというところにあります。
あれではせっかくの Unicode も泣いてしまいます。
一方で、私は UCS Normalization という考え方自体は
否定しません。なぜならば、Unicode は現状で M17N に関して
(いろいろ文句はあるものの)実用的な仕様が定義されている
唯一の系である、というところです。もはや ISO-2022 系の
発展が止まってしまっていることを考えると、
多言語環境を目指すなら、CSI にこだわってもしょうがない
という気はします。
Re:Unicode vs CSI (スコア:0)
多言語環境と CSI って別なレイヤーだと思うのですが…
他の部分は全面的に同意です。
Re:Unicode vs CSI (スコア:0)
CSI とか UCS Normalization とかそういうのは意識しなくてもいい。
ただ一方で、多言語系の複雑さとか範囲の大きさを考えたら、
向こう 10 年とかそういうスパンでは、それなりに実用的な唯一の存在として
Unicode ベースの系が君臨するんじゃないかという気がするので、
ほかの系のことはすっぱり忘れて、よーするに手っ取り早くその辺に
落っこちてる ICU でも使って当面はお手軽に済ますのがいいかなと。
ちょっと暴論ぎみですけど。
個人的見解としては、現在はまだまだ M17N に関しては暗中模索な状況で、
Re:Unicode vs CSI (スコア:0)
> CSI とか UCS Normalization とかそういうのは意識しなくてもいい。
うーん、X と libc の wchar とかの抽象化じゃダメということですか?
まぁ、確かに足りない部分ありますけど。
でも、ある特定の codeset の コードポイントを直接見るよりは、
API でも一個作った方が嬉しいなぁ。
いずれ、ほぼスベテ UTF-8 になるとは思いますが、
私の不安は、ハードコードで UTF-8 で 2 byte までしか
処理しないようなプログラ
Re:Xutf8 (スコア:0)