「ロケールに従うこと」記事へのコメント

ロケール問題

[keisuken (2614)]

確かに、ロケールの問題は多いと思う。

ロケールに限ったことではないのですが、一般の人に Linux などの UN*X 互換 OS を進められない原因の１つだと思う。つまりアプリケーションによって操作方法とか仕様の統一が行われておらず混乱を招いているということなんですが...。

そういう意味で、ロケール指定方法の統一とか、フレーム

Re:ロケール問題

[keisuken (2614)]

まだ言いたいことがあった。というより忘れてた(^^;。

ロケール問題で、kubota さんが取り上げてた問題で、いわゆる複数のロケール(含む、国, 時間帯, 通貨, 言語など)をどう表現し扱うのか。

一番の問題点は、Unicode 系で統一しようとする動きですよね。日本にいる限り日本人である限り、Unicode (UTF-7/8 など) の便利さは否定しないものの、Unicode だけに統一しちゃうというのは NG です。という

Unicode 系で統一

[kubota (64)]

最終的には Unicode 系で統一になるのでは、と思っています。なぜなら、言語、時間帯、通貨、文字などは文化や生活に密着したものですが、エンコーディングはそうではないからです。

つまり、日本語や漢字は日本文化そのものですが、EUC-JP や Shift_JIS は日本文化ではありません。

EUC-JP や Shift_JIS の範囲は、現在の Unicode は完全に上位互換性を保っていますので、原理的には置き換えることが可能です。TRON コードや文字鏡コードなどは Unicode とは違ったポリシーや文字を持っていますので、置き換えることができません。ですので、TRON コードや文字鏡コードが必要な場所ではそれは残るでしょう。が、少なくとも現在ロケールの枠組みに従って使わ

Re:Unicode 系で統一

[keisuken (2614)]

私の場合、プログラミングの大半は Java で行っており、その中での国際化(含むロケール)のフラームワークしか知らないので、誤解も含まれています。すんません。

EUC-JP や Shift_JIS の範囲は、現在の Unicode は完全に上位互換性を保っていますので、原理的には置き換えることが可能です。... が、少なくとも現在ロケールの枠組みに従って使われている文字コードは将来的には Unicode 系で統一されることになると思います。

漢字の異体字については、Variation Selectorというのができるみたいなので、将来的にはこれで解決に向かうと思います。

なるほど、こんな感じで統一しようとしているのですねぇ。

Unicode 系でさしあたっていちばん気をつけないといけないのは、Unicode をサポートしていると謳っているけど実はほんのサブセットしかサポートしていない、ということです。

Java の場合もまだサブセットですね。

ただ、Unicode をぜんぶサポートするというのはほんとうに大変で、いま私たちが「Unicode サポートといってもヨーロッパ言語だけで、日本語は対応していないじゃないか」と文句を言う側なのが、将来的には逆に「Unicode サポートといっても英語と CJK だけで、xx 語は対応していないじゃないか」と文句を言われる側にまわるのではないかと思います。(xx には、タイ語、アラビア語、ヘブライ語、などが入るのではないかと思います)

たしかに、そのあたりの面倒臭さとローカルの人々がサポートしなくちゃいけない問題などなかなか難しいところがありますよね。それは、Java で国際化プログラミングを組んでいるときに感じていました。

異体字以外にも、CJK や日本語固有の問題としては、文字幅 (全角/半角) の問題と変換テーブルの問題があります。

これをエンコードと認識していたこと自体が問題だと思います。

やっぱり、世界の大半は Unicode に持っていきたいみたいですねぇ。個人的には、やりたいことがすべて Unicode でまかなえるのかということと、文化的な側面が本当に損なわれないのか危惧しています。

それに伴う、仕様の巨大化も何とかしてほしいですね。