アカウント名:
パスワード:
GNU libc は wchar_t に UCS-4 を採用してしまったので、TRON コードロケールは実現不可能になってしまいました。というか、TRON コードロケール以外にも、文字集合が UCS-4 のサブセットではないようなエンコーディング、たとえば ISO-2022-JP-2 なども不可能です。もちろん、それが可能だからといって実際にそれを実装するかというと話は別ですけど。
Linux など、wchar_t イコール UCS-4 なシステムで ISO-2022 系のロケールを実装するための、どこまで本気か冗談か分からないような提案もあります。__STDC_ISO_10646__ の定義に思いっきり違反しているように思うのですが。ただ、このページの著者の Markus Kuhn さんは、どうやら Unicode についてはかなり権威と見られているようで、たとえば google で Unicode を検索してみると Unicode Consortium のページ (とその旧ページ) の次に彼の UTF-8 and Unicode FAQ for Unix/Linux が出てきたりして、寒いです。
*BSD ではどうなのでしょうか?Solarisとか、ほかのUN*Xでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
UN*XでTRONコード (スコア:1)
GNU libc は wchar_t に UCS-4 を採用してしまったので、TRON コードロケールは実現不可能になってしまいました。というか、TRON コードロケール以外にも、文字集合が UCS-4 のサブセットではないようなエンコーディング、たとえば ISO-2022-JP-2 なども不可能です。もちろん、それが可能だからといって実際にそれを実装するかというと話は別ですけど。
Linux など、wchar_t イコール UCS-4 なシステムで ISO-2022 系のロケールを実装するための、どこまで本気か冗談か分からないような提案もあります。__STDC_ISO_10646__ の定義に思いっきり違反しているように思うのですが。ただ、このページの著者の Markus Kuhn さんは、どうやら Unicode についてはかなり権威と見られているようで、たとえば google で Unicode を検索してみると Unicode Consortium のページ (とその旧ページ) の次に彼の UTF-8 and Unicode FAQ for Unix/Linux が出てきたりして、寒いです。
*BSD ではどうなのでしょうか?Solarisとか、ほかのUN*Xでは?