現在Unicodeには「か」と合成済みの「が」と濁点が3種類も(合成用のU+3099、合成済みのU+309B、半角濁点)入ってますけど、これは正規化などの「問題」を引き起こすとしてむしろ非難されてますよね。ハングルも合成済みのと「合理的な」組み合わせ式のとKS X 1001互換用の3種類入ってました。 どうして単純にビット数を増やして何でもかんでも固定長に突っ込めばすべてが解決するという単純な頭の人が後を絶たないのか本当に不思議でなりません。すごい文字コード [srad.jp]でも使っててください。
MANIFESTO (スコア:0)
思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:0)
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:1)
これから UCS 正規化方式に切り替えるなら、UTF-16 ではなく UTF-32 を採用したほうがマシですかね。固定長ですし。
現状で UTF-16 を採用するメリットって何も無いような…
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:3, 参考になる)
UTF-32でも可変長が避けて通れない(日本に限ってもIVS [nikkeibp.co.jp]とか)なんていい加減常識になったと思ってたんだけど、なんでまだこんなこと言う人がいるの?
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:5, 参考になる)
合成文字もありますしね。簡単な文字列処理ならともかく、エディタ等では合成された文字を1文字として認識できないとまずいですから。
ブラウザ次第ではありますが、上記のＧＲの台詞をマウスで選択したとき、上は「ま」と濁点が別々の文字、下は1つの文字として扱われているはず。
Re: (スコア:0)
Windows7RC では Firefox/Chrome とも１文字として扱われるものの、「ま ゛」のように仮名と濁点の間に大きな空間が開きますね。まだまだ不完全な感じ。一方 IE8 は隣接するものの、今度は「っ」の上にはみ出して表示されるという不具合が。また選択すると「ま」のみが反転されて、濁点は消えてなくなります。そのままメモ帳に濁点つきでコピペできるところを見ると、文字通り濁点が仮想的なマス目からはみ出て描画されているのかも。ちなみにメモ帳での表示が一番自然に見えました。
Re: (スコア:0)
XPでIE7だけど下のは「ま・っ」となって点になってます
Re: (スコア:0)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja; rv:1.9.3a4pre) Gecko/20100318 Minefield/3.7a4pre
合字されました。
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja-JP-mac; rv:1.9.2) Gecko/20100115 Firefox/3.6
合字されましたが、濁点は文字の左上につきました。
Safari 4.0.5 (6531.22.7)
合字されませんでした。
Re: (スコア:0)
> 合字されませんでした。
うちのSafari(同じversion)ではうまくいってます。
何が違うんだろ。
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だろうと(サロゲートペアを無視した)UCS-2だろうとWindows←→Mac OS X間のファイル共有を実装しようとするだけで文字合成(「タ,U+3099←→ダ」とか)の考慮は必須です。
UTF-8やUTF-16は定義域をU+10FFFFまでに制限している限り1コードポイントのサイズが4バイトを超えることはありませんから、UTF-32はメモリの無駄遣いでしかありません。ISO/IEC 10646でもUnicodeとの相互運用性向上のため、U+10FFFFを超える範囲は「永久予約」とされました。
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は当時からあったのですからいくらなんでもその主張は無理があるでしょう。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:2)
いっそ全面固定長のUTF-128を…
# zipでよく潰れそう
Re: (スコア:0)
現在Unicodeには「か」と合成済みの「が」と濁点が3種類も(合成用のU+3099、合成済みのU+309B、半角濁点)入ってますけど、これは正規化などの「問題」を引き起こすとしてむしろ非難されてますよね。ハングルも合成済みのと「合理的な」組み合わせ式のとKS X 1001互換用の3種類入ってました。
どうして単純にビット数を増やして何でもかんでも固定長に突っ込めばすべてが解決するという単純な頭の人が後を絶たないのか本当に不思議でなりません。すごい文字コード [srad.jp]でも使っててください。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:2)
固定長であることとは関係しないのでは? たとえばUTF-32を一文字64bitの、余りは0埋めした固定長として扱う、とか。
Re: (スコア:0)
漢字も部首とかの部品を合成するようにすればいいんですよね。
漫画とかで漢字?っぽい必殺技が出てきても大丈夫だし。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (スコア:1)
Re: (スコア:0)
>いっそ全面固定長のUTF-128を…
モノクロ32x32ビットマップフォントがまんま入りますね
#それ文字コードちゃう
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
IVSはそれ自体で一文字だから、関係ないでしょ
Re: (スコア:0)
WindowsやMac OS X(Cocoa)と互換性が高くなるというメリットがあります。