[PHP-dev 253] Re: PHP 5/Zend Engine 2の国際化について

Fri, 8 Mar 2002 00:05:02 +0900

廣川でうs。

>   逆に、内部エンコーディングを採用する際に世間の人が一番心配するのは、エ
>   ンコーディング変換のパフォーマンスのようです。が、これに関してはコンパ
>   イラっぽいツール(APCやZend Encoder)を使用すればよいと思いますし、それ
>   が嫌なら内部エンコーディングで書けばよい話なので、それ程心配しなくても
>   よいかと考えています。
> 
>   まぁ、内部エンコーディングを採用しない、となると話は一気に変わってくる
>   (そして単純になる)と思うので、ここでは内部エンコーディングがあることを
>   前提に話を進めます。
> 
>   そして内部エンコーディングを何にするか(もしくはどの様に決定するか等)、
>   というのは、最後まで読んでいただければご理解いただけるかと思いますが、
>   結局国際化版PHP5の中心的問題となるのでここではちょっと結論できません。
> 
> # ひょっとして自分は大いなる勘違いをしているような気がしていて、なんだか
> # 不安です。いえ、なんとなくそう思うだけなのですが。

内部文字エンコーディングについては、コンパイル時にconfigureで
指定し、固定で良いと思います。
(--with-internal-encoding=UNICODE とか、)

内部文字コードに
切替えられることにメリットがなくもないですが、Shift_JIS/CP932の
取り扱いに問題がなければ、内部文字コードとして何を使っても問題は
ないでしょうし、かえって混乱をまねく可能性の方が大きいと思います。

内部文字コードとしては、理想的にはUCS-2/UCS-4等の国際化に対応した
ワイドキャラクターが良いと思います。
UCS-4だと今までシングルバイトで済んでいた多くのユーザから
反対がおきないとも限らないので、Javaとかと同様にUCS-2でしょうか。

現在のmbstringの文字コード変換はワイドキャラクターを経由しているよう
ですので、ワイドキャラクターを経由した相互変換のベースはあると
思います。

他には、多くの人が使えるISO-8859-1のサポートも必要でしょう。

ワイドキャラクター化での問題は、Zend APIのレベルでバイトストリームとの
相互変換を上手く吸収できないとほとんどの拡張モジュールの修整が必要に
なってしまうことでしょう。

現実的な案としてはUTF-8というのもありかと思います。

> 
> 
> (II) 個々の問題
> 
>   (1) スクリプトのエンコーディング
>     スクリプトのエンコーディングに関して問題となる点は以下の2つかな、と
>     思っています。
> 
>     - スクリプトエンコーディングの判別方法
> 
>       これについては
> 
>       (i)   php.ini/.htaccessで指定
>       (ii)  自動判別
>       (iii) スクリプト中で指定
>       (iv)  コマンドライン版PHPの場合はオプションで指定

(i)で指定するのがやはり基本ですね。
スクリプトを読みこむ際に内部文字コードに変換するという
機能をまずPHP4/Zend Engineに取り込むのが良いと思います。

(ii)、(iii)については確かに便利ですが、本家にとりこむ場合に、
メリットを理解してもらうのが若干難しくなるのではないかと思います。
(技術的には面白いのですが。。。)

また、(i)さえサポートされれば、Shift_JISでスクリプトを書きたい
ユーザに対しても、php.iniにこう書けば良いと言えるようになります。
複数の文字コードで書かれたPHPスクリプトを１つのアプリケーションに
読みこむような人は少数派だと思います。

> 
>   (2) 入力データのエンコーディング
>   (3) 出力データのエンコーディング
>     このうち(2)と(3)については、現在のところhttp_input, http_outputが実
>     装されていますが、その他の入出力(例えばI/O、データベースとの通信等)
>     については内部エンコーディング素通しです(言うまでも無く)。まぁ、現在
>     のinternal_encodingの意味はここ(DB連携等の都合)にあるのではないかと
>     勝手に思っているのですが、以前よしおかさんがおっしゃっていた通り、内
>     部エンコーディングは少なくともコンパイル時には決定すべきですよね(と、
>     これは廣川さんがおっしゃっていましたね)。

DBやイメージ関数等、固有の文字エンコーディングを要求する
モジュール、それから、ファイルI/O等とのインターフェイスでは、
文字エンコーディングの変換が必要となります。
具体的には各モジュール単位でのサポートとなるかもしれませんが、
その場合でもZendAPIのレベルで文字エンコーディングの変換用APIを
サポートして欲しいところです。

>   (4) 出力メッセージ
>     ちょっと疲れてきました-_-; ので簡単に済ませますが、これはzend_error
>     でメッセージカタログを使用して国際化、という方法で大丈夫かな、と考え
>     ています。もちろん、実装にあたってはもう少し決めなければいけないこと
>     が出てくるとは思いますが(localeの決め方等--環境変数? php.ini?)大筋と
>     してはよいかな、と(というか、他に思いつきません)。

エラーメッセージの国際化については、Zend Engine 2に関するドキュメントにも
書いてあったような気がします。
localeの設定については、php.ini で指定し、メッセージカタログを読みこむ方法で良いと思います。

> 
>   (5) 結局どうなのか
> 
>     結局現時点では、ほぼ全ての問題は「内部エンコーディング」ということに
>     集約されると思います。参考までに幾つか案を上げて見ますと(実装の実現
>     性云々は無視しています。実は最後にここを書いていて頭が飽和状態です:(
> 
>     - 現状(PHP3国際化版)のまま
>     - UCS-4(もしくはUCS-2、はたまたUTF-16)を強行採用
>     - Mule Internal Encodingはどうでしょう？
>     - UTF-8に固定
>     - UTF-8に固定だとISO-8859-xな人々がアレなのでUTF-8もしくは素通し
>     - コンパイル時にユーザが指定(選択肢は?)

(1) UCS-2
(2) UTF-8 or ISO-8859-1

あたりをコンパイル時に指定に1票です。

> 
>     皆様、色々ご意見がおありかと思います。いかがでしょうか？
> 
> 
> (II) (参考)他のスクリプト言語

これは、非常に参考になります。なかなか決定版みたいなのはないですね。
スクリプト言語ではないですが、最近のSambaとかはUCS-2だったでしょうか?

-- 
-----------------------------------------------------
Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
             <hirokawa@php.net>