[PHP-dev 178] Re: [PATCH] multibyte patch for PHP 4.1.0

Masaki Fujimoto php-dev@php.gr.jp
Sun, 23 Dec 2001 23:31:23 +0900


ふじもとです。

On Sun, 23 Dec 2001 11:42:30 +0900
Rui Hirokawa <rui_hirokawa@ybb.ne.jp> wrote:

> 廣川です。

毎回、お世話になります...

# Optimizer関連の話は岡田様の方に返信しましたので省略します

> 一方、現行のZend Engine 1.xについては多少ad-hocなアプローチで
> あってもユーザの使い勝手が向上するならば受け入れられる余値はあると思います。
> Zend-1.xでのShift_JIS対応は、日本で短期的にもユーザ数を増やしたい
> Zend社の意向とも一致するわけで、受け入れられる余値は充分あると思います。
> 
> 世界的にみたらこの機能を使わないPHPユーザの方が圧倒的に多数派ですから
> そうしたユーザの使い勝手や性能を低下させずに機能をとりこめるのでしたら、
> 問題ないのではないのでしょうか。

そうですね。とりあえず現在のパッチはZEND_MULTIBYTEをdefineしなければ使い
勝手は全く変わりませんし、性能に関しても無視できる程度(パーサがencoding
ディレクティブをチェックするのみ <= パーサ関連の箇所は#ifdef出来ないので)
だと考えています。

> Zend-1.xではconfigureのオプションでマルチバイト対応でコンパイルした時にだけ
> 機能が有効となるような考え方で良いと思います。

そうですね。では、configureで--enable-multibyteが指定されたら
ZEND_MULTIBYTEが有効になるようにしてみようかと思います。それとも別の
configureオプションが良いでしょうか?あと、encodingに関しては「便利さ」
という観点からだとどう考えてもphp.iniを読みにいったほうが良さそうですね。

どのみち、個人的スケジュールでは29日くらいまでは実装できそうにないので皆
様の意見をお待ちしたいと思います。というわけでちょっとまとめてみました。

------------------------------------------------------------------------
(1) configureでの設定方法

- --enable-multibyteでZEND_MULTIBYTEとZendからphp.iniを読みに行く機能が
  共に有効になる。

- 別のconfigureオプションでZEND_MULTIBYTEとZendからphp.iniを読みに行く機
  能が共に有効になる。

- あるconfigureオプションでZEND_MULTIBYTEが有効になり、別のconfigureオプ
  ションでZendからphp.iniを読みに行く機能が共に有効になる。

が考えられますが、どれがよいでしょうか?


(2) Zend Engineのマルチバイト対応機能

現在のShift_JIS(等)対応機能の他に

- encoding指定省略時のエンコーディング自動判別機能
- encoding指定省略時にphp.iniのmbstring.script_encodingを読みに行く機能
  (もしくはencodingディレクティブを廃止してphp.iniのみを読みに行く?)
- php.iniのmbstring.internal_encodingを読んでエンコーディングの自動変換
  を行う機能

等が挙げられると思いますが、どれが必要でしょうか?(全部とか...)
------------------------------------------------------------------------

個人的にはZend Engineのスクリプトエンジン単体としての機能にも期待してい
るので、「Zend Engine単体への変更」と「『PHPで使用するZend Engine』への
変更」は区別して実装できれば、と考えています。

# と、言いつつZend Engineのマルチバイト対応に関しては、割り切って廣川さ
# んのおっしゃるようにad-hocなものにして上記の両者の区別はつけない、とい
# う手もありかとも思っています(そのほうが実装も使い勝手もシンプルになり
# ますし)。難しいですね。

> 一方、Zend Engine 2についても、できるだけ早く仕様案をまとめたいところです。
> 
> 個人的な考えですが、Zend Engine のローダに関して、
> スクリプトエンジンがスクリプトファイルのファイルIOといったシステムよりの
> 機能まで全面的に受け持つのはエンジンをアプリケーションやOSから独立させると
> いう観点からどうかと思います。
> むしろ、ローダの方は抽象化IOレベルにとどめておいて、
> 後はアプリケーション(ここではPHP)にシステムよりの処理をまかせる方が
> 良いのではないかと思っています。
> 逆にそうすれば、PHPアプリケーション側だけで機能を取りこむ余値が生まれます。
> 
> また、HTTP出力ハンドラみたいにローダにハンドラの機能を追加するというのも
> ありかと思います。
> 文字コード変換以外にも、例えば、セキュリティ上危険なPHPスクリプトコードを
> ローダレベルでrejectするということもできるようになるかもしれません。
> これもアプリケーション側(PHP)がどこかで割り込めるようにならないと
> 難しいのですが。
> 
> どちらにしてもこのレベルのコーディングは私の技術では困難なので、仕様案作成や
> デバッグ等に関して主に協力させていただきます。

僕にも困難ですが... このアイデアは面白いですね。やはり、何はともあれ仕様
を早いところ決めておきたいところです。Zend Engine 2対応に関しては別のス
レッドできっちり話し合ったほうが良いかもしれませんね。もしくはPHP新年会
とかを行ってその場でたたき台をつくるとか:D

上述のように、ちょっといそがしくてZend Engine 2に関してはたたき台となる
ようなパッチを作る暇もなさそうなので、まずは要件に関してだけでも詰められ
ると嬉しいかもしれません。大垣さんはEngine内部でinternal encodingを統一
した方が... といったことをおっしゃっていましたし(読み違えていたらすみま
せん>大垣様)

何はともあれ、この話も盛り上がってきたようなので本腰を入れて取り組んでみ
ようかと思っています。

--
藤本 真樹

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