[PHP-dev 1387] Re: mb_strwidth関数とmb_strimwidth関数の挙動について

[Moriyoshi Koizumi]

小泉です。

Seiji Masugata wrote:
> こんにちわ、桝形です。
<snip>
>>> 実装としては間違っていないけれど、今は常にnon-East Asianとして定義
>>> されているのでは、という事でした。本来であれば、該当する部分は、
>>>
>>> - East Asian　　　：　幅２
>>> - non-East Asian　：　幅１
>>>
>>> というような分岐が必要なのでは、という事です。
> 
> East Asianで振る舞う実装を追加したい、というのが目的です。
> そのように理解していますが間違っていますでしょうか？
> そもそも無理がある、という事でしょうか？

ambiguous な文字をどのように扱うか、という件ですね。TR11 にあるように、
それは文脈に依る話かと思います。

初めに実装したときは確かに annex の方も考慮していて、もっぱら PHP が web
関連のアプリケーションに使われる言語であるということから、表示はプロポー
ショナルなフォントで行われることがほとんどだろうというところで、変にオプ
ションをつけてあれこれするよりは ambiguous は half width として扱うよう
にしたという思惑がありました。

East Asian な文字セットを含む monospace なフォントのほとんどで慣例どお
り、ambiguous が full width になるような字形が提供されているということな
ら (おそらくそうでしょうが)、それらを考慮してオプションをつけてやるのも
一つの案かと思います。

PHP の手続き型で利用されることが想定される関数でコンテキスト (先の文脈と
同じ意味で使っています) を扱うには 4 通りの慣例があると認識しています。

1. 拡張モジュール側で内部的にコンテキストを保持する。コンテキストはユー
ザから隠蔽する (strtok() や mb_regex_set_options() など)
2. コンテキストをリソースとしてユーザに公開し、ユーザ側が関数の引数とし
てそれを常に渡すようなインターフェイスにする (stream context など)
3. 配列、ビットマスクなどの形で、関数パラメータとして暗黙的にコンテキス
トをユーザが指定できるようにする。
4. コンテキストごとに別の関数を用意する。(imagecopyresampled() /
imagecopyresized() など)

もっぱら 1. は安直で、バグの温床になるのでできれば避けたいと思います。

-- 
Moriyoshi Koizumi <moriyoshi ＠ at.wakwak.com>