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

[Yasuo Ohgaki]

大垣です。

Masaki Fujimoto wrote:
>>># script_encoding=internal_encodingだと
>>># script_encoding=autoの時
>>># SJIS/EUCごちゃまぜのソースの時困ります。
>>
>>無用な問題を避ける為にもソース／DBのエンコーディングは統一
>>するべきと考えています。経験豊かな方はそうしているので、
>>それに習った方が良いと思います。
> 
> 
> おそらくあさかわさんは、大垣さんのおっしゃっている「したほうが良い」と
> いうことをお分かりになった上で、なお「実務レベル」(?)では、たとえば
> ソースコードがShift_JIS/EUC-JPで書かれているという事態が往々にして発生
> してしまうので、こういった状態をPHP側で吸収してくれるとうれしい、とい
> うことをおっしゃっているのかな、と思います。

確かにあります。私もzend-multibyte無しでコンパイルしたPHP用のプログラ
ムを当然のようにEUC-JPで書いたところ、何故かおかしな動作をするので調
べてみたら他の方はSJISでスクリプトを書かれていた、と言うこともありま
した。
# DBがEUC-JPだったので、当然スクリプトもEUC-JPで、と思ったのですが
# 「zend-multibyte無しでもUTF-8も使えるので初めに確認すべき」と言わ
# れればそれまでですね...

ある程度便利と言う事も事実ですが、本当に必要な機能か？と考えると、ど
ちらかと言うと無い方が良いのでは？と思っています。

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

同感です。

> たとえば、ファイルの入出力エンコーディングに関しては、(それがユーザ定
> 義になるか、システムから提供されるかはまだ分かりませんが)ストリームを
> 用いて抽象化するところかと思います。データベースに関しても同様で、これ
> はデータベース側のエンコーディング変換機能を利用するか、データベース抽
> 象化クラス側で対処するのが自然に思えます。さすがにこれらをPHP側で、
> (http_input/output変換のように)組み込まれた仕組みとして提供するのは
> ちょっと行き過ぎかな、と思うのですがいかがでしょうか？

確かにやりすぎに思えます。ストリームの様な仕組みにするにしても、モジュー
ルの書き換えは必要になりますし...

>>script_encodingにautoはサポートするべきでは無いと思います。
>># XMLの様にファイルの先頭にエンコーディングを記述するように
>># 約束事が必要になります。
> 
> 
> これについては僕も迷うところです。autoが無いほうが、設計も実装も綺麗に
> なるし理解しやすいのは確実ですが、autoが役立つ場面がまだまだあるのも確
> かなので。

機械的にエンコーディングを変換しては、と言っても開発体制の関係上、簡単に
そうできない場合もありますね...

私は利用しないと思いますが、script_encoding=autoに関しては中立(あっても
無くても良い)と言う立場にさせて頂きます。

--
Yasuo Ohgaki