[PHP-dev 1032] Re: Fwd: [PHP-I18N] Re: ICU Extensions for PHP

[Moriyoshi Koizumi]

小泉です。

On 2004/11/04, at 16:52, Tadashi Jokagi wrote:

> Moriyoshi Koizumiさんの「[PHP-dev 1030] Re: Fwd: [PHP-I18N] Re: ICU 
> Extensions for PHP」から
>> はい。増やしました。XML 関連の拡張モジュールが標準で enable され、
>> iconv が libxml とのからみで自動的に有効にされることが推測できたので、
>> どこでも multibyte-aware な関数を使える環境を実現するには iconv に
>> アドホック的に mbstring と等価な関数を追加していくしかないという
>> 動機からでした。
>
>       なるほど．ナイスだと思います．

そういっていただけるとありがたいです。
特にこの件に関してはフィードバックをはじめて頂いたもので。

>> # 決して mbstring を見限ったとかそういう意図はないですよ
>
>       日本での貢献を見るだけでも今だにすばらしいモジュールだと思います．

「見限った〜」に関しては、mbstring を条件付きで PECL に移動すると
いう話を私が提案していたことについてのフォローです。実は。

以前 Derick さんから私宛にメールがあったのをきっかけに始まった
話に廣川さんも交えようとして、それきりになってしまっていたので
改めてこの場を借りて説明したいと思います。ちょっと長くなりますが
ご容赦下さい。

要は mbstring モジュールと libmbfl (mbfilter) が分離し、
libmbfl が PHP のコードベースとの依存関係を持たない独立した
ライブラリになったので、現在のようなライブラリの
「バンドル」という形式を止めて、いっそのことユーザさんには
libmbfl は PHP のパッケージとは別に導入してもらって
--with-mbfl (--enable-mbstring ではなく) を configure に指定して
もらったほうが、いろいろな面 (このメールでは省略させてください) で
メリットが多いのではないかと考えたわけです。

この流れでいうと、libmbfl (mbfilter) を単体パッケージとして標準で
提供しているディストロは現状ではないわけで、標準モジュールとして
PHP のパッケージに、はじめから mbstring を含めておく正当性が
薄れてしまいます。

ですから、mbstring を PECL に移動するという話に繋がるのですが、
もちろん現状で mbstring を多くの人に使っていただいていることを
顧みると、現在の PECL の仕組みの中に放り込むことは大変利便性を
損ねてしまうことになりかねませんので、PECL がもっとユーザに
使いやすい形で整備されれば、検討してもいい事項ではないかと
思っています。

>> 個人的には iconv_substr() 等を使う事はあまりおすすめしません ^^;
>> というのは、mb_substr() などと比較して恐ろしく遅いためです。
>> (平均で 1/3 位の速度です)
>
>       3 倍早いマシンで(苦笑

まあ、実際 iconv_substr() をパフォーマンス上の重大なボトルネックと
なるくらい頻繁に使うようなケースはまれでしょうし、iconv_strpos() に
関して言えば、UTF-8 ならば preg_* ファミリの関数を使った方が速い
場合が多いですからね、工夫 (?) 次第でなんとかなるものかもしれません。

>> そうは言っても、iconv_mime_*() ファミリは mbstring よりはだいぶ
>> RFC に添っていて柔軟性の高い作りになっていますので、
>> iconv_mime_decode_headers() などはメールボックス解析などに有効では
>> ないかと (かってに) 期待しています。
>
>       mbstring は個人的には「携帯端末(SHIFT JIS)対応」と「日本語メール
>     対応」の解決に使われることが非常に多いと思っています．XML とかも
>     まぁそうですがあの辺の文字コード変換程度なら PHP 4 の iconv() でも
>     事足りるので．

私が開発に参加する前に決まった仕様ですからあまりかってな事は
言えませんが、携帯に関して言えば、肝心の mb_send_mail() が
携帯メールに対応していないことは重大だったと考えています。
言い換えれば、mbstring.language の設定でしかメール本文の
文字コードやヘッダの文字コードを決定できないという仕様は一種の障害
だったのではないかと思います。

# PHP 5 からはヘッダのオーバーライドをサポートし、
# Content-Type ヘッダをオーバーライドするとメッセージボディの
# 文字コードを変えられるようになりました。

>> あと、iconv_send_mail() について。同等の関数を追加することは可能ですが、
>> どの程度需要があるでしょうか。。。
>
>       前述の通り，メール送信に mb_send_mail()が利用されることは非常に
>     多いと思います．もし iconv が標準で存在することになったら
>     l10n/i18n を意識してないオープンソース(sf.net にも結構あります)の
>     mail() でメール送信しているものを iconv_send_mail() にしてよ!!っ
>     て言いやすいと思います．mbstring は海外ではまず有効になってない場
>     合が多いので，なかなかそうもいえないんですよね．

分かりました。これについては別メールで検討したいと思います。