[PHP-dev 274] Re: PHP国際化ミーティングのサマリ

Sat, 30 Mar 2002 21:58:50 +0900

廣川です。

立派なサマリを作成して頂きありがとうございます。
当日は、そうそうたる面々に参加頂いたこともあり活発な議論が展開されたと
思います。
ただ、多様な意見がでたことでブレインストーミング的な議論となったことと、
とりまとめの私がまとめきれなかったせいもあり、開発者であるZeevに
明確なリクエストをだすところまでまとめきれませんでした。

PHP5の開発が進んでいることもありますので、リクエストを明確化する場として、
近日中に再度同様なミーティングを開催する予定です。


On Wed, 27 Mar 2002 23:55:31 +0900
Masaki Fujimoto <masaki-f@fides.dti.ne.jp> wrote:

> ふじもとです。
> 
> 忘れないうちに、昨日のミーティングのサマリを書いておきます。参加された皆
> 様、参加できなかった皆様の参考になれば幸いです。あまり集中できていなかっ
> たところとかもあったりするので、補足訂正等お待ちしています。
> 
> --- ここから ---
> 議論(?)は、あるトピックをどなたかが提供されるとそれについて、様々なレイ
> ヤの様々な意見が飛び交う、という感じで進んでいったような気がします。議論
> というよりはbrain stormingに近かったような気がしますが。
> 
> 以下に(覚えている範囲で)それらを適当に整理して、並べてみました(何方がど
> のようなことをおっしゃったかまではちょっと覚えいてないので、その辺りの情
> 報は欠落しています。ご容赦ください)。
> 
> [シングルバイト圏のアプリケーションをマルチバイト環境でも問題なく使える
> ような機構が欲しい]
> 
> 例えば、PHP 4.2.0で追加されるmail()関数のオーバーロードのような仕組みに
> よって、マルチバイトを意識しないで書かれたスクリプトが日本語(や韓国語、
> 中国語等)環境で、問題なく動作するようになって欲しい、という意見が出され
> ました。
> 
> このリクエスト自体に関しては皆様異存は無いようにお見受けしましたが、その
> 実現方法に関する意見は千差万別でした。特に、例に挙がったstrlen()に関する
> 議論は良くも悪くも白熱しました。問題の根本はstrlen()関数が「バイト数をカ
> ウント」するのと「文字数をカウント」する機能を兼ね備えてしまっていること
> にあることは明白なのですが、
> 
> - PHP4との互換性を保ちつつ
> - シングルバイト圏の人がなるべく違和感を感じないように
> - 且つ上記機能を実現する
> 
> となると、様々な問題をはらむようです。このメールはあくまでレポートという
> ことで、敢えて個人的意見は控えます。で、この問題を突き詰めていくと
> 
> - じゃ、内部エンコーディングはどしましょう？
> 
> に代表される低いレイヤに関する話題になってしまって話はますます混乱してし
> まいました(僕が大いにその一因になってしまいましたが...反省してます)。
> 
> そういう訳で、strlen()やsubstr()のような関数をどうしようか、というのはな
> かなか難しい問題だということは良く分かったので、次回は建設的な議論が出来
> るように意見をまとめてこなければ、という点では意見が一致したと思います。

本件に関して、当日、Zeevが言ってたのは、
「strlen()は文字数を調べるという目的以外にバイト数を調べる目的で使用されているコードが存在する。文字数を調べる関数を別に作った方が良いのではないか?」
という意見でした。
実際に英語圏のアプリケーションではそのような2種類の目的でstrlen()が
使用されており、移植の際には問題を発生する可能性は高いと言えます。

  個人的には既存のアプリケーションでも混用しており機械的な判別は難しいため、
時間をかけて使い方をわけていくしかないのではないかと思います。

具体的には、
1.当面はstrlen()に関しては現在の機能をそのまま残す。
2.バイト長を返すPHP関数(bytelen()なりblength())を定義する。
3.バイト長についてはこの新しい関数を使用するよう説得する。
4.strlen()を文字列長を返す関数にし、マルチバイト文字に対応する。
という感じになります。

より強行にいくなら、
1.バイト長を返すPHP関数(bytelen()なりblength())を定義する。
2.バイト長についてはこの新しい関数を使用するよう説得する。
3.strlen()を文字列長を返す関数にし、マルチバイト文字に対応する。
ですが、これはシングルバイト圏の人になかなか受け入れがたいものがあるでしょう。
  ただ、Zeevも言っていましたが、strlenは文字列関数の中の特殊な例で、
strchrのような他の文字列関数については、プログラマは文字列用関数で
あることを認識して使用しているため、マルチバイト対応に際して問題は
起きにくいだろうということでした。

> 
> 
> [PHP3, PHP4との互換性を保ちたい]
> 
> 要はPHP5でどんな国際化が行われるにせよ、PHP3やPHP4のアプリケーションはな
> るべくそのまま動いて欲しい、ということです。
> 
> とはいっても、国際化とは関係ない箇所で(特にクラス周り)互換性が結構失われ
> ることが確実っぽいので(コンストラクタの名称が__constructorに統一されたり
> とか)、もう既に100%の互換性の保持は無理、というのがちょっと悲しいですね。
> 多分PHP3 → PHP4より移植は面倒になるかと思います。
> 
> このリクエストに関しては1番目のリクエストとも噛むので、やはりもう少し詰
> める必要があるでしょう。

