[PHP-dev 298] 「PHP国際化に関するミーティング」(2002/4/9 開催)のまとめ

Sat, 13 Apr 2002 21:54:16 +0900

廣川です。 

大変遅くなりましたが、今週の火曜日に行われました
ミーティングのまとめを書いておきます。
ミーティングに参加された皆さんお疲れ様でした。

いろいろと抜けもあるかと思いますが、ご指摘/ご意見いただければと思います。

なお、以下の議論においては、現状の国際化機能において既にサポートされている
機能も必要とされる機能の中に含まれていますが、Webアプリケーション用の
スクリプト言語として必要な機能をサポートするという観点から議論を行いました。

なお、私個人の意見は以下の文章においてできるだけ排除しているつもりですが、
もしかすると、偏りがあるかもしれません。

また、以下の機能の実装に際しては、実装の容易さやシングルバイト圏の開発者の
意見といった要素がかかわりますので、最終的に実装される機能と
一致するとは限らないということをご承知おきください。


「PHP国際化に関するミーティング」(2002/4/9 開催)のまとめ

今回のミーティングは、前回のミーティングでまとまらなかった
事項を国際化に関する機能のリクエストとしてまとめることを目的として
行われました。
今回は、参加者がそれぞれPHP国際化に関して必要だと思う機能について
リクエストを出すという形で行われ、前回と同様に活発な議論が行われました。

しかし、やはり議論が発散傾向であったため、時間の関係で途中から関数で実現
できるような付加機能はとりあえずおいておき、内部文字情報の取扱いや変換と
いった基本的な機能に焦点を絞って議論を行いました。

「基本的な機能(必須の機能)」

1. ユーザ入力(POST/GET/Cookie)の文字エンコーディング自動判別/変換
   ユーザ入力の取得処理はそのまま通して、関数でまとめて変換できると良い。
   (mb_parse_str()関数に相当?)
2. (HTML)出力の文字エンコーディング指定／変換
   
3. PHPスクリプトのコード指定/内部コードへの変換
  * 文字エンコーディング自動判別/変換ができる方が良い。
  * 余計な変換をせずにそのまま通して、内部的な文字情報として使いたい。
   (変換をするとどうしても可逆性が保てない特殊なコードがある場合に困る)

   (この辺の議論が一番盛りあがりました。)

  * (\を漢字コード領域に使うなど)Shift_JISが特殊な文字コードである。
    このコードさえ通せれば他の文字コードのサポートに問題はない。
  * Shift_JIS(やワイドキャラクターを)を通すようにパーサが賢くなれば
    よいのではないか。
  * Shift_JISが指定された場合は、パーサの前後で必要な変換を実施する。
  * スクリプトから呼ばれるライブラリの文字コードが違っていたら、どうするか?
      この辺は意見の集約が難しいですが、以下の点まではまとまりました。

   -  明示的に指定する形式で、複数の文字
   エンコーディングをスクリプトで使用可能とし、
    php.ini、php_value、encodingディレクティブ(先頭行)で指定可能とする。
    (右側の方が優先準位が高い。)
   - 現在のスクリプトの文字コードを取得する手段(関数)を用意する。

   スクリプトの文字エンコーディングを指定して具体的にどうするかという
   ところまでいくと、内部文字コードに変換するとか、とりあえずパーサだけ通す
   ようにして、あとはスクリプトの文字コードをそのまま使用するということまで
   決める必要があります。

  ここまでが、最終的に意見がまとまった要件です。
  その他に重要と考えられる課題についての議論について以下にまとめます。   

1. 内部コードについて

  * ワイドキャラクターのサポートは困難なので、現実的にはUTF-8あたりが妥当だろう。
  * UTF-8固定とするとISO-8859-1を使用するドイツ語圏の人からクレームがでるだろう。   * iモードの絵文字やチルダのように問題を可逆性に問題を発生するケースがあるので、
    余計な変換をせずにそのまま通して、内部的な文字情報として使いたい。

2. strlenをはじめとする文字列関数
  * マルチバイト関数でオーバーライドする。
  * PHPスクリプト内のユーザ定義関数で組み込み関数を上書きできるようにする。
  * strlenについては文字数を返す関数とバイト数を返す関数を二つ作る。
    (これについては異論あり) 
3. 文字リテラルのサポート
 * 現状では、バイト情報として文字を認識。
 -> ZendEngine2の $a{3} といった構文で問題となる。

4. 関数単位での入出力文字コードの制御
 * データベースとのインターフェイスで必要となる文字コード変換について
  動作を制御する仕組みが必要。
  -> PostgreSQL等は関数APIレベルでクライアントエンコーディングを指定可能なので
     不要またはデータベース側の問題ではという意見あり。

5. 性能の確保 
 * シングルバイトの文字列を処理する際の性能を低下させるような変更は
    受け入れられないだろう。


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