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

[Tomoyuki Asakawa]

あさかわ

> この件で、議論していたのは、

なにを議論してるのかはわかってるつもりですが。

> >SJISを、設定することはできるけど、SJISの、２バイト目に\が来る文字
> >（能など）の問題があるので事実上つかえないはずですが。

 >それは理解しています。

なのだから

>>    //  SJISでスクリプトが書かれていた場合、自動的に
>>    //  internal_encdingがSJISになる

なんていうのは、反対だと言ってるわけですよ。

それとも、internal_encdingがSJISになっても
SJISスクリプトに”能"という文字が入っていても正常に動作する
様にPHP本体が変わることを前提にされてるのでしょうか？

 >ついでに書いておくと、本来、encoding_translationの用途は
 >http_inputの(internal_encdingへの)自動変換なのでは？という話を
 >していました。

「本来」って意味ではそうだと思います。
しかし、PHP本体が、SJISを、理解できない以上しょうがないという
ことだと思います。

また、

internal_encoding != script_encoding
のおかげで

今だと。
ファイルやＤＢの入出力がinternal_encodingに固定されるので
スクリプトがEUCとSJISの混在でも、正常に動作するという
メリットもあります。

もちろん混在させるのが間違ってるという考え方もありますが。

本来論ならば漢字コードなんて意識しないですむ様になっていればいいのですが
歴史的経緯で、現在は意識が必要で、将来的にも、必要でしょう。

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

既存の言葉だと誤解の元なので、あえて、日本語にしますが

プログラムスクリプトの漢字コード
PHPの文法処理の漢字コード
ファイル入出力の漢字コード
API(DBなど）の漢字コード
HTTP 入出力の漢字コード

この５つは、独立事象のはずです。
ところが、現在真ん中の３つが、internal_encodingとして
同時に作用してしまうので

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と同じになるというのならば
非常にわかりやすくなると思います。