確かに正規化形式 C (NFC) にすると、例えば a + umlaut が a umlaut という一つの文字になるように、多くの combining character sequence が合成済文字に変換されるので、グリフと一対一に対応することが増えるのですが、すべての combining character sequence が対応する合成済文字を持っているわけではないし、 Unicode 文字と表示上のグリフとが一対一に対応しないのは合成文字が関わる場合以外にリガチャーの場合もあるので (もっとほかにもあると思います)、 NFC にして解決するのは問題の一部です。
悪夢じゃね？ (スコア:1)
新しくユニコードに含める、ってことは、書体の（フォントファイルの）中に入るって話だよね。
そうすると、絵文字に対応した書体と対応してない書体が世の中で入り乱れたりすると。
Q.「送られてきたメールの文字がソフトバンクのマークになります」
A.「書体を変更してください」
見たいな文章がそこここにあふれることになるんでしょう？
A.「エンコード形式を UTF-8+emojiに設定してください 」
とか
A.「その書体は絵文字入って無いので、新しく買いなおしてください、○万円です」
とか
A.「その書体は、CID、Pro、Pr5、Pr6、Pr6+emoji の5種類あり、それぞれ値段が違います」
とかなるんでしょう？
正直、勘弁してほしい。
せめて、HTMLでタグ指定か、CSSでの指定とか、そういう方向でどうにかしてほしい。
でも実際に、そうなってしまったら、「ホニャララって書体の顔文字は感情表現が弱いが、その分視認性に優れている。丸ゴシックの従属書体だけあって、ガーリーな表現と意外にもあう」なんてしたり顔でコメントしてると思うけどね。
Re:悪夢じゃね？ (スコア:2, 興味深い)
マージャン牌とかも普通にコードがふられているし。
そもそも、ハングルでもキリルでもなんでもいいけど自分のシステムに無いフォントは今でも
表示できないんだから、読みたい文章があれば合わせてフォントをインストールする
しかないでしょ。
Re:悪夢じゃね？ (スコア:2, おもしろおかしい)
おお！フォントさえインストールすればラムちゃんのママとも文通できるのか！
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はサロゲートペアの処理時に特殊な扱いをしなければならないのですが、正式な規格とはことなる独自規格もひろまっていますし(そのうち正式な規格に統一されるでしょうが)。
内部表現もucs2(16bit/char)では足りなくなってしまいますので、変更が必要でしょう。
現在の大半の「unicodeをなんとか使えるようになっている」ソフトは対応できないんじゃないでしょうか。
悪夢となるか、unicode or ISO10646にしっかり準拠させるための強い動機付けとなるか…
# 16ビットの空間に文字を全部いれることができなかった時点で個人的には充分悪夢だと思う。
Re:悪夢じゃね？ (スコア:1)
税金のようなものです。考慮せずに、いわば汚染された UTF-8 を世の中に垂れ流すのは
言語道断ですし、汚染された UTF-8 (BMP 以外は6バイトで表現) に新しいエンコーディング名を
付けて世間に認めさせちゃおう、なんてのは馬鹿としか言いようがありません。
どちらかというと、サロゲートペアであれば悪夢、という言い方が残っていることに驚きました。
いわば税金を払うことを厭わしいという考え方の残存こそが、悪夢の前兆であるように思います。
Re:悪夢じゃね？ (スコア:1, 参考になる)
たとえばJavaのCharも16bitだし。
１文字の幅を固定長にしておかないと逆方向のカーソル移動とか、検索とかが甚だしく面倒になるので（どこかにどういう文字列クラスを書いておけ、というのはまあ置いておいて）。
VistaでJIS2004が採用されたときに調査したのですが、JISの第三水準、第四水準にはBMPに入らない文字があって、これがまともにサポート出来ていたのは一太郎ぐらいだったのに愕然としました（MSの製品もダメでした）。
またSunもBMP以外に文字がある場合、一番簡単な作戦は１文字32bitにして処理をしろと言ってます。
つうことで、結論。
プログラマの我々としては、別に規約に従ってサロゲートペアの入ったエンコーディング（というか他人とのデータ交換）をやるのを恐れているのではありません。それは当然やるべき話です。
そうではなくて、BMPに入らない文字を扱おうと思うとプログラムが色々作り直しになるだろうなあと思って恐れて（またはゲンナリして）いるのです。
Re:悪夢じゃね？ (スコア:1)
> たとえばJavaのCharも16bitだし。
補助文字をサポートするようになったのはjava5からなのに、そんなことはないでしょう。
# …と思いたいだけかもしれない
Re: (スコア:0)
さておき。
メモリ使用量さえ気にしなければ、ASCII文化圏のプログラマと同じ気分でプログラムが書けるのですよ？
という気持ちになったプログラマ（というかデザイナ）は一杯居るのです。ここにはファーイーストのプログラマだけではなく、ファーイーストのプログラマにプログラミングをさせる環境をデザインしている側も含まれます。
Javaもそうだし、SymbianもTDesは実際問題16bit幅です。それから私が非常に詳しく知っている某アプリケーションのコードも１文字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]を参照してください。
Re: (スコア:0)
多くのプログラマは8bitだと思っているものだと……
Javaの世界が特殊なんだと思ってたよ……
Re: (スコア:0)
つまりmixiもFacebookはてなも/.JもアメブロもMovableTypeもXOOPSもダメ。
これはひどい
Re:悪夢じゃね？ (スコア:2, 参考になる)
http://dev.mysql.com/doc/refman/6.0/en/charset-unicode.html [mysql.com]
Re: (スコア:0)
「MySQL4.1の文字コードの悪夢再び」ってことにならなければ良いのじゃが。。。
Re: (スコア:0)
そういえば
少し前の英語圏のプログラマが文字は8bit決めうちでいいじゃん。対応面倒だし。
なんて感じでUTF-8ですら消極的な人も多かったねぇ。
(今もいるか)
悪夢かどうかはおいておいて、仕事で自社の対応が必要なら使わざるを得ないって感じじゃないですか？
Re: (スコア:0)
例示されてる絵文字は、キャリア三社で結構違ってるんですけど、これって漢字統合の再来みたいな気がする。
# 仕様はスムースに決まるかもしれないが、実装は揉めるだろうなぁ。
Re: (スコア:0)
Re: (スコア:0)
安直な解法としては、ここらあたりの記号を絵文字に置き換えて表示するとか。
\u005cがバックスラッシュでは無く、円記号で表示される延長で。
いやまあどうせドミノや麻雀牌のようにサロゲートペア領域になるでしょうけど。
Re:悪夢じゃね？ (スコア:1)
Re: (スコア:0)
エンコードとキャラクタセットって別の概念ですよね。よく海外の人は混同されますけど。