[PHP-dev 1467] Re: UTF-8文字の長さ

[Tatsuo Ishii]

横から済みません。石井です。

違っていたらごめんなさい。

小泉さんの懸念は、そもそも ISO/IEC 10646ではinvalidではないのに、
RFC3629 や Unicode Standardでinvalidだからと言って、PHP側でその部分を
無視して良いのですか、ということだと思います。

どうでしょう？ > 小泉さん
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> 大垣です。
> 
> ICUでも似たような問題があって、最近修正されています。
> ICUのパッチを見る限りでは後に続く文字を食べてしまうように見えました。
> アドバイザリもXSS脆弱性となっていたのでそのような動作をしたのだと思います。
> 
> mbfilterが古い規格に基づく長さになっていることをしばらく前から知っていて、気
> になっていたのですが、ICUの脆弱性を機会にメールしました。
> 
> 個人的には、こんなUTF-8の規格変更をするな、と言いたいですが、なってしまった
> 物は仕方ないので、攻撃に利用できる状態などは思いつかないですが、無効なエン
> コーディングを作らない(作れない)ようにしておいた方が良いと思います。
> 
> mbfilter的に、この前のパッチで良いのか分かっていません。
> 詳しい小泉さんに見ていただけると助かります :)
> 
> --
> Yasuo Ohgaki
> 
> 2009/04/11 0:36 Moriyoshi Koizumi <mozo ＠ mozo.jp>:
> > 小泉です。
> >
> > それはわかるのですが、これは単純にUTF-81文字を表すシーケンスの最初のオクテットから長さを決定するテーブルなので、単純に 5 を 4
> > に変えるような問題ではないと思うのです。
> >
> > また、ISO/IEC 10646 では U+110000 以降は reserved と定義しているので、この領域に対応する UTF-8
> > シーケンスは (符号化という観点では) 有効です。
> >
> > RFC3629 や Unicode Standard では、そのようなシーケンスは無効だという理解です。
> >
> > 2009/4/11 Moriyoshi Koizumi <mozo ＠ mozo.jp>:
> >> 2009/4/11 KOYAMA Tetsuji <koyama ＠ hoge.org>:
> >>> 小山です。
> >>>
> >>> 2009/4/11 Moriyoshi Koizumi <mozo ＠ mozo.jp>:
> >>>> 小泉です。
> >>>>
> >>>> 不勉強ですみませんが、この変更にはどのような意義があるのでしょう。
> >>>
> >>> RFC 3629 では、UNICODE で定義されていない 第16面より後ろに
> >>> 対応するバイトシーケンスは削除されているということだと
> >>> 思います。最長 4 バイトになってますね。
> >>>
> >>>
> >>> --
> >>>    小山哲志＠テックスタイル
> >>>    koyama ＠ techstyle.jp
> >>>    koyama ＠ hoge.org
> >>> _______________________________________________
> >>> PHP-dev mailing list
> >>> PHP-dev ＠ php.gr.jp
> >>> http://ml.php.gr.jp/mailman/listinfo/php-dev
> >>>
> >>
> > _______________________________________________
> > PHP-dev mailing list
> > PHP-dev ＠ php.gr.jp
> > http://ml.php.gr.jp/mailman/listinfo/php-dev
> >
> _______________________________________________
> PHP-dev mailing list
> PHP-dev ＠ php.gr.jp
> http://ml.php.gr.jp/mailman/listinfo/php-dev