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

自己紹介てきめん • https://tekitoh-memdhoi.info • X: @youkidearitai • https://github.com/youkideari tai
オレ

mbstringとは • PHPのマルチバイト処理を司るPHP拡張 • C言語でできている – libmbflというライブラリに依存している • UCS方式（目的の文字コードに変換する前にUCSに変換する） –
コードポイントごとに処理する – 対する方式としてCSI方式がある(Rubyが代表的) • もちろん組合せ爆発はあるものの独自の文字エンコーディングとかできたりするのでこっちもメリットが有る

今までのmbstring • PHP 5.6くらいまでは活発に日本人が開発・利用していた – コミッターもいらっしゃった – 諸説あるけど7ではもうほとんどいなくなってた •
セキュリティの専門家もいる • 徳丸先生とかがいるのはかなり強い

現在のmbstring • 実はmbstringという名前の通り、色々な国・地域の人々が使っていたPHP拡張だった • 当然のことながら「海外に徳丸先生は居ない」ため、不適切な使われ方が散見されるようになる • PHP 8.1で判明した大規模改修で注目されているのは
「mb_detect_encoding」 – これを使って文字コードを判定してたので困り果てる日本・海外ユーザー多数

統一されていない内部エンコーディング • 実は内部で使用する文字コードはバラバラ – mb_strposではUTF-8に変換する • https://github.com/php/php-src/issues/9613 で不正なバイト列で ?
がマッチするというIssueを作ったことがある – mb_substr他、大体の関数ではUTF-32(UCS-4)に変換する – この挙動の不統一さによって、セキュリティ問題が発生する可能性があると指摘される

日本のユーザーはどうやってたか • 我々には徳丸先生がいる – コミッターの大垣さんもいた • mb_check_encodingを作ってくれたのでまずはそれを通して不正なバイト列を弾くということをする – そうすれば先程の不統一さは気にしなくても良くなる

普通書くならこうですよね

海外のユーザーでは？ぎょっとしましたがこれをXSS対策だと言ってきました: https://externals.io/message/121889#121924 ま、まあ海外に徳丸先生は居ないから…

いやあ…それは違うでしょうと言いたいが • mb_check_encodingを使って入力された文字コードのチェックをするなんて本当にやっているのか？ – 日本のユーザーならこんな話はしないはず • https://www.docswell.com/s/ockeghem/ZVM1XZ-PHPCON-2010-character-code-securit y –
13年前に徳丸先生が「文字コードちゃんとチェックしろよ」って言ってくれた • しかし、フールプルーフのような考え方をするならば、このような方法を想定しなければならないのでは？ – つまり、色々なユースケースを考えないといけないよなということなどと考えるようになりました。

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で動かない文字が発生しましたが… – 使ってないだろうしいいだろうということで一致しています

つまりこれからのmbstringは • 徳丸先生のいない世界線のmbstringの使われ方を想定しないといけない – そういう人たちにはmbstringはレイヤーが低め • 日本人が作り、日本人が使っていたというユースケースから、日本人はユーザーのうちの一人になってしまった

最新のmbstringの動向 • 最近Alex Dowadさんに呼び出されているのは、主にmb_strcut関数についてです – Alexさんによると「libmbflに依存している最後の関数」だそうです – libmbflからの脱却を図っているという認識です
• そうすると使われない数千行のコードを削除できます

最近のわたし • mb_strcutってよくわからん関数ですね – 切られ方が違ってる可能性があるので注意してください（挙動が違ってる可能性ありと言いたい） – 正がわからなくなってくる – レビューするからには全力でやっていきます

mbstringとは関係ありませんが次のようなことがありました

「みんな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の話じゃない。論点をずらすないで」と反論 – 徹底的にぐうの音もださせないようにしました。ユニコード戦記で学んだ

まとめ • mbstringは日本人が作って使ってたから、世界中のユーザーの一人に変わっていった • 海外に徳丸先生は居ない（日本でも永遠ではない） • libmbflから脱却しようとしている – mb_strcutの挙動が変わっている可能性がある
• 文字コードのチェックはちゃんとしましょう • 内部の文字コード処理はバラバラである

いかがでしたか？ • mbstringは最早日本語の拡張ではないと思われます • こんな感じでほぼ毎日、土日もなしに議論してます★ – 国境なき技術での議論は楽しいですよ • これからも文字コードおよび文字集合の規格を掘り下げて調べていきます
– PHPカンファレンス北海道ではよろしくお願いします。 • 資料作成中です

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

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

てきめん tekimen PRO

Transcript