アカウント名:
パスワード:
確かに、ロケールの問題は多いと思う。
ロケールに限ったことではないのですが、一般の人に Linux などの UN*X 互換 OS を進められない原因の１つだと思う。つまりアプリケーションによって操作方法とか仕様の統一が行われておらず混乱を招いているということなんですが...。
そういう意味で、ロケール指定方法の統一とか、フレームワークの統一とか、別の意味での制限みたいなものが必要だと思う。
過去の遺産をどう引き継ぐかという問題もあるのですが...。もし本当に使ってもらいたいならちゃんとそのあたり整備したほうがいいんですよね。場合によっては過去の遺産は捨てるだけの覚悟も必要かもしれません。
まだ言いたいことがあった。というより忘れてた(^^;。
ロケール問題で、kubota さんが取り上げてた問題で、いわゆる複数のロケール(含む、国, 時間帯, 通貨, 言語など)をどう表現し扱うのか。
一番の問題点は、Unicode 系で統一しようとする動きですよね。日本にいる限り日本人である限り、Unicode (UTF-7/8 など) の便利さは否定しないものの、Unicode だけに統一しちゃうというのは NG です。というより日本という文化を捨ててしまうのではないかと危惧するほど。
そのあたり風間さんとかいろいろ日本人の中からも話が出ているようですが、あまり ISO-8859-1 圏の方々は理解してくれないご様子で(苦笑。
もっともっとそういう部分の活動をしていかなくちゃいけないですよね。
ロケールに合わせて動作すべき，というのはもっともですが， kterm や less や lv などのように， 文字エンコーディングを意識して動作する場合はなかなか難しいものがあります。 というのも，現在のロケールでサポートされている文字エンコーディングが何か，というのを知ることができないから。 文字エンコーディングの名前を返す標準的な関数としては nl_langinfo(CODESET) がありますが， 古い OS (ちょっと前までの Linux を含む) では関数自体がないし，もっと致命的なのは， これの返す値が標準化されていないこと。 特定 OS だけで動けばいいのなら楽でしょうが， 移植性を考えると，頭痛がしてきます。
C 言語のロケール・モデルは，ロケールが大域変数のような形で存在するという考え方なので，この枠内で考える限りはうまい解はありません。 X/Open の DISS [opengroup.org] のようにロケールを一つのオブジェクトとして扱うとか， さらには文字というもの自体をオブジェクト化して， アプリケーションから文字列操作を直接させないことにするとか， いくつか提案は出ています。 レンダリングに注目したものでは STSF [sourceforge.net] とか。
エンコーディングを自前で操作するソフトウェアですが、nl_langinfo() がなければ、Bruno Haible さんの libiconv や libcharset を使うことができます。ただ、LGPL なのでどこにでも使うというわけにはいかないですが。
完璧を目指すのでなければ、ある程度は nl_langinfo(CODESET) のエミュレートはできます。もしバグレポートが来なければいまのところその程度で困る人はいないということだし、バグレポートが来ればテーブルにそれを追加すればいいし、どちらにせよ、実用上問題にはなりません。
最近、Li18nux が、ロケール名称の統一化ガイドラインを作ろうとしていますが、なぜこれが10年前ではなく今の仕事となっているのかが、不思議でたまりません (もちろん10年前には Li18nux はありませんでしたので、これは Li18nux の責任ではありません)。それに、Li18nux はどうやら Linux だけに特化した団体ではなさそうな気配なのですが、はっきりとしたことはよくわからないし。標準化団体なのならこういうところをはっきりさせないとだめだと思うのですが。
それでも、たとえば fr_FR は ISO-8859-1 なのか ISO-8859-15 なのか、とか、いろいろと悩ましいですね。
最近、Li18nux が、ロケール名称の統一化ガイドラインを作ろうとしていますが、なぜこれが10年前ではなく今の仕事となっているのかが、不思議でたまりません
うう，耳が痛い． なぜ10年前にできなかったのか， ということですが，
…から，他社と共通化するという方向性が乏しかったのが原因と思います．その後，Windows 3.1 以降で Windows 上での国際化機能は実質的に統一され，UNIX 陣営も CDE (Common Desktop Environment) で統一する方向があったのですが， Linux や *BSD では，それがまた独自でばらばらの状態に戻ってしまった．そういう意味では，最大の問題は:
かもしれません．たとえば MIME では charset パラメーターの値は登録制になっていますが， setlocale() や iconv_open() で使う名前はそうなっていないから，ばらばらに実装することを許してしまった．
(もちろん10年前には Li18nux はありませんでしたので、これは Li18nux の責任ではありません)。
主要メンバーは10年前からの残党ですが :-)
最終的には Unicode 系で統一になるのでは、と思っています。なぜなら、言語、時間帯、通貨、文字などは文化や生活に密着したものですが、エンコーディングはそうではないからです。
つまり、日本語や漢字は日本文化そのものですが、EUC-JP や Shift_JIS は日本文化ではありません。
EUC-JP や Shift_JIS の範囲は、現在の Unicode は完全に上位互換性を保っていますので、原理的には置き換えることが可能です。TRON コードや文字鏡コードなどは Unicode とは違ったポリシーや文字を持っていますので、置き換えることができません。ですので、TRON コードや文字鏡コードが必要な場所ではそれは残るでしょう。が、少なくとも現在ロケールの枠組みに従って使われている文字コードは将来的には Unicode 系で統一されることになると思います。(TRON コードや文字鏡コードやフル実装の ISO-2022 がロケールに従った文脈で使われている例というのを知りません)。
漢字の異体字については、Variation Selector [unicode.org] というのができるみたいなので、将来的にはこれで解決に向かうと思います。
従来みたいに、英語と日本語あるいはせいぜい CJK だけサポートして「国際化」と称していられた時代ならともかく、bidi や結合文字といった強敵 (これらは文字そのものの性質だから、無視することは文化の多様性を無視することになる) を前に、文化そのものではないエンコーディングの多様性にまで開発努力を向けている余裕はない、というのが、Unicode 派の考えていることなのではないかと思います。
Unicode 系でさしあたっていちばん気をつけないといけないのは、Unicode をサポートしていると謳っているけど実はほんのサブセットしかサポートしていない、ということです。ただ、Unicode をぜんぶサポートするというのはほんとうに大変で、いま私たちが「Unicode サポートといってもヨーロッパ言語だけで、日本語は対応していないじゃないか」と文句を言う側なのが、将来的には逆に「Unicode サポートといっても英語と CJK だけで、xx 語は対応していないじゃないか」と文句を言われる側にまわるのではないかと思います。(xx には、タイ語、アラビア語、ヘブライ語、などが入るのではないかと思います)
異体字以外にも、CJK や日本語固有の問題としては、文字幅 (全角/半角) の問題と変換テーブルの問題 [debian.or.jp]があります。
私の場合、プログラミングの大半は Java で行っており、その中での国際化(含むロケール)のフラームワークしか知らないので、誤解も含まれています。すんません。
EUC-JP や Shift_JIS の範囲は、現在の Unicode は完全に上位互換性を保っていますので、原理的には置き換えることが可能です。... が、少なくとも現在ロケールの枠組みに従って使われている文字コードは将来的には Unicode 系で統一されることになると思います。 漢字の異体字については、Variation Selectorというのができるみたいなので、将来的にはこれで解決に向かうと思います。
漢字の異体字については、Variation Selectorというのができるみたいなので、将来的にはこれで解決に向かうと思います。
なるほど、こんな感じで統一しようとしているのですねぇ。
Unicode 系でさしあたっていちばん気をつけないといけないのは、Unicode をサポートしていると謳っているけど実はほんのサブセットしかサポートしていない、ということです。
Java の場合もまだサブセットですね。
ただ、Unicode をぜんぶサポートするというのはほんとうに大変で、いま私たちが「Unicode サポートといってもヨーロッパ言語だけで、日本語は対応していないじゃないか」と文句を言う側なのが、将来的には逆に「Unicode サポートといっても英語と CJK だけで、xx 語は対応していないじゃないか」と文句を言われる側にまわるのではないかと思います。(xx には、タイ語、アラビア語、ヘブライ語、などが入るのではないかと思います)
たしかに、そのあたりの面倒臭さとローカルの人々がサポートしなくちゃいけない問題などなかなか難しいところがありますよね。それは、Java で国際化プログラミングを組んでいるときに感じていました。
異体字以外にも、CJK や日本語固有の問題としては、文字幅 (全角/半角) の問題と変換テーブルの問題があります。
これをエンコードと認識していたこと自体が問題だと思います。
やっぱり、世界の大半は Unicode に持っていきたいみたいですねぇ。個人的には、やりたいことがすべて Unicode でまかなえるのかということと、文化的な側面が本当に損なわれないのか危惧しています。
それに伴う、仕様の巨大化も何とかしてほしいですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ロケール問題 (スコア:1)
確かに、ロケールの問題は多いと思う。
ロケールに限ったことではないのですが、一般の人に Linux などの UN*X 互換 OS を進められない原因の１つだと思う。つまりアプリケーションによって操作方法とか仕様の統一が行われておらず混乱を招いているということなんですが...。
そういう意味で、ロケール指定方法の統一とか、フレームワークの統一とか、別の意味での制限みたいなものが必要だと思う。
過去の遺産をどう引き継ぐかという問題もあるのですが...。もし本当に使ってもらいたいならちゃんとそのあたり整備したほうがいいんですよね。場合によっては過去の遺産は捨てるだけの覚悟も必要かもしれません。
Re:ロケール問題 (スコア:1)
まだ言いたいことがあった。というより忘れてた(^^;。
ロケール問題で、kubota さんが取り上げてた問題で、いわゆる複数のロケール(含む、国, 時間帯, 通貨, 言語など)をどう表現し扱うのか。
一番の問題点は、Unicode 系で統一しようとする動きですよね。日本にいる限り日本人である限り、Unicode (UTF-7/8 など) の便利さは否定しないものの、Unicode だけに統一しちゃうというのは NG です。というより日本という文化を捨ててしまうのではないかと危惧するほど。
そのあたり風間さんとかいろいろ日本人の中からも話が出ているようですが、あまり ISO-8859-1 圏の方々は理解してくれないご様子で(苦笑。
もっともっとそういう部分の活動をしていかなくちゃいけないですよね。
Re:ロケール問題 (スコア:1)
ロケールに合わせて動作すべき，というのはもっともですが， kterm や less や lv などのように， 文字エンコーディングを意識して動作する場合はなかなか難しいものがあります。 というのも，現在のロケールでサポートされている文字エンコーディングが何か，というのを知ることができないから。 文字エンコーディングの名前を返す標準的な関数としては nl_langinfo(CODESET) がありますが， 古い OS (ちょっと前までの Linux を含む) では関数自体がないし，もっと致命的なのは， これの返す値が標準化されていないこと。 特定 OS だけで動けばいいのなら楽でしょうが， 移植性を考えると，頭痛がしてきます。
C 言語のロケール・モデルは，ロケールが大域変数のような形で存在するという考え方なので，この枠内で考える限りはうまい解はありません。 X/Open の DISS [opengroup.org] のようにロケールを一つのオブジェクトとして扱うとか， さらには文字というもの自体をオブジェクト化して， アプリケーションから文字列操作を直接させないことにするとか， いくつか提案は出ています。 レンダリングに注目したものでは STSF [sourceforge.net] とか。
nl_langinfo (スコア:1)
エンコーディングを自前で操作するソフトウェアですが、nl_langinfo() がなければ、Bruno Haible さんの libiconv や libcharset を使うことができます。ただ、LGPL なのでどこにでも使うというわけにはいかないですが。
完璧を目指すのでなければ、ある程度は nl_langinfo(CODESET) のエミュレートはできます。もしバグレポートが来なければいまのところその程度で困る人はいないということだし、バグレポートが来ればテーブルにそれを追加すればいいし、どちらにせよ、実用上問題にはなりません。
最近、Li18nux が、ロケール名称の統一化ガイドラインを作ろうとしていますが、なぜこれが10年前ではなく今の仕事となっているのかが、不思議でたまりません (もちろん10年前には Li18nux はありませんでしたので、これは Li18nux の責任ではありません)。それに、Li18nux はどうやら Linux だけに特化した団体ではなさそうな気配なのですが、はっきりとしたことはよくわからないし。標準化団体なのならこういうところをはっきりさせないとだめだと思うのですが。
それでも、たとえば fr_FR は ISO-8859-1 なのか ISO-8859-15 なのか、とか、いろいろと悩ましいですね。
[gnu.org]Re:nl_langinfo (スコア:1)
うう，耳が痛い． なぜ10年前にできなかったのか， ということですが，
…から，他社と共通化するという方向性が乏しかったのが原因と思います．その後，Windows 3.1 以降で Windows 上での国際化機能は実質的に統一され，UNIX 陣営も CDE (Common Desktop Environment) で統一する方向があったのですが， Linux や *BSD では，それがまた独自でばらばらの状態に戻ってしまった．そういう意味では，最大の問題は:
かもしれません．たとえば MIME では charset パラメーターの値は登録制になっていますが， setlocale() や iconv_open() で使う名前はそうなっていないから，ばらばらに実装することを許してしまった．
主要メンバーは10年前からの残党ですが :-)
Unicode 系で統一 (スコア:1)
最終的には Unicode 系で統一になるのでは、と思っています。なぜなら、言語、時間帯、通貨、文字などは文化や生活に密着したものですが、エンコーディングはそうではないからです。
つまり、日本語や漢字は日本文化そのものですが、EUC-JP や Shift_JIS は日本文化ではありません。
EUC-JP や Shift_JIS の範囲は、現在の Unicode は完全に上位互換性を保っていますので、原理的には置き換えることが可能です。TRON コードや文字鏡コードなどは Unicode とは違ったポリシーや文字を持っていますので、置き換えることができません。ですので、TRON コードや文字鏡コードが必要な場所ではそれは残るでしょう。が、少なくとも現在ロケールの枠組みに従って使われている文字コードは将来的には Unicode 系で統一されることになると思います。(TRON コードや文字鏡コードやフル実装の ISO-2022 がロケールに従った文脈で使われている例というのを知りません)。
漢字の異体字については、Variation Selector [unicode.org] というのができるみたいなので、将来的にはこれで解決に向かうと思います。
従来みたいに、英語と日本語あるいはせいぜい CJK だけサポートして「国際化」と称していられた時代ならともかく、bidi や結合文字といった強敵 (これらは文字そのものの性質だから、無視することは文化の多様性を無視することになる) を前に、文化そのものではないエンコーディングの多様性にまで開発努力を向けている余裕はない、というのが、Unicode 派の考えていることなのではないかと思います。
Unicode 系でさしあたっていちばん気をつけないといけないのは、Unicode をサポートしていると謳っているけど実はほんのサブセットしかサポートしていない、ということです。ただ、Unicode をぜんぶサポートするというのはほんとうに大変で、いま私たちが「Unicode サポートといってもヨーロッパ言語だけで、日本語は対応していないじゃないか」と文句を言う側なのが、将来的には逆に「Unicode サポートといっても英語と CJK だけで、xx 語は対応していないじゃないか」と文句を言われる側にまわるのではないかと思います。(xx には、タイ語、アラビア語、ヘブライ語、などが入るのではないかと思います)
異体字以外にも、CJK や日本語固有の問題としては、文字幅 (全角/半角) の問題と変換テーブルの問題 [debian.or.jp]があります。
Re:Unicode 系で統一 (スコア:1)
私の場合、プログラミングの大半は Java で行っており、その中での国際化(含むロケール)のフラームワークしか知らないので、誤解も含まれています。すんません。
なるほど、こんな感じで統一しようとしているのですねぇ。
Java の場合もまだサブセットですね。
たしかに、そのあたりの面倒臭さとローカルの人々がサポートしなくちゃいけない問題などなかなか難しいところがありますよね。それは、Java で国際化プログラミングを組んでいるときに感じていました。
これをエンコードと認識していたこと自体が問題だと思います。
やっぱり、世界の大半は Unicode に持っていきたいみたいですねぇ。個人的には、やりたいことがすべて Unicode でまかなえるのかということと、文化的な側面が本当に損なわれないのか危惧しています。
それに伴う、仕様の巨大化も何とかしてほしいですね。