[PHP-dev 1496] Re: mbstring の文字列変換、文字エンコーディング検出の関連の問題について

[komura]

komura です。

遅くなりましたが、作成したパッチを検証してみました。
とりあえず、大きな問題はなさそうに思いましたので、添付して投稿します。


> > ところで、関連する別の問題を発見してしまいました。本来であれば U+FEFF は先頭にあるときのみ BOM
> > としての役割を果たすため、挙動としては明らかにバグなのですが、コード列の中のいずれの箇所でも U+FFFE が出現すると、U+FEFF
> > が出力された後、エンディアンが切り替わってしまうのです。

パッチでは、エンディアンの切り替えは最初だけにしてみました。
結果は以下のようになります。

$ php 'var_dump( bin2hex( mb_convert_encoding(
 "\xfe\xff\xff\xfe\x41\x00\x42\x00\x41\x00", "UTF-16BE", "UTF-16" ) ) );'

パッチ適用前: string(20) "fefffeffff4100420041"
パッチ適用後: string(20) "fefffffe410042004100"


> それとも、0xfffe が BOM の位置以外で出現した場合は、不正文字列として
> 削除すべきでしょうか？
> 手元の iconv では削除するようです。ただ、iconv も本件と同じような問題
> があるような気がします。
> 
> var_dump(bin2hex(iconv("UTF-16", "UTF-16BE",
> "\xfe\xff\xff\xfe\x41\x00\x42\x00\x41\x00")));
> ----
> 結果
> string(16) "fffe410042004100"

上記の BOM に関する件と iconv() の挙動については、私が勘違いです。
UTF-16BE は BOM を付けてはならないため、iconv() の結果としては上記
で正しい動作になっています。
上記の場合は、BOM があるのかないのか判断できないような気がしますが・・・。


RFC2781 では、UTF-16BE と UTF-16LE は BOM は使用不可となっています。
mb_convert_encoding() では、UTF-16BE および、UTF-16LE への変換では
BOM が残りますので、この挙動の方がおかしいということなると思います。

今回のパッチでは、BOM 関連の処理は変更していません。
UTF-16 の変換で文字列が壊れるという当初の問題と、途中で U+FEFF が
出現した場合に、エンディアンが切り替わるという問題のみへの対処です。

-- 
komura <komura.db2r1e ＠ gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: php530_mbfilter_utf16_invalid_conversion_2.patch
Type: text/x-patch
Size: 979 bytes
Desc: 無し
URL: <http://ml.php.gr.jp/pipermail/php-dev/attachments/20090830/086e9ce1/attachment.bin>