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

開発中の PHP 6、UTF-16 化に失敗。開発ブランチも 5.3 系に巻き戻し 」記事へのコメント

  • もう文字コードはUTF8でいいぢゃないって思う。
    膨大な血を流してUTF16にする利点ってあんまりないと思う。
    全部UTF8にしてUTF8を超高速に扱う方法をみんなで考えたほうが幸せになれる気がする。

    --
    by rti.
    • by Anonymous Coward on 2010年03月20日 15時32分 (#1736130)

      utf8は可変長なので。内部的に使うには仕組み上コストがでかすぎるのですよ。
      utf16は固定長なのでその辺りの問題がないので内部処理で使われる。
      その差は仕組み的なものから生まれるから、闇雲に方法とか言われても……

      親コメント
      • by gk-hyn (7889) on 2010年03月20日 15時45分 (#1736135)

        つ サロゲートペア

        いまどきUCS2ってなら、それはそれで反対しませんけど。

        親コメント
        • by Anonymous Coward

          つ無視

          # 規格なんて飾りです

      • by Anonymous Coward

        「超高速に扱う方法をみんなで考えたほうが」
        って下りからコストが高いことは承知の上だって意図を汲めない物ですかね…?

        多言語の文字コードの扱いが面倒な点はいつでも可変長だからです。
        固定長のコストパフォーマンスに目がくらんでUTF16を採用した結果がサロゲートペアやIVSだかなんだかの問題です。

        UTF32とか使わない限り、結局可変長の問題にはぶち当たるんですよ。

        だったら中途半端に固定長にして後で変な構造で可変長に対応するよりも、最初から全部可変長のまま高速化を狙った方がもしかしたら効率がいいかもしれないじゃないか。

        それに、仕組み的にコストがでかいから無理なんて考えは思考停止もいいところですよ。
        パイプライン的に扱うとか、ハードウェアでサポートしてみるとか、ライブラリ側に隠蔽可能な中間形式で扱うとか、考えようと思えば幾らでもネタは出てきます。
        そういったアイディアが実用的か否かはまた別の話だけれども、しょっぱなから否定してかかるのはどーなのかね?

アレゲはアレゲを呼ぶ -- ある傍観者

処理中...