互換性は非常に重要な点ですので、できるだけユーザ向けのインターフェイスは
維持する方向で考えたいと思います。

> 
> 
> [スクリプトエンコーディングの指定はphp.ini → php_value → encodingディ
> レクティブ(優先度順)で指定したい]
> 
> これに関してはPHP3国際化版や、僕の作ったパッチとほぼ同様なので特に問題は
> ないかと思います。ちなみに、encodingディレクティブに関してZeevが(現在既
> にZend Engineに組み込まれているdeclareディレクティブを使用して実装する例
> をその場で実装して見せてくれました。
> 
> ただ、ワイドキャラクタを使用して記述されたスクリプトはencodingディレクティ
> ブのパースにたどりつく前にエラーになってしまう、という問題があります。こ
> れに関しては、
> 
> - 現在ワイドキャラクタでスクリプトを書くことはほとんど無いので気にしても
>   仕方ないのではないか
> - 最初の数バイトを読み込んで0x00が有ったらワイドキャラクタを使用している
>   と判断して適宜対応(エンコーディングスキームを自動判別してUTF-8に変換?
>   等)してはどうか
> 
> といった意見が出されました。
> 
> # UCS-4, UCS-2 BE/LEの判別は問題ないとして、UTF-16やUTF-32も含めて自動判
> # 別は可能なのでしょうか？サロゲートペア周辺のスキームは不勉強なので良く
> # 分かっていません。もし可能ならPHP4にも実装したいですね。

個人的には、PHPスクリプトのワイドキャラクター対応に関しては、明確な
ニーズを持たれている方が少ないという認識ですので、他の作業を優先した
方が良いのではないかと思っています。

判別については、FAQ UTF and BOM によると、
http://www.unicode.org/unicode/faq/utf_bom.html

Bytes  Encoding Form    
00 00 FE FF  UTF-32, big-endian    
FF FE 00 00  UTF-32, little-endian    
FE FF  UTF-16, big-endian    
FF FE  UTF-16, little-endian    
EF BB BF  UTF-8

となっていますのできちんとした実装のファイルならBOMである程度判別できるのでは
ないかと思います。
サロゲートペアについては私も知識がないため分りません。

> 
> 
> [その他]
> 
> その他、以下のような意見がありました。
> 
> - エンコーディング変換テーブルをダイナミックロード等の仕組みによって
>   pluggableにしてはどうか？
> 
> - UCS-4等のwide characterを内部エンコーディングとするのは厳しいだろう
> 
> - UTF-8が現実的ではないか？(これに関連してアジアの各国語のエンコーディン
>   グに関する貴重なお話がありました。)
> 
> - 内部エンコーディングはコンパイル時には決定したい
>   とはいえ、(特に複数の国の)複数ユーザにホスティングすることを考えると、
>   内部エンコーディングを可変にできるというのもメリットではある
> 

この辺も意見が分れるところでした。どれが正解という話ではないため
難しいところです。

> 
> [次回に向けて]
> 
> 最後に、やはり少なくとももう1回集まって話を詰めたほうがよいのではないか、
> と言うことになりました。できれば大垣さんにもいらしていただきたい、ダメな
> ら電話でも、といった意見も:)
> 
> で、このまま集まって同じようなことが繰り返されても意味が無いので、それま
> でに今日の集まりを踏まえて個人的に、できればMLで意見を詰めておくのが良い
> のではないか、ということになりました(確か)。
> --- ここまで ---
> 
> おおざっぱに、以上のような感じだと思います。改めて、ご参考になれば幸いで
> す。

  私は、Zend Engine のAPIレベルでのマルチバイト文字のサポートが行われることが
中長期的に望ましい方向だと考えています。
  これについては、マルチバイトサポート機能を追加する人に
ミーティングの席でZeevからZend Engine 2の開発用CVSアカウントを
発行するという提案がだされています。
  既にPHPのCVSアカウントをお持ちの方+アルファの中で作業を行うことに
なるかと思いますが、仕様が固まった段階でプロトタイプレベルのものを早期に
作っていく必要があるでしょう。

> 
> # 今日のZeevの講演聴きたかった... 内容が気になります

休暇をとってZeevの講演を聞きに行って来ました。
(おかげでというわけではありませんが、今週の後半は本業で詰んでいました。(^_^))
講演そのものは、PHPの歴史とPHP5のクラスを中心とした新機能に関するものでした。
Zend Studioを使ってのデモを交えながら解説が行われ、なかなか
わかりやすいものでした。
ちなみに当日の参加者は400名ほどで、Zeevのコメントでは、PHPのみを
テーマとしたセッションの中で世界最大だったということでした。

当日の講演で紹介されたPHP 5機能に文字列中の文字に関して、
$a{4}
 というような記法が新たに採用されるというものがありました。
この機能は、マルチバイト文字サポートを欠いた状態では、
日本のユーザに混乱を招く可能性があると思います。
後の懇親会の席でZeevにそのことを言ったところ、Zend Engineのレベルでマルチバイト文字を
サポートすることはできるだろうということでした。


-- 
-----------------------------------------------------
Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
             <hirokawa@php.net>