Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130454
Precedence: list
MIME-Version: 1.0
References: <CAEPPVa0YL4Mi2e4T66fNB8F5_QcmKpX4KpAeSbAMGmeyp2L1xw@mail.gmail.com>
 <69C279A1.5040405@adviesenzo.nl>
In-Reply-To: <69C279A1.5040405@adviesenzo.nl>
Date: Thu, 26 Mar 2026 01:03:32 +0900
Message-ID: <CAEPPVa3CTSghvNZH6rOaBpksKdsyOpXbG89ExbX9xt1RvSn8Lw@mail.gmail.com>
Subject: Re: [PHP-DEV][RFC][UNDER DISCUSSION] Oniguruma maintenance end and
 future of mbregex(End of mbregex)
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: youkidearitai@gmail.com (youkidearitai)

2026=E5=B9=B43=E6=9C=8824=E6=97=A5(=E7=81=AB) 20:46 Juliette Reinders Folme=
r
<php-internals_nospam@adviesenzo.nl>:
>
> On 23-3-2026 1:34, youkidearitai wrote:
>
> Hi, Internals
>
> I decide deprecate mbregex in 8.6 and drop in 9.0.
> So I would like to go to Under Discussion phase.
> https://wiki.php.net/rfc/eol-oniguruma
> https://github.com/php/php-src/pull/21490
>
>
> Thank you for writing this RFC. I don't have a strong opinion either way.=
 I fully understand that maintaining the Oniguruma library, while it was ab=
andoned by the original project is a huge and unenviable task.
>
> Having said that, I am very curious what Ruby will be using going forward=
 and if PHP could adopt a similar solution.
> I also wonder if there are no other "blessed" forks of the Oniguruma libr=
ary to which PHP could switch.
> I believe this should be investigated and the results of this investigati=
on should be added to the RFC to (potentially) strengthen the case for the =
current proposal, or, depending on the findings, it could be that the curre=
nt proposal could be adjusted based on what this investigation throws up.
>
> Secondly, I believe the RFC would benefit from a more detailed section ab=
out what PHP devs can do to mitigate the deprecation.
> For example, if the only expected text encoding is UTF-8, people can use =
`preg_*()` functions with the `u` modifier instead of the `mb_ereg*()` func=
tions.
>
> I also think it is important to mention that the Symfony Mbstring[1] poly=
fill package does **NOT** polyfill the MB regex functionality, so cannot be=
 used as a replacement/alternative.
>
> With this in mind, I also believe the impact analysis in the RFC should b=
e expanded as the MbString extension is widely used.
>
> To support this, I've created a branch in the PHPCompatibility package [2=
] specifically for this deprecation and I have run the relevant checks over=
 the Packagist Top 4000 (as of yesterday).
>
> I've posted the used ruleset and the full results as a gist.
> https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214
>
> Summary of findings:
>
> PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
> -------------------------------------------------------------------------=
------------------
> SOURCE                                                                   =
             COUNT
> -------------------------------------------------------------------------=
------------------
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_splitDeprecated         =
             30
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_regex_encodingDeprecated=
             25
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregi_replaceDeprecated =
             20
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replaceDeprecated  =
             18
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_matchDeprecated    =
             13
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_initDeprecat=
ed           10
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_regsDeprecat=
ed           9
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replace_callbackDep=
recated      6
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_getregsDepre=
cated        5
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregDeprecated          =
             4
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_setposDeprec=
ated         4
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregiDeprecated         =
             2
> PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_posDeprecate=
d            1
> -------------------------------------------------------------------------=
------------------
> A TOTAL OF 147 SNIFF VIOLATIONS WERE FOUND IN 13 SOURCES
> -------------------------------------------------------------------------=
------------------
>
> So, 147 occurances in the Packagist top 4000 in total.
>
> While this is lower than I would have expected, it should be remembered t=
hat most distributed packages will default to/require UTF-8 encoding and th=
at code handling non-UTF8 encodings - and therefore needing the Mb regex fu=
nctionality - is mostly found in proprietary packages.
>
> The PIE extension would help those packages.
>
> Another potential alternative for those packages would be to convert all =
their data and code to a UTF-8 base, which will be a humongous project for =
most (and that deserves a mention in the RFC).
>
> Hope this helps.
>
> Smile,
> Juliette
>
>
> 1: https://symfony.com/packages/polyfill-mbstring
> 2: https://github.com/PHPCompatibility/PHPCompatibility/commit/47ba8b691f=
82d13dcfe496549c1110d250e18a8c
> 3: https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214

Hi, Juliette

Thank you very much for your gist.
I saw your gist, seems like depends mbregex(Oniguruma).

> Having said that, I am very curious what Ruby will be using going forward=
 and if PHP could adopt a similar solution.
> I also wonder if there are no other "blessed" forks of the Oniguruma libr=
ary to which PHP could switch.
> I believe this should be investigated and the results of this investigati=
on should be added to the RFC to (potentially) strengthen the case for the =
current proposal, or, depending on the findings, it could be that the curre=
nt proposal could be adjusted based on what this investigation throws up.

Indeed, There is a Onigmo in
Ruby(https://github.com/ruby/ruby/blob/master/regexec.c) that fork
from Oniguruma.
There are Onigmo and Oniguruma differences.

I wrote your feedback to RFC.
And I quoted your gist result. Please let me know if there is any problem.
Thank you again.

Regards
Yuya

--=20
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------