[PHP-dev 820]Re: zend-multibyteサポートの危機？

[Seiji Masugata]

桝形です。

> ここまでくるとポリシーの問題になりますが、僕としてはこれ以上PHPが「勝
> 手に(== implicitに)いろいろしてくれる」機能は追加すべきではない、と
> 思っています(現状でも有り過ぎ、というか)。

痒いトコロに手が届く。。。で、こそPHPじゃあないですか、とあえて
言ってみる。いや、冗談です。ごめんなさい。(^^;

> # multipartの変換は...どうでしょう？この辺はZend Engineから離れるので
> # 今回の議論ではパス、ということで他の方に譲ります（笑）

確かにZend Engineから議論は外れますけど。。。ちょっと次回に期待。
以前は仕様、という事でちょっとさみしかったです（笑）

。。。自分が頑張ればいいんですけどね、いつもすみません。

> > script_encodingにautoはサポートするべきでは無いと思います。
> > # XMLの様にファイルの先頭にエンコーディングを記述するように
> > # 約束事が必要になります。
> 
> これについては僕も迷うところです。autoが無いほうが、設計も実装も綺麗に
> なるし理解しやすいのは確実ですが、autoが役立つ場面がまだまだあるのも確
> かなので。
> 
> この辺とそれに付随する項目としては：
> 
> (1) script_encoding=autoをサポートするか？
> (2) script_encoding->internal_encodingをサポートするか？
> (3) (2)をサポートする場合、そのon/offはencoding_translationで指定すべ
>     きか？(前に話題になりましたね...)
> 
> 等でしょうか。

自分はautoではなく、固定で使う人なので、(1)はあまり困らないの
ですが、(2)に関しては現状のものとの互換性をどうするか？という
事につきます。

今まで、

(script)     (internal)
SJIS     →  EUC-JP

だったものが、

(script)     (internal)
SJIS     →  SJIS

と、勝手になる訳で、EUCを前提として書いているようなプログラム
が正常に動かない可能性があり、また、EUCで格納されているDB(ファイル)
から、そのまま情報を持ってきた場合に文字コードが一致しなくて
文字化けする等。

現状は、

http://ns1.php.gr.jp/pipermail/php-dev/2003-May/000762.html

な感じで明示的にinternal_encodingを返る場合と、変えない場合が
ある( 大抵は後者・携帯系は前者 )ので、前者は問題ないのですが、
特に後者において、どうにか互換性はないのかな？と思っています。

zend-multibyteで、現状の機能と、(script)→(internal)になる
ような機能を提供してみるとか。。。余計に混乱ですかね？

でもなぁ、PHP5では特にクラスの仕様が大幅に変わるので、いっそ
の事、気分一新して、それもいいかな。。。なんてぼそっ。

なにか、そういう気分にさせてくれる( デメリットを払拭させて
くれるような )新たな機能がmbstringに提供されれば、ユーザー
も納得するのかもしれませんね。

--
Seiji Masugata<s.masugata ＠ digicom.dnp.co.jp>