確かに正規化形式 C (NFC) にすると、例えば a + umlaut が a umlaut という一つの文字になるように、多くの combining character sequence が合成済文字に変換されるので、グリフと一対一に対応することが増えるのですが、すべての combining character sequence が対応する合成済文字を持っているわけではないし、 Unicode 文字と表示上のグリフとが一対一に対応しないのは合成文字が関わる場合以外にリガチャーの場合もあるので (もっとほかにもあると思います)、 NFC にして解決するのは問題の一部です。
悪夢じゃね? (スコア:1)
新しくユニコードに含める、ってことは、書体の(フォントファイルの)中に入るって話だよね。
そうすると、絵文字に対応した書体と対応してない書体が世の中で入り乱れたりすると。
Q.「送られてきたメールの文字がソフトバンクのマークになります」
A.「書体を変更してください」
見たいな文章がそこここにあふれることになるんでしょう?
A.「エンコード形式を UTF-8+emojiに設定してください 」
とか
A.「その書体は絵文字入って無いので、新しく買いなおしてください、○万円です」
とか
A.「
Re: (スコア:1, 興味深い)
http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html [unicode.org]
によるとまだunicodeコードの割り当ては当然まだですが、
携帯各社はU+Exxx(外字領域; Private Use Area)を使い、
google内部コードはU+FExxxになっていますね。
U+5桁ということは、サロゲートペア…
もし正式採用でもサロゲートペア(非BMP面、つまり16bits/charで収まらない領域)であれば、悪夢です。
utf-8はサロゲートペアの処理時に特殊な扱いをしなければならないのですが、正式な規格とはことなる独自規格もひろまっていますし(そのうち正式な規格に統一されるで
Re: (スコア:1)
税金のようなものです。考慮せずに、いわば汚染された UTF-8 を世の中に垂れ流すのは
言語道断ですし、汚染された UTF-8 (BMP 以外は6バイトで表現) に新しいエンコーディング名を
付けて世間に認めさせちゃおう、なんてのは馬鹿としか言いようがありません。
どちらかというと、サロゲートペアであれば悪夢、という言い方が残っていることに驚きました。
いわば税金を払うことを厭わしいという考え方の残存こそが、悪夢の前兆であるように思います。
Re: (スコア:1, 参考になる)
たとえばJavaのCharも16bitだし。
1文字の幅を固定長にしておかないと逆方向のカーソル移動とか、検索とかが甚だしく面倒になるので(どこかにどういう文字列クラスを書いておけ、というのはまあ置いておいて)。
VistaでJIS2004が採用されたときに調査したのですが、JISの第三水準、第四水準にはBMPに入らない文字があって、これがまともにサポート出来ていたのは一太郎ぐらいだったのに愕然としました(MSの製品もダメでした)。
またSunもBMP以外に文字が
Re:悪夢じゃね? (スコア:1)
> たとえばJavaのCharも16bitだし。
補助文字をサポートするようになったのはjava5からなのに、そんなことはないでしょう。
# …と思いたいだけかもしれない
Re: (スコア:0)
さておき。
メモリ使用量さえ気にしなければ、ASCII文化圏のプログラマと同じ気分でプログラムが書けるのですよ?
という気持ちになったプログラマ(というかデザイナ)は一杯居るのです。ここにはファーイーストのプログラマだけではなく、ファーイーストのプログラマにプログラミングをさせる環境をデザインしている側も含まれます。
Javaもそうだし、SymbianもTDesは実際問題16bit幅です。それから私が非常に詳しく知っている某アプリケーションのコードも1文字16bitルールで書いてます。
というかエンコ
固定長だと簡単? (スコア:1)
UTF-32 では全部の「文字」が同じ長さになるのですが、それだと何かプログラムを書く側にとって都合が良いのでしょうか。僕は、「文字が固定長だとプログラミングが簡単だ」というのは国際化されたアプリケーションの開発ではほぼ成り立たないのではないかと思っています。
例えば、 Unicode の文字は表示時のグリフとは必ずしも一対一に対応しないので、 UTF-32 であっても、 200 バイトの文字列を表示する場合に最初の 100 バイトと次の 100 バイトの 2 回に分けて表示するようなことは無条件にはできません。
別の例では、文字列の「先頭の 1 文字」で分類するような索引を作ろうとしても、人間にとっての「先頭の 1 文字」は Unicode で 1 個の文字とは限りません (合成文字等があるため)。なので、人間にとっての「1 文字」はメモリ上で常に 32 ビットになるわけではありません。
Re:悪夢じゃね? (スコア:1)
16Bitだったものが、Java5から32bitになっているのに、未だに16bitだと思ってる人は少ないんじゃないか
と言いたかったです。
charは16bitですが、codePointを32bit(int)で扱うように変わってます。
Re:悪夢じゃね? (スコア:1)
……って与太はおいといて、16bitあれば全世界の文字が収納できるなんて与太論文書いた馬鹿(Digitalの奴だっけ?)には、今更であっても良いから論文引っ込めてもらいたい。16bit空間なんて日本語の文字(二万六千文字ぐらいだったか?)と中国語(簡体字繁体字どちらかだけで四万文字ぐらいだったか?)の文字を全部入れただけで溢れてしまい、それ以外の文化圏の文字(alpha-numeric込み)を納めることすら出来なくなるのだから。
# って言うか、非欧米圏にどれだけの文字が存在するかきちんと調べようとしなかったのがそもそもの……
ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
Re: (スコア:0)
Re:固定長だと簡単? (スコア:1)
Unicodeの正規化でそのあたりは何とかなるんじゃないでしょうか。
"正規化形式 C"ってそれようにあるものだと思ってました。
Re:固定長だと簡単? (スコア:1)
確かに正規化形式 C (NFC) にすると、例えば a + umlaut が a umlaut という一つの文字になるように、多くの combining character sequence が合成済文字に変換されるので、グリフと一対一に対応することが増えるのですが、すべての combining character sequence が対応する合成済文字を持っているわけではないし、 Unicode 文字と表示上のグリフとが一対一に対応しないのは合成文字が関わる場合以外にリガチャーの場合もあるので (もっとほかにもあると思います)、 NFC にして解決するのは問題の一部です。
それはよくある誤解だと思います。極端な例ですが合成済文字を NFC にすると基底文字+合成文字に分解される場合もあります。 NFC で合成済文字にならない場合について詳しいことは、 Unicode Normalization Forms (Standand Annex #15) の 6 節「Composition Exclusion Table」 [unicode.org]を参照してください。