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

[Masaki Fujimoto]

ふじもとです。

忘れないうちに、昨日のミーティングのサマリを書いておきます。参加された皆
様、参加できなかった皆様の参考になれば幸いです。あまり集中できていなかっ
たところとかもあったりするので、補足訂正等お待ちしています。

--- ここから ---
議論(?)は、あるトピックをどなたかが提供されるとそれについて、様々なレイ
ヤの様々な意見が飛び交う、という感じで進んでいったような気がします。議論
というよりはbrain stormingに近かったような気がしますが。

以下に(覚えている範囲で)それらを適当に整理して、並べてみました(何方がど
のようなことをおっしゃったかまではちょっと覚えいてないので、その辺りの情
報は欠落しています。ご容赦ください)。

[シングルバイト圏のアプリケーションをマルチバイト環境でも問題なく使える
ような機構が欲しい]

例えば、PHP 4.2.0で追加されるmail()関数のオーバーロードのような仕組みに
よって、マルチバイトを意識しないで書かれたスクリプトが日本語(や韓国語、
中国語等)環境で、問題なく動作するようになって欲しい、という意見が出され
ました。

このリクエスト自体に関しては皆様異存は無いようにお見受けしましたが、その
実現方法に関する意見は千差万別でした。特に、例に挙がったstrlen()に関する
議論は良くも悪くも白熱しました。問題の根本はstrlen()関数が「バイト数をカ
ウント」するのと「文字数をカウント」する機能を兼ね備えてしまっていること
にあることは明白なのですが、

- PHP4との互換性を保ちつつ
- シングルバイト圏の人がなるべく違和感を感じないように
- 且つ上記機能を実現する

となると、様々な問題をはらむようです。このメールはあくまでレポートという
ことで、敢えて個人的意見は控えます。で、この問題を突き詰めていくと

- じゃ、内部エンコーディングはどしましょう？

に代表される低いレイヤに関する話題になってしまって話はますます混乱してし
まいました(僕が大いにその一因になってしまいましたが...反省してます)。

そういう訳で、strlen()やsubstr()のような関数をどうしようか、というのはな
かなか難しい問題だということは良く分かったので、次回は建設的な議論が出来
るように意見をまとめてこなければ、という点では意見が一致したと思います。


[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にも実装したいですね。


[その他]

その他、以下のような意見がありました。

- エンコーディング変換テーブルをダイナミックロード等の仕組みによって
  pluggableにしてはどうか？

- UCS-4等のwide characterを内部エンコーディングとするのは厳しいだろう

- UTF-8が現実的ではないか？(これに関連してアジアの各国語のエンコーディン
  グに関する貴重なお話がありました。)

- 内部エンコーディングはコンパイル時には決定したい
  とはいえ、(特に複数の国の)複数ユーザにホスティングすることを考えると、
  内部エンコーディングを可変にできるというのもメリットではある


[次回に向けて]

最後に、やはり少なくとももう1回集まって話を詰めたほうがよいのではないか、
と言うことになりました。できれば大垣さんにもいらしていただきたい、ダメな
ら電話でも、といった意見も:)

で、このまま集まって同じようなことが繰り返されても意味が無いので、それま
でに今日の集まりを踏まえて個人的に、できればMLで意見を詰めておくのが良い
のではないか、ということになりました(確か)。
--- ここまで ---

おおざっぱに、以上のような感じだと思います。改めて、ご参考になれば幸いで
す。

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

--
藤本 真樹

アストラザスタジオ
fujimoto@studio.co.jp
fujimoto@php.net