パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

携帯絵文字のUnicode化、Googleも協力」記事へのコメント

  • うーん、提案段階のものにケチをつける趣味は無いのだけれども…

    新しくユニコードに含める、ってことは、書体の(フォントファイルの)中に入るって話だよね。
    そうすると、絵文字に対応した書体と対応してない書体が世の中で入り乱れたりすると。

    Q.「送られてきたメールの文字がソフトバンクのマークになります」
    A.「書体を変更してください」

    見たいな文章がそこここにあふれることになるんでしょう?

    A.「エンコード形式を UTF-8+emojiに設定してください 」
    とか
    A.「その書体は絵文字入って無いので、新しく買いなおしてください、○万円です」
    とか
    A.「
    • Re: (スコア:1, 興味深い)

      by Anonymous Coward
      unicode.orgのWGがだした対応表(巨大なので注意)
      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はサロゲートペアの処理時に特殊な扱いをしなければならないのですが、正式な規格とはことなる独自規格もひろまっていますし(そのうち正式な規格に統一されるで
      • もし正式採用でもサロゲートペアであれば、悪夢です。
        サロゲートペアの処理というのは、UTF-16 を扱うときには必ず考慮しなければならない、
        税金のようなものです。考慮せずに、いわば汚染された UTF-8 を世の中に垂れ流すのは
        言語道断ですし、汚染された UTF-8 (BMP 以外は6バイトで表現) に新しいエンコーディング名を
        付けて世間に認めさせちゃおう、なんてのは馬鹿としか言いようがありません。

        どちらかというと、サロゲートペアであれば悪夢、という言い方が残っていることに驚きました。
        いわば税金を払うことを厭わしいという考え方の残存こそが、悪夢の前兆であるように思います。
        • Re: (スコア:1, 参考になる)

          by Anonymous Coward
          いやー、プログラムを書く側からすると、メモリ上の1文字は16bitだと多くの人が固定的に思ってますよ。
          たとえばJavaのCharも16bitだし。
          1文字の幅を固定長にしておかないと逆方向のカーソル移動とか、検索とかが甚だしく面倒になるので(どこかにどういう文字列クラスを書いておけ、というのはまあ置いておいて)。

          VistaでJIS2004が採用されたときに調査したのですが、JISの第三水準、第四水準にはBMPに入らない文字があって、これがまともにサポート出来ていたのは一太郎ぐらいだったのに愕然としました(MSの製品もダメでした)。
          またSunもBMP以外に文字が
          • > いやー、プログラムを書く側からすると、メモリ上の1文字は16bitだと多くの人が固定的に思ってますよ。
            > たとえばJavaのCharも16bitだし。
            補助文字をサポートするようになったのはjava5からなのに、そんなことはないでしょう。

            # …と思いたいだけかもしれない
            • by Anonymous Coward
              えーと、Javaの文字は最初っから16bit幅だと思うのですが。

              さておき。
              メモリ使用量さえ気にしなければ、ASCII文化圏のプログラマと同じ気分でプログラムが書けるのですよ?
              という気持ちになったプログラマ(というかデザイナ)は一杯居るのです。ここにはファーイーストのプログラマだけではなく、ファーイーストのプログラマにプログラミングをさせる環境をデザインしている側も含まれます。

              Javaもそうだし、SymbianもTDesは実際問題16bit幅です。それから私が非常に詳しく知っている某アプリケーションのコードも1文字16bitルールで書いてます。

              というかエンコ
              • UTF-32 では全部の「文字」が同じ長さになるのですが、それだと何かプログラムを書く側にとって都合が良いのでしょうか。僕は、「文字が固定長だとプログラミングが簡単だ」というのは国際化されたアプリケーションの開発ではほぼ成り立たないのではないかと思っています。

                例えば、 Unicode の文字は表示時のグリフとは必ずしも一対一に対応しないので、 UTF-32 であっても、 200 バイトの文字列を表示する場合に最初の 100 バイトと次の 100 バイトの 2 回に分けて表示するようなことは無条件にはできません。

                別の例では、文字列の「先頭の 1 文字」で分類するような索引を作ろうとしても、人間にとっての「先頭の 1 文字」は Unicode で 1 個の文字とは限りません (合成文字等があるため)。なので、人間にとっての「1 文字」はメモリ上で常に 32 ビットになるわけではありません。

              • >表示時のグリフとは必ずしも一対一に対応しない
                Unicodeの正規化でそのあたりは何とかなるんじゃないでしょうか。
                "正規化形式 C"ってそれようにあるものだと思ってました。
              • >表示時のグリフとは必ずしも一対一に対応しない
                Unicodeの正規化でそのあたりは何とかなるんじゃないでしょうか。

                確かに正規化形式 C (NFC) にすると、例えば a + umlaut が a umlaut という一つの文字になるように、多くの combining character sequence が合成済文字に変換されるので、グリフと一対一に対応することが増えるのですが、すべての combining character sequence が対応する合成済文字を持っているわけではないし、 Unicode 文字と表示上のグリフとが一対一に対応しないのは合成文字が関わる場合以外にリガチャーの場合もあるので (もっとほかにもあると思います)、 NFC にして解決するのは問題の一部です。

                "正規化形式 C"ってそれようにあるものだと思ってました。

                それはよくある誤解だと思います。極端な例ですが合成済文字を NFC にすると基底文字+合成文字に分解される場合もあります。 NFC で合成済文字にならない場合について詳しいことは、 Unicode Normalization Forms (Standand Annex #15) の 6 節「Composition Exclusion Table」 [unicode.org]を参照してください。

                親コメント

身近な人の偉大さは半減する -- あるアレゲ人

処理中...