アカウント名:
パスワード:
これから UCS 正規化方式に切り替えるなら、UTF-16 ではなく UTF-32 を採用したほうがマシですかね。固定長ですし。現状で UTF-16 を採用するメリットって何も無いような…
UTF-32でも可変長が避けて通れない(日本に限ってもIVS [nikkeibp.co.jp]とか)なんていい加減常識になったと思ってたんだけど、なんでまだこんなこと言う人がいるの?
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1260 [xml.gr.jp] > これだけPCの容量が大きくなったのだから32bitにしてもいいじゃないか、と> いう意見がありますが、これは一種の錯誤です。続きはリンク先をどうぞ。最近ではスマートフォンとかiPadとかネットブックとかの、PCよりメモリ要求が厳しい端末も無視できませんからなおさらですね(主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。これは理由のないことではありません)。UTF-32にしても固定長で処理が済むわけでは全然なく、メリットはありません。UTF-32だろうと(
あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。
> 主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。> これは理由のないことではありません
これはそれぞれのエンコーディングを机上に並べて評価したと言うより、依存先のライブラリや、プロジェクトの起点が UTF-16 だったからという理由じゃないですかね。IE なら Windows、WebKit なら fork 元の KHTML の親プロジェクトの KDE、Firefox なら Mozilla Project と。どれも UTF-32 が生まれる前から存在するプロジェクトなので、まぁそうなりますよね。というか、UCS-2 時代から存在するコードからすると UTF-8 すら新参になるため、その資産を生かそうとすると UTF-16 以外選択肢にならなくなってしまうと。
そういえば、JavaScript は所々に UTF-16 前提の仕様が入ってますね。
> あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。でも__STDC_ISO_10646__は主流じゃなかったと思いますけど。まあ、>> 私の感想は「ああ、余裕のある組織なんだな」。お>> そらく余裕の無いところは意地でMacを使い続ける余裕はなく、お客さんが>> WindowsならWindowsにしないとやってられないのだろうな、と思いました。なんて書いてるような人だからWindows以外眼中に無いのは確かでしょうけど。本人は否定してますけど視点がものすごくWindowsに偏向してますから。> どれも UTF-32 が生まれる前からUCS-4は当時からあったのですからいくらなんでもその主張は無理があるでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
MANIFESTO (スコア:0)
思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:0)
Re: (スコア:1)
これから UCS 正規化方式に切り替えるなら、UTF-16 ではなく UTF-32 を採用したほうがマシですかね。固定長ですし。
現状で UTF-16 を採用するメリットって何も無いような…
Re: (スコア:3, 参考になる)
UTF-32でも可変長が避けて通れない(日本に限ってもIVS [nikkeibp.co.jp]とか)なんていい加減常識になったと思ってたんだけど、なんでまだこんなこと言う人がいるの?
Re: (スコア:2, 参考になる)
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1260 [xml.gr.jp]
> これだけPCの容量が大きくなったのだから32bitにしてもいいじゃないか、と
> いう意見がありますが、これは一種の錯誤です。
続きはリンク先をどうぞ。
最近ではスマートフォンとかiPadとかネットブックとかの、PCよりメモリ要求が厳しい端末も無視できませんからなおさらですね(主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。これは理由のないことではありません)。
UTF-32にしても固定長で処理が済むわけでは全然なく、メリットはありません。UTF-32だろうと(
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:2)
あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。
> 主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。
> これは理由のないことではありません
これはそれぞれのエンコーディングを机上に並べて評価したと言うより、
依存先のライブラリや、プロジェクトの起点が UTF-16 だったからという理由じゃないですかね。
IE なら Windows、WebKit なら fork 元の KHTML の親プロジェクトの KDE、
Firefox なら Mozilla Project と。
どれも UTF-32 が生まれる前から存在するプロジェクトなので、まぁそうなりますよね。
というか、UCS-2 時代から存在するコードからすると UTF-8 すら新参になるため、
その資産を生かそうとすると UTF-16 以外選択肢にならなくなってしまうと。
そういえば、JavaScript は所々に UTF-16 前提の仕様が入ってますね。
Re: (スコア:0)
> あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。
でも__STDC_ISO_10646__は主流じゃなかったと思いますけど。
まあ、
>> 私の感想は「ああ、余裕のある組織なんだな」。お
>> そらく余裕の無いところは意地でMacを使い続ける余裕はなく、お客さんが
>> WindowsならWindowsにしないとやってられないのだろうな、と思いました。
なんて書いてるような人だからWindows以外眼中に無いのは確かでしょうけど。本人は否定してますけど視点がものすごくWindowsに偏向してますから。
> どれも UTF-32 が生まれる前から
UCS-4は当時からあったのですからいくらなんでもその主張は無理があるでしょう。