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

2009年 4月 15日 (水) 13:23:49 JST

石井です。

「3」についてちょっとだけ見てみました。

1) UTF-16で最大の値がU+10FFFFになっているのは、UTF-16の実装上の制限

2) ISO/IEC 10646では、U+10FFFF以降は「予約領域」または「私用領域」となっ
   ている

つまり、U+10FFFF以降が許されないのは、合理的な理由があるわけではなく、
単にUTF-16の実装上の都合、あるいは歴史的な(政治的な)理由によるものであ
ると思われます。

であれば、

- UTF-8には、特にU+10FFFFの範囲内という制限を設けない
- UTF-16は、RFC3629にしたがって制限を加える

という考え方も成り立つと思います(PHPの実装を良く理解しているわけではな
いので、そもそもこういう使い分けが成り立つのかどうか分からないのですが)。
しかし、絶対UTF-8に制限を加えるべきではない、とまでは思いません。

# ちなみに、PostgreSQLでは、UTF-8を入力する際にU+10FFFF以下かどうかの
# チェックを行なう実装になっています。私が実装したところではないので、
# 背後にある考え方はわかりません。
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> 小泉です。
> 
> 2009/4/13 Tatsuo Ishii <ishii ＠ sraoss.co.jp>:
> > 石井です。
> >
> > 確認ですが、小泉さんのおっしゃる「文字集合」とはUnicodeのcode pointの
> > ことを指しているのでしょうか？だとすると、「表現可能な文字集合」とは
> > code pointのことになり、もともとUnicodeがcode pointを割り当てているわ
> > けですから、「表現可能」なのは当然で、同義反復だと思います。
> 
> 「表現可能」な、というのは「Unicode Standard
> に定義されている」というような意味合いで書いたつもりだったのですが、後で読み返すとたしかに意味不明で、同義反復となっていました。
> 
> > # たぶんUnicodeには「文字集合」という概念はないので、ちょっと混乱して
> > # しまいました。
> 
> はい、むしろそういう概念を持ち込まないことがゴールの一つでもあると思います。ここでは
> (規格上そう明記されているわけではないけれども、事実上の) 符号化方式として UTF-8
> を見る必要もあったので、より一般的なセンスで「文字集合」と表現しました。
> 
> > 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
> >