現在のmbstringの立ち位置 これからどうなっていくのか

第159回PHP勉強会＠東京
https://phpstudy.connpass.com/event/304155/

Transcript

1. 現在のmbstringの立ち位置 これからどうなっていくのか
2. 自己紹介 てきめん • https://tekitoh-memdhoi.info • X: @youkidearitai • https://github.com/youkideari tai オレ
3. mbstringとは • PHPのマルチバイト処理を司るPHP拡張 • C言語でできている – libmbflというライブラリに依存している • UCS方式（目的の文字コードに変換する前にUCSに変換する） – コードポイントごとに処理する – 対する方式としてCSI方式がある(Rubyが代表的) • もちろん組合せ爆発はあるものの独自の文字エンコーディングとかできたりするのでこっち もメリットが有る
4. 今までのmbstring • PHP 5.6くらいまでは活発に日本人が開発・利用して いた – コミッターもいらっしゃった – 諸説あるけど7ではもうほとんどいなくなってた • セキュリティの専門家もいる • 徳丸先生とかがいるのはかなり強い
5. 現在のmbstring • 実はmbstringという名前の通り、色々な国・地域の人々が使ってい たPHP拡張だった • 当然のことながら「海外に徳丸先生は居ない」ため、不適切な使われ 方が散見されるようになる • PHP 8.1で判明した大規模改修で注目されているのは 「mb_detect_encoding」 – これを使って文字コードを判定してたので困り果てる日本・海外ユーザー 多数
6. 統一されていない内部エンコーディング • 実は内部で使用する文字コードはバラバラ – mb_strposではUTF-8に変換する • https://github.com/php/php-src/issues/9613 で不正なバイト 列で ? がマッチするというIssueを作ったことがある – mb_substr他、大体の関数ではUTF-32(UCS-4)に変換する – この挙動の不統一さによって、セキュリティ問題が発生する可 能性があると指摘される
7. 日本のユーザーはどうやってたか • 我々には徳丸先生がいる – コミッターの大垣さんもいた • mb_check_encodingを作ってくれたのでまずはそれを通し て不正なバイト列を弾くということをする – そうすれば先程の不統一さは気にしなくても良くなる
8. 普通書くならこうですよね
9. 海外のユーザーでは？ ぎょっとしましたがこれをXSS対策だと言ってきました: https://externals.io/message/121889#121924 ま、まあ海外に徳丸先生は居ないから…
10. いやあ…それは違うでしょうと言いたいが • mb_check_encodingを使って入力された文字コードのチェックをするなんて本当に やっているのか？ – 日本のユーザーならこんな話はしないはず • https://www.docswell.com/s/ockeghem/ZVM1XZ-PHPCON-2010-character-code-securit y – 13年前に徳丸先生が「文字コードちゃんとチェックしろよ」って言ってくれた • しかし、フールプルーフのような考え方をするならば、このような方法を想定しなければ ならないのでは？ – つまり、色々なユースケースを考えないといけないよなということ などと考えるようになりました。
11. Character indices used by mb_strpos and mb_substr have same meaning, even on invalid strings #12913 • https://github.com/php/php-src/pull/12913 – Alexさんが作ってくれました • mb_substrの挙動の変更ということになります • SJIS-macで動かない文字が発生しましたが… – 使ってないだろうしいいだろうということで一致しています
12. つまりこれからのmbstringは • 徳丸先生のいない世界線のmbstringの使われ方 を想定しないといけない – そういう人たちにはmbstringはレイヤーが低め • 日本人が作り、日本人が使っていたというユース ケースから、日本人はユーザーのうちの一人になっ てしまった
13. 最新のmbstringの動向 • 最近Alex Dowadさんに呼び出されているのは、主 にmb_strcut関数についてです – Alexさんによると「libmbflに依存している最後の関数」 だそうです – libmbflからの脱却を図っているという認識です • そうすると使われない数千行のコードを削除できます
14. 最近のわたし • mb_strcutってよくわからん関数ですね – 切られ方が違ってる可能性があるので注意してくださ い（挙動が違ってる可能性ありと言いたい） – 正がわからなくなってくる – レビューするからには全力でやっていきます
15. mbstringとは関係ありませんが 次のようなことがありました
16. 「みんなUTF-8だからUTF-8にしようぜ」 • https://externals.io/message/121825 Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ? • 「いやあ…」っていうため息が感想 – Shift_JISでは5c問題がでるということ(GB 18030も出るので中国も影響がある） – Shift_JISには亜種が大量にあり、そのバイト列だけで何の漢字を指しているのかわからないこと – そもそもISO-8859シリーズでも0xC4とか何になるの？Latin-1ならISO-8859-1だけど、16まであるよね？どう やって判断するの？ – RustならUTF-8デフォルトだしいいんじゃね？に対して • PHPほどの古い言語で新しい言語を比較に出すのはフェアじゃない、同じくらい歳を重ねた言語(Perl, Ruby, Python, Javaなど)と比較をすべきだと主張 – 「PSRがあってあっちではUTF-8で書けって言ってるんだからそれでいいじゃないか」と主張 • 「タブとかスペースとか縛られたくないのだが」という反論に対し、「オレが話してるのは文字コードの話。PSRの話じゃない。 論点をずらすないで」と反論 – 徹底的にぐうの音もださせないようにしました。ユニコード戦記で学んだ
17. まとめ • mbstringは日本人が作って使ってたから、世界中のユーザーの一人に変 わっていった • 海外に徳丸先生は居ない（日本でも永遠ではない） • libmbflから脱却しようとしている – mb_strcutの挙動が変わっている可能性がある • 文字コードのチェックはちゃんとしましょう • 内部の文字コード処理はバラバラである
18. いかがでしたか？ • mbstringは最早日本語の拡張ではないと思われます • こんな感じでほぼ毎日、土日もなしに議論してます★ – 国境なき技術での議論は楽しいですよ • これからも文字コードおよび文字集合の規格を掘り下げて調べて いきます – PHPカンファレンス北海道ではよろしくお願いします。 • 資料作成中です