パスワードを忘れた? アカウント作成
203242 story

開発中の PHP 6、UTF-16 化に失敗。開発ブランチも 5.3 系に巻き戻し 77

ストーリー by reo
決断には勇気を要したことだろう 部門より

ある Anonymous Coward 曰く、

PHP の次期メジャーバージョンと見られている PHP6 では、内部的には文字列をすべて UTF-16 で処理するという方針が決定していたのだが、これが頓挫した模様 (マイコミジャーナルの記事) 。

PHP 開発者である Johannes Schlüter 氏による 2010/3/12 付けのブログ記事、"Future of PHP 6" によれば、数カ月前から PHP のコア開発者の多くから「PHP エンジン内部を Unicode 化するというアプローチは正しくないのでは、最初からやり直したほうがよいのでは」という議論が行われていたらしい。

「処理系内部ではすべての文字を Unicode で処理する」というアプローチは Java や Ruby、Python、Perl などですでに採用されているのだが、PHP の開発者らの結論は「プログラムにおいてすべての入出力時に変換処理を行うのはパフォーマンスの点でよろしくなく、実装も複雑になり、後方互換性もなくなる。いっぽうで多くのユーザーが受ける恩恵は非常に小さい」とのことで、とりあえずは現在行われていた PHP エンジンの UTF-16 化はすべて白紙に戻されるようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • もうすべての文字にGUIDを割り当てて管理したらいいんじゃないですかね。
    文字は創造したり誤記が広まったりして進化してきたのでしょうから
    コンピュータ上でも皆が新しい文字をどんどん創造できるような仕組みが良い気がします。

  • http://itpro.nikkeibp.co.jp/article/COLUMN/20090223/325328/?ST=securit... [nikkeibp.co.jp] を見るに1.8まではバイト列、1.9はオブジェクト毎に指定可能となっているけど。
  • おまえが言うな (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2010年03月19日 13時06分 (#1735658)

    >後方互換性もなくなる
    PHPに後方互換性なんてあったの?

  • Perl は :utf8 を付けなければ後方互換性は保たれている実装なので、
    そう言う問題は出なかった。なので、後方互換性に失敗したってこと
    なんでしょう。

    現状でも、mb_convert_encoding しまくれば良いとも言えるので、
    ちょっとみっともないぐらい。PHPプログラマはそういう細かいことは
    気にしないってことだな。

    メールの扱いとかでも、すぐにencodeは混在しちゃうから、必ず
    使うことになるし。
    • by Anonymous Coward on 2010年03月19日 17時03分 (#1735780)

      LLの場合、バイト列と文字列がごっちゃになりがちで、実際Perlの:utf8はかなりバッドノウハウの温床になっていて使いにくいので、基本バイト列として扱って文字列として扱う時は関数使うか別途クラスを立ち上げろ、というのは相応に理にかなった対応だとは思います。
      UTF-16はサロゲートペア問題があるためUNICODEの内部表現としては今となっては必ずしもベストではなく、結局文字列表現として何文字か数えるのに専用関数で数えて下さいみたいなことになるなら、バイト列にUTF-8で突っ込んで専用関数で取り扱えばいいじゃん、というのは原始的ですが間違いは少ないと言えます。

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

    --
    by rti.
  • by Anonymous Coward on 2010年03月19日 12時32分 (#1735626)
    マニフェストどおりじゃなくていいんですか!
    • 技術的に無理だと言うなら仕方ないと思うが、スタンスが間違ってたと言う話になるなら、何でもっと早めにそれらについて討議しなかったのか?と感じる。結局無駄な時間を費やしてしまうことになる。 日頃から十分な議論を行うよう、今後に期待したい。
      • by firewheel (31280) on 2010年03月19日 14時35分 (#1735703)

        ソフトウエア開発は単純な組み立て作業ではなく複雑な設計作業そのものだから。
        設計作業が終わるまで見えてこない物というのはあるものです。

        って、いったい何度繰り返したらエライ人は理解してくれるようになるんだろう。

        親コメント
        • by Anonymous Coward on 2010年03月19日 15時55分 (#1735741)

          そうなんだよね。
          流れ作業にまで落ちた「製造」に該当するのはCDのプレスとかに
          なると思うんだけど、なかなか理解が得られない。

          親コメント
        • by Anonymous Coward

          あなたが技術職を引退し、あなた自身かその教え子が現場を掌握する立ち場を受け持ったときです。

      • えっと (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2010年03月19日 13時01分 (#1735653)

        基地移転問題の事ですか?

        親コメント
        • Re:えっと (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2010年03月19日 15時18分 (#1735726)
          ずっと討議はしてたんじゃないの? 野党だったから聞く耳持ってもらえなかっただけで。
          親コメント
      • これから UCS 正規化方式に切り替えるなら、UTF-16 ではなく UTF-32 を採用したほうがマシですかね。固定長ですし。
        現状で UTF-16 を採用するメリットって何も無いような…

        親コメント
        • by Anonymous Coward on 2010年03月19日 13時16分 (#1735668)

          UTF-32でも可変長が避けて通れない(日本に限ってもIVS [nikkeibp.co.jp]とか)なんていい加減常識になったと思ってたんだけど、なんでまだこんなこと言う人がいるの?

          親コメント
          • 合成文字もありますしね。簡単な文字列処理ならともかく、エディタ等では合成された文字を1文字として認識できないとまずいですから。

            大作:「立て、ジャイアントロボ!」
            GR:「ま゛っ」 ← U+309B : 独立した濁点
            GR:「ま゙っ」 ← U+3099 : 合成用濁点

            ブラウザ次第ではありますが、上記のGRの台詞をマウスで選択したとき、上は「ま」と濁点が別々の文字、下は1つの文字として扱われているはず。

            親コメント
            • by Anonymous Coward

              Windows7RC では Firefox/Chrome とも1文字として扱われるものの、「ま ゛」のように仮名と濁点の間に大きな空間が開きますね。まだまだ不完全な感じ。一方 IE8 は隣接するものの、今度は「っ」の上にはみ出して表示されるという不具合が。また選択すると「ま」のみが反転されて、濁点は消えてなくなります。そのままメモ帳に濁点つきでコピペできるところを見ると、文字通り濁点が仮想的なマス目からはみ出て描画されているのかも。ちなみにメモ帳での表示が一番自然に見えました。

            • by Anonymous Coward

              Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja; rv:1.9.3a4pre) Gecko/20100318 Minefield/3.7a4pre
              合字されました。

              Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja-JP-mac; rv:1.9.2) Gecko/20100115 Firefox/3.6
              合字されましたが、濁点は文字の左上につきました。

              Safari 4.0.5 (6531.22.7)
              合字されませんでした。

              • by Anonymous Coward
                > Safari 4.0.5 (6531.22.7)
                > 合字されませんでした。

                うちのSafari(同じversion)ではうまくいってます。
                何が違うんだろ。
          • by Anonymous Coward on 2010年03月19日 13時50分 (#1735682)

            http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1260 [xml.gr.jp]
            >  これだけPCの容量が大きくなったのだから32bitにしてもいいじゃないか、と
            > いう意見がありますが、これは一種の錯誤です。
            続きはリンク先をどうぞ。
            最近ではスマートフォンとかiPadとかネットブックとかの、PCよりメモリ要求が厳しい端末も無視できませんからなおさらですね(主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。これは理由のないことではありません)。
            UTF-32にしても固定長で処理が済むわけでは全然なく、メリットはありません。UTF-32だろうと(サロゲートペアを無視した)UCS-2だろうとWindows←→Mac OS X間のファイル共有を実装しようとするだけで文字合成(「タ,U+3099←→ダ」とか)の考慮は必須です。
            UTF-8やUTF-16は定義域をU+10FFFFまでに制限している限り1コードポイントのサイズが4バイトを超えることはありませんから、UTF-32はメモリの無駄遣いでしかありません。ISO/IEC 10646でもUnicodeとの相互運用性向上のため、U+10FFFFを超える範囲は「永久予約」とされました。

            親コメント
            • あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。

              > 主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。
              > これは理由のないことではありません

              これはそれぞれのエンコーディングを机上に並べて評価したと言うより、
              依存先のライブラリや、プロジェクトの起点が UTF-16 だったからという理由じゃないですかね。
              IE なら Windows、WebKit なら fork 元の KHTML の親プロジェクトの KDE、
              Firefox なら Mozilla Project と。
              どれも UTF-32 が生まれる前から存在するプロジェクトなので、まぁそうなりますよね。
              というか、UCS-2 時代から存在するコードからすると UTF-8 すら新参になるため、
              その資産を生かそうとすると UTF-16 以外選択肢にならなくなってしまうと。

              そういえば、JavaScript は所々に UTF-16 前提の仕様が入ってますね。

              親コメント
              • by Anonymous Coward

                > あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。
                でも__STDC_ISO_10646__は主流じゃなかったと思いますけど。
                まあ、
                >> 私の感想は「ああ、余裕のある組織なんだな」。お
                >> そらく余裕の無いところは意地でMacを使い続ける余裕はなく、お客さんが
                >> WindowsならWindowsにしないとやってられないのだろうな、と思いました。
                なんて書いてるような人だからWindows以外眼中に無いのは確かでしょうけど。本人は否定してますけど視点がものすごくWindowsに偏向してますから。
                > どれも UTF-32 が生まれる前から
                UCS-4は当時からあったのですからいくらなんでもその主張は無理があるでしょう。

          • いっそ全面固定長のUTF-128を…

            # zipでよく潰れそう

            親コメント
        • by Anonymous Coward

          現状で UTF-16 を採用するメリットって何も無いような…

          WindowsやMac OS X(Cocoa)と互換性が高くなるというメリットがあります。

      • by Anonymous Coward
        NHK夜9時の人の口調が頭に浮かぶのはわたしだけかなあ。
  • by Anonymous Coward on 2010年03月19日 13時01分 (#1735654)

    最初からUnicodeの言語はなんの問題もないわけだし、つまるところ後方互換性の問題の問題でしょ。
    「サニタイズ」なんて謎のジャーゴンが繁殖するタイプの言語に多くを求めてもしょうがない。
    # HTMLのcontentにはstringを使わず別の型を定義すりゃいいのに。

  • by Anonymous Coward on 2010年03月19日 14時12分 (#1735693)
    もしかして: ü 上位 2 件の検索結果
    と言われたよ
    • by Anonymous Coward

      RSSのdescriptionにそのまま入っていて、invalidなRSSになっています。
      RSSリーダがエラーになるので直してほしいです。

    • by Anonymous Coward
      PHP勉強してて、RSSリーダーつくるのにスラドのRSS使わせてもらってました。
      んで、simplexml_load_file()が失敗するので、なんでかなあと思ってたのですが…そういうことでしたか。
      ちなみに、こんなエラーがでております。

      Entity 'uump' not defined

      以上です。
  • by Anonymous Coward on 2010年03月19日 14時22分 (#1735696)

    過去のしがらみ(作ったときにはそれで問題ないけど)で後から苦労するのはコンピュータ業界の定番なので
    数年後の事を予測して困らない方式で作ってくれていればどれでもいいよ。

  • by Anonymous Coward on 2010年03月19日 15時51分 (#1735740)

    >いっぽうで多くのユーザーが受ける恩恵は非常に小さい

    開発人の脳内は
    ユーザー = 欧米1バイト文字圏ユーザー

    ってことかね。

    • by Anonymous Coward

      失礼な。

      ユーザー ≒ 欧米1バイト文字圏ユーザー

      ぐらいの認識はあるよ。たまにTシャツに「スーパーサイヤ人」と書きたくなったりするもん。

  • by Anonymous Coward on 2010年03月19日 17時54分 (#1735817)

    ちょっぴり安心した。

typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...