現在の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カンファレンス北海道ではよろしくお願いします。 ● 資料作成中です