[PHP-dev 768]Re: zend-multibyteの挙動について

[Moriyoshi Koizumi]

小泉です。

Tomoyuki Asakawa <tom ＠ asakawa.ne.jp> wrote:
<snip>
> それとも、internal_encdingがSJISになっても
> SJISスクリプトに”能"という文字が入っていても正常に動作する
> 様にPHP本体が変わることを前提にされてるのでしょうか？

このくだり、すみませんが意味をつかめません。
まず、zend multibyte を有効にしてビルドされた PHP ならば、

mbstring.script_encoding=SJIS
mbstring.internal_encoding=SJIS

としても、SJIS で書かれたスクリプトを問題なく実行できるはずなのですが。
さらに、

>  >ついでに書いておくと、本来、encoding_translationの用途は
>  >http_inputの(internal_encdingへの)自動変換なのでは？という話を
>  >していました。
> 
> 「本来」って意味ではそうだと思います。
> しかし、PHP本体が、SJISを、理解できない以上しょうがないという
> ことだと思います。

こんなことを言うと話がややこしくなるかもしれませんが、
zend multibyte なしで、internal_encoding を SJIS にするケースも
十分考えられますよね。SJIS の解釈に問題が発生するのは字句解析の部分であ
って、ランタイムが SJIS を扱えないわけではありませんから。
スクリプトからマルチバイト文字を排除するだけで addslashes() など一部の関
数の挙動に注意すれば問題なく動くわけです。

とにかく、素の(zend multibyte なしの) PHP においても、internal_encoding 
にSJIS が指定できないということはありません。

> また、
> 
> internal_encoding != script_encoding
> のおかげで
> 
> 今だと。
> ファイルやＤＢの入出力がinternal_encodingに固定されるので
> スクリプトがEUCとSJISの混在でも、正常に動作するという
> メリットもあります。
> もちろん混在させるのが間違ってるという考え方もありますが。

スクリプトを SJIS で書いて、DB の入出力を EUC-JP で行うというケースでし
ょうか。今回の話は、それがユーザの混乱につながるから、internal_encoding 
とscript_encoding を異なる設定にできないようにしたほうが幸せなのではない
か、という議論のつもりです。

> なので逆に現在、internal_encodingに
> ファイルの入出力のencodingも影響受けていますが
> ある意味でこちらの方が、わかりにくくしてる原因の一つだと思います。

それは仕様上あたりまえの事ではないでしょうか。以下に続きます。

> 既存の言葉だと誤解の元なので、あえて、日本語にしますが
> 
> プログラムスクリプトの漢字コード
> PHPの文法処理の漢字コード
> ファイル入出力の漢字コード
> API(DBなど）の漢字コード
> HTTP 入出力の漢字コード
> 
> この５つは、独立事象のはずです。

考え方の違いだとは思いますが、私はこれら全てが独立事象とは思いません。
なぜなら、ファイル / DB の入出力は、特に mb_convert_encoding() などによ
ってスクリプト内で明示的な変換を行わない限り、字句解析後の文字列のエンコ
ーディング(PHPの文法処理の漢字コード)によって行われるからです。
それ以上のものでもそれ以下のものでもありません。

> script_encoding = internal_encoding
> にすると、わかりやすくなる様に
> みえるのだと思います。
>
> わたしは、前述の様に、それはそれで別の問題を引き起こすと思います。

別の問題とはどのことをおっしゃっているのでしょう？

> そこで
> 
> プログラムスクリプトの漢字コード=script_encoding
> ファイル入出力の漢字コード=file_encoding
> API(DBなど）の漢字コード=api_encoding
> HTTP 入出力の漢字コード= http_encoding
> 
> 以上がinternal_encodingから
> 分離できれば。
> PHPの文法処理の漢字コードにSJISが使えないという
> 問題は無関係になり
> PHPの文法処理の漢字コード＝internal_encoding
> は、PHPの開発者以外は知らないで
> よいことになるはずです。
> 
> その時
>   file_encoding= api_encoding= http_encoding
> のデフォルトが、script_encodingと同じになるというのならば
> 非常にわかりやすくなると思います。

file_encoding と api_encoding と script_encoding と internal_encoding が
全部バラバラに指定できるという状況はどう考えても好ましくないし、
利便性をそれほど強く感じないのですが。