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

2009年 4月 13日 (月) 21:07:53 JST

石井です。

確認ですが、小泉さんのおっしゃる「文字集合」とはUnicodeのcode pointの
ことを指しているのでしょうか？だとすると、「表現可能な文字集合」とは
code pointのことになり、もともとUnicodeがcode pointを割り当てているわ
けですから、「表現可能」なのは当然で、同義反復だと思います。

# たぶんUnicodeには「文字集合」という概念はないので、ちょっと混乱して
# しまいました。

3については基本的に同意ですが（そのようなシーケンスが発見された時点で、
以降の変換処理を中断する）、1が妥当なのかどうか勉強不足で良く分からな
いので、ちょっと調べてみようと思います。
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> 小泉です。
> 
> ええと、論点は 3 つありまして、
> 
> 1. ISO/IEC 10646 の UTF-8 は obsolete なのか
> 2. ISO/IEC 10646 に倣って reserved となっている区点に対応するシーケンスも許容するのかどうか
> 3. 許容しないとして、理論上 5 バイトや 6 バイト長となるシーケンスが来た場合にどのような対処をすればいいのか
> 
> 1. については、個人的には「規格としては obsolete ではないが、従うべきではない」と考えます。UTF-16 との
> interoperability をはじめとして、符号化方式も表現可能な文字集合を前提としたデザインにするべきだという観点が Unicode
> Standard や RFC に盛り込まれているのだと思います。
> 
> 2. については、ISO/IEC 10646 の UTF-8
> というものを一種の符号化方式として見立てる立場に立つと、文字集合の変換が関与しない文字列操作においては、許容されるべきということになります。mbstring
> の場合は、一部の例外を除いて文字列操作関数で UCS-4 もどきへの変換が一旦行われるため、RFC3629
> 的に許容されないシーケンスはエラーとなることが自ずと保証されていると言っていいと思います。
> 
> 文字列操作関数でエンコードされた文字列の妥当性検査を行う必要があるかどうか、という議論もあります。私は入出力では必要があると思いますが、スクリプト内部での操作には必要ないと思います。
> 
> 3. については、テーブルの修正のみですと、そもそも符号として許容されていないバイト列を 4
> バイト長であると無理やり見なすことになるため、あまり問題の解決となっていないように思われます。そのようなシーケンスが発見された時点で、以降の変換処理を中断するのが正しい対処法かと思いますがいかがでしょうか?
> 
> 2009/4/13 Tatsuo Ishii <t-ishii ＠ sra.co.jp>:
> > 横から済みません。石井です。
> >
> > 違っていたらごめんなさい。
> >
> > 小泉さんの懸念は、そもそも 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
> > _______________________________________________
> > 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