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

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

  • by baka_gahaku (4542) on 2008年11月28日 17時12分 (#1463624) 日記
    うーん、提案段階のものにケチをつける趣味は無いのだけれども…

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

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

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

    A.「エンコード形式を UTF-8+emojiに設定してください 」
    とか
    A.「その書体は絵文字入って無いので、新しく買いなおしてください、○万円です」
    とか
    A.「その書体は、CID、Pro、Pr5、Pr6、Pr6+emoji の5種類あり、それぞれ値段が違います」
    とかなるんでしょう?

    正直、勘弁してほしい。
    せめて、HTMLでタグ指定か、CSSでの指定とか、そういう方向でどうにかしてほしい。

    でも実際に、そうなってしまったら、「ホニャララって書体の顔文字は感情表現が弱いが、その分視認性に優れている。丸ゴシックの従属書体だけあって、ガーリーな表現と意外にもあう」なんてしたり顔でコメントしてると思うけどね。
    • by Anonymous Coward on 2008年11月28日 17時37分 (#1463649)
      策定や提案されてるものをみたらいいよ。
      マージャン牌とかも普通にコードがふられているし。

      そもそも、ハングルでもキリルでもなんでもいいけど自分のシステムに無いフォントは今でも
      表示できないんだから、読みたい文章があれば合わせてフォントをインストールする
      しかないでしょ。
      親コメント
      • Re:悪夢じゃね? (スコア:2, おもしろおかしい)

        by Anonymous Coward on 2008年11月28日 18時55分 (#1463713)
        >マージャン牌とかも普通にコードがふられているし。

        おお!フォントさえインストールすればラムちゃんのママとも文通できるのか!
        親コメント
    • by Anonymous Coward on 2008年11月28日 17時48分 (#1463662)
      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はサロゲートペアの処理時に特殊な扱いをしなければならないのですが、正式な規格とはことなる独自規格もひろまっていますし(そのうち正式な規格に統一されるでしょうが)。
      内部表現もucs2(16bit/char)では足りなくなってしまいますので、変更が必要でしょう。

      現在の大半の「unicodeをなんとか使えるようになっている」ソフトは対応できないんじゃないでしょうか。

      悪夢となるか、unicode or ISO10646にしっかり準拠させるための強い動機付けとなるか…

      # 16ビットの空間に文字を全部いれることができなかった時点で個人的には充分悪夢だと思う。
      親コメント
      • by vn (10720) on 2008年11月29日 6時50分 (#1463963) 日記

        もし正式採用でもサロゲートペアであれば、悪夢です。
        サロゲートペアの処理というのは、UTF-16 を扱うときには必ず考慮しなければならない、
        税金のようなものです。考慮せずに、いわば汚染された UTF-8 を世の中に垂れ流すのは
        言語道断ですし、汚染された UTF-8 (BMP 以外は6バイトで表現) に新しいエンコーディング名を
        付けて世間に認めさせちゃおう、なんてのは馬鹿としか言いようがありません。

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

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

          VistaでJIS2004が採用されたときに調査したのですが、JISの第三水準、第四水準にはBMPに入らない文字があって、これがまともにサポート出来ていたのは一太郎ぐらいだったのに愕然としました(MSの製品もダメでした)。
          またSunもBMP以外に文字がある場合、一番簡単な作戦は1文字32bitにして処理をしろと言ってます。

          つうことで、結論。
          プログラマの我々としては、別に規約に従ってサロゲートペアの入ったエンコーディング(というか他人とのデータ交換)をやるのを恐れているのではありません。それは当然やるべき話です。
          そうではなくて、BMPに入らない文字を扱おうと思うとプログラムが色々作り直しになるだろうなあと思って恐れて(またはゲンナリして)いるのです。
          親コメント
          • by herewe (21291) on 2008年11月29日 20時25分 (#1464326) 日記
            > いやー、プログラムを書く側からすると、メモリ上の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 ビットになるわけではありません。

                親コメント
              • by herewe (21291) on 2008年11月30日 14時32分 (#1464617) 日記
                あ、勘違いさせてしまいました。
                16Bitだったものが、Java5から32bitになっているのに、未だに16bitだと思ってる人は少ないんじゃないか
                と言いたかったです。

                charは16bitですが、codePointを32bit(int)で扱うように変わってます。
                親コメント
              • by MISSION (13232) on 2008年12月05日 21時17分 (#1468373) 日記
                 やっとTRON codeが世界的に認められるのですね! おめでとう!

                 ……って与太はおいといて、16bitあれば全世界の文字が収納できるなんて与太論文書いた馬鹿(Digitalの奴だっけ?)には、今更であっても良いから論文引っ込めてもらいたい。16bit空間なんて日本語の文字(二万六千文字ぐらいだったか?)と中国語(簡体字繁体字どちらかだけで四万文字ぐらいだったか?)の文字を全部入れただけで溢れてしまい、それ以外の文化圏の文字(alpha-numeric込み)を納めることすら出来なくなるのだから。
                # って言うか、非欧米圏にどれだけの文字が存在するかきちんと調べようとしなかったのがそもそもの……
                --
                ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
                親コメント
              • by Anonymous Coward
                もう1文字256bitにして未来永劫どんなに文字が増えてもCharのサイズ増やさなくていいようにすればいいんじゃね?16x16のフォントサイズさえ変わらなければ大丈夫だよ。
              • >表示時のグリフとは必ずしも一対一に対応しない
                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]を参照してください。

                親コメント
          • by Anonymous Coward
            >メモリ上の1文字は16bitだと多くの人が固定的に思ってますよ。
            多くのプログラマは8bitだと思っているものだと……
            Javaの世界が特殊なんだと思ってたよ……
      • by Anonymous Coward
        代表的なところではMySQLが対応していませんね。
        つまりmixiもFacebookはてなも/.JもアメブロもMovableTypeもXOOPSもダメ。
        これはひどい
      • by Anonymous Coward
        ># 16ビットの空間に文字を全部いれることができなかった時点で個人的には充分悪夢だと思う。

        そういえば
        少し前の英語圏のプログラマが文字は8bit決めうちでいいじゃん。対応面倒だし。
        なんて感じでUTF-8ですら消極的な人も多かったねぇ。
        (今もいるか)

        悪夢かどうかはおいておいて、仕事で自社の対応が必要なら使わざるを得ないって感じじゃないですか?
      • by Anonymous Coward
        wgetで落としても、閲覧に時間がかかりました。イメージがいっぱいリンクしてるから。
        例示されてる絵文字は、キャリア三社で結構違ってるんですけど、これって漢字統合の再来みたいな気がする。

        # 仕様はスムースに決まるかもしれないが、実装は揉めるだろうなぁ。
      • by Anonymous Coward
        ハングルがあんなに無駄に場所をとらなければ。。。
      • by Anonymous Coward
        http://www.unicode.org/charts/PDF/U2600.pdf [unicode.org]
        安直な解法としては、ここらあたりの記号を絵文字に置き換えて表示するとか。
        \u005cがバックスラッシュでは無く、円記号で表示される延長で。

        いやまあどうせドミノや麻雀牌のようにサロゲートペア領域になるでしょうけど。
    • by ruto (17678) on 2008年11月28日 22時25分 (#1463836) 日記
      合成フォントにしたらいいじゃん。
      親コメント
    • by Anonymous Coward

      エンコードとキャラクタセットって別の概念ですよね。よく海外の人は混同されますけど。

最初のバージョンは常に打ち捨てられる。

処理中...