Unicodeに完全移行したい

PHPのメンテナーをしていますてきめんです。主に文字コードの機能を担当しています。

最近起きた変化

PHPでは、最近、mbstringというマルチバイト文字の拡張の機能追加がしにくくなってきました。その理由は、intl拡張のgrapheme関数（書記素クラスター）を再発明したことで、こっちのほうがいいじゃないかということです。

Unicodeを考えてみると、Unicode 16.0で日本語では文字情報基盤の文字を収録することができたため、一応の収束を達成することができたという認識であります。

また、Unicodeでないとコンピューターで文書を収録したり、コミュニケーションすることができない国・地域の言葉が存在しています。もはや「Unicodeに移行しなければならない」まで来てしまったというところだと思っています。

Unicodeが完璧だとは思いませんが（CJKの包摂によるフォント・グリフの問題や、特に書記素クラスターは結局左から読むのか…ってなるし複雑）、Unicodeしか選択肢がないというところももはやレガシー文字エンコーディングと化したShift_JISをサポートし続けるというところに限界が来ているのかもしれません。

もちろん、だからといって例えば mb_convert_encoding のような文字コード変換関数が今すぐなくなるとか言うことは多分ありません。intl拡張を司るICUも文字コード変換の機能を持っていますから、後方互換性に関しては保証されると思われます。

なんでこんなことを言い始めたのか

きっかけは、正規表現エンジンである鬼車( https://github.com/kkos/oniguruma )がメンテナンスを終了したことによる、 mb_ereg 系の関数をどうするのかというメーリングリストにあります。鬼車は多分PCREと比較して以下のような特徴があると考えられます

• 様々な文字コードのサポート
• POSIX系の正規表現のサポート

とはいえ、メンテナンスが終了したことで、維持するにはphp-srcに再収録（元々はphp-srcに収録されていたが、pkg-configによって外部ライブラリーとして切り離された）というのは茨の道になることです。鬼車に脆弱性が見つかればPHPのチームが修正することになります。ここまでのメンテナンスコストが果たして必要なのか？というところが上記の動機になります。

あとは、「Shift_JISのほうが日本語の実装が楽」という意見については、低レイヤーガールさんがOS日本語化をUnicodeでやってたことも、もうその説も否定してもいいのではないかと思った次第です。

もうそろそろUnicodeに移行したい：総論

そういうわけでして、文字コードの変換部分は残しつつも、 mb_ereg に代表されるような鬼車のサポートの終了による非推奨化を目指してもいいんじゃないかというふうに思っています。

もうPCRE( preg 系関数 ) を使っているからいいよって思われるか、まだ必要だ、困るということがありましたら教えてくれると助かります、PHP Internalsに投稿します、という記事でした。

2025/07/17 6:55