開発中の 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 化はすべて白紙に戻されるようだ。
めんどくさいね (スコア:2)
もうすべての文字にGUIDを割り当てて管理したらいいんじゃないですかね。
文字は創造したり誤記が広まったりして進化してきたのでしょうから
コンピュータ上でも皆が新しい文字をどんどん創造できるような仕組みが良い気がします。
Re:めんどくさいね (スコア:1)
ISO/IEC 10036 (JIS X 4165)で登録してるグリフと識別番号が、そんな感じじゃなかったでしたっけ?
Ruby の内部エンコーディング (スコア:1)
Rubyが内部すべてUnicode? (スコア:0, フレームのもと)
あのCSI派のすくつ(←なぜか変換できない)がいつの間にUnicode化されたんでしょうか。はつみみです。
と思ったらアレたま中に既出だったので、タレコミ人と編集者はRuby M17N の設計と実装 [rubyist.net]でも一億回読み返せ。
Re:Rubyが内部すべてUnicode? (スコア:1, 参考になる)
Tokyo Ruby Kaigi のなるせさんのビデオ [ustream.tv]もいいよ。
それにしてもCSIで良く頑張ってるなぁと思う。 かなり大変だと思うんだけど。
Re: (スコア:0, オフトピック)
「巣窟(そうくつ)」
変換できないってネタだよね?
Re:Rubyが内部すべてUnicode? (スコア:1)
2chのネタですね。
○○(←何故か変換できない)【なぜかへんかんできない】[成句] [media-k.co.jp]
Re: (スコア:0)
# とはいえ、巣窟とす(ryでは既に微妙に意味(ニュアンス)が違ってきているような気がしないでもない。
# 言葉って生き物ですねぇ。
おまえが言うな (スコア:1, おもしろおかしい)
>後方互換性もなくなる
PHPに後方互換性なんてあったの?
Re:おまえが言うな (スコア:1)
ある程度はありますよ。そりゃ。
Re:おまえが言うな (スコア:1)
アプリよりは、ライブラリ実装の制約かもしれない。
Re: (スコア:0)
むしろ邪魔な互換性が一杯ある。
当面、ライブラリレベルでやれってことね (スコア:1)
そう言う問題は出なかった。なので、後方互換性に失敗したってこと
なんでしょう。
現状でも、mb_convert_encoding しまくれば良いとも言えるので、
ちょっとみっともないぐらい。PHPプログラマはそういう細かいことは
気にしないってことだな。
メールの扱いとかでも、すぐにencodeは混在しちゃうから、必ず
使うことになるし。
Re:当面、ライブラリレベルでやれってことね (スコア:2, 参考になる)
LLの場合、バイト列と文字列がごっちゃになりがちで、実際Perlの:utf8はかなりバッドノウハウの温床になっていて使いにくいので、基本バイト列として扱って文字列として扱う時は関数使うか別途クラスを立ち上げろ、というのは相応に理にかなった対応だとは思います。
UTF-16はサロゲートペア問題があるためUNICODEの内部表現としては今となっては必ずしもベストではなく、結局文字列表現として何文字か数えるのに専用関数で数えて下さいみたいなことになるなら、バイト列にUTF-8で突っ込んで専用関数で取り扱えばいいじゃん、というのは原始的ですが間違いは少ないと言えます。
UTF8でいいぢゃない。 (スコア:1)
もう文字コードはUTF8でいいぢゃないって思う。
膨大な血を流してUTF16にする利点ってあんまりないと思う。
全部UTF8にしてUTF8を超高速に扱う方法をみんなで考えたほうが幸せになれる気がする。
by rti.
Re:UTF8でいいぢゃない。 (スコア:1)
速度的には理論的にはUTF16が速いとは思うが、あんまり関係ないしね。
Re:UTF8でいいぢゃない。 (スコア:1)
つ サロゲートペア
いまどきUCS2ってなら、それはそれで反対しませんけど。
Re:UTF8でいいぢゃない。 (スコア:1)
んじゃ、この文書の100万文字目を取ってきてくれ。
# 解決は無理な問題もあると思うぞ。
# UTF-8のコーディング自体に手を入れないでは
MANIFESTO (スコア:0)
思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:0)
「ソフトウエア設計とはなにか」 (スコア:2, すばらしい洞察)
ソフトウエア開発は単純な組み立て作業ではなく複雑な設計作業そのものだから。
設計作業が終わるまで見えてこない物というのはあるものです。
って、いったい何度繰り返したらエライ人は理解してくれるようになるんだろう。
Re:「ソフトウエア設計とはなにか」 (スコア:2, すばらしい洞察)
そうなんだよね。
流れ作業にまで落ちた「製造」に該当するのはCDのプレスとかに
なると思うんだけど、なかなか理解が得られない。
Re: (スコア:0)
あなたが技術職を引退し、あなた自身かその教え子が現場を掌握する立ち場を受け持ったときです。
えっと (スコア:1, すばらしい洞察)
基地移転問題の事ですか?
Re:えっと (スコア:1, すばらしい洞察)
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:1)
これから UCS 正規化方式に切り替えるなら、UTF-16 ではなく UTF-32 を採用したほうがマシですかね。固定長ですし。
現状で UTF-16 を採用するメリットって何も無いような…
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:3, 参考になる)
UTF-32でも可変長が避けて通れない(日本に限ってもIVS [nikkeibp.co.jp]とか)なんていい加減常識になったと思ってたんだけど、なんでまだこんなこと言う人がいるの?
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:5, 参考になる)
合成文字もありますしね。簡単な文字列処理ならともかく、エディタ等では合成された文字を1文字として認識できないとまずいですから。
ブラウザ次第ではありますが、上記のGRの台詞をマウスで選択したとき、上は「ま」と濁点が別々の文字、下は1つの文字として扱われているはず。
Re: (スコア:0)
Windows7RC では Firefox/Chrome とも1文字として扱われるものの、「ま ゛」のように仮名と濁点の間に大きな空間が開きますね。まだまだ不完全な感じ。一方 IE8 は隣接するものの、今度は「っ」の上にはみ出して表示されるという不具合が。また選択すると「ま」のみが反転されて、濁点は消えてなくなります。そのままメモ帳に濁点つきでコピペできるところを見ると、文字通り濁点が仮想的なマス目からはみ出て描画されているのかも。ちなみにメモ帳での表示が一番自然に見えました。
Re: (スコア:0)
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)
合字されませんでした。
Re: (スコア:0)
> 合字されませんでした。
うちのSafari(同じversion)ではうまくいってます。
何が違うんだろ。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:2, 参考になる)
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を超える範囲は「永久予約」とされました。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:2)
あれ、リンク先、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 前提の仕様が入ってますね。
Re: (スコア:0)
> あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。
でも__STDC_ISO_10646__は主流じゃなかったと思いますけど。
まあ、
>> 私の感想は「ああ、余裕のある組織なんだな」。お
>> そらく余裕の無いところは意地でMacを使い続ける余裕はなく、お客さんが
>> WindowsならWindowsにしないとやってられないのだろうな、と思いました。
なんて書いてるような人だからWindows以外眼中に無いのは確かでしょうけど。本人は否定してますけど視点がものすごくWindowsに偏向してますから。
> どれも UTF-32 が生まれる前から
UCS-4は当時からあったのですからいくらなんでもその主張は無理があるでしょう。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:2)
いっそ全面固定長のUTF-128を…
# zipでよく潰れそう
Re: (スコア:0)
現在Unicodeには「か」と合成済みの「が」と濁点が3種類も(合成用のU+3099、合成済みのU+309B、半角濁点)入ってますけど、これは正規化などの「問題」を引き起こすとしてむしろ非難されてますよね。ハングルも合成済みのと「合理的な」組み合わせ式のとKS X 1001互換用の3種類入ってました。
どうして単純にビット数を増やして何でもかんでも固定長に突っ込めばすべてが解決するという単純な頭の人が後を絶たないのか本当に不思議でなりません。すごい文字コード [srad.jp]でも使っててください。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:2)
固定長であることとは関係しないのでは? たとえばUTF-32を一文字64bitの、余りは0埋めした固定長として扱う、とか。
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは? (スコア:1)
Re: (スコア:0)
WindowsやMac OS X(Cocoa)と互換性が高くなるというメリットがあります。
Re: (スコア:0)
つまるところ後方互換性 (スコア:0)
最初からUnicodeの言語はなんの問題もないわけだし、つまるところ後方互換性の問題の問題でしょ。
「サニタイズ」なんて謎のジャーゴンが繁殖するタイプの言語に多くを求めてもしょうがない。
# HTMLのcontentにはstringを使わず別の型を定義すりゃいいのに。
&uump;をググッたら (スコア:0)
と言われたよ
Re: (スコア:0)
RSSのdescriptionにそのまま入っていて、invalidなRSSになっています。
RSSリーダがエラーになるので直してほしいです。
Re: (スコア:0)
んで、simplexml_load_file()が失敗するので、なんでかなあと思ってたのですが…そういうことでしたか。
ちなみに、こんなエラーがでております。
Entity 'uump' not defined
以上です。
文字コード (スコア:0)
過去のしがらみ(作ったときにはそれで問題ないけど)で後から苦労するのはコンピュータ業界の定番なので
数年後の事を予測して困らない方式で作ってくれていればどれでもいいよ。
はぁ (スコア:0)
>いっぽうで多くのユーザーが受ける恩恵は非常に小さい
開発人の脳内は
ユーザー = 欧米1バイト文字圏ユーザー
ってことかね。
Re: (スコア:0)
失礼な。
ユーザー ≒ 欧米1バイト文字圏ユーザー
ぐらいの認識はあるよ。たまにTシャツに「スーパーサイヤ人」と書きたくなったりするもん。
良かった、グダグダは日本だけじゃないんだ! (スコア:0)
ちょっぴり安心した。
Re:良かった、グダグダは日本だけじゃないんだ! (スコア:1, おもしろおかしい)
Re:良かった、グダグダは日本だけじゃないんだ! (スコア:1)
最初の決断が間違いだった、ってことを、それなりの労力を、期間を払った後に認めないといけないわけだから。
これができずに、最初の決断の正当性を主張し、ぐだぐだなものを気合や精神論で無理やり乗り切る方が実際多いんじゃない?