Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130543
Precedence: list
MIME-Version: 1.0
References: <CAEPPVa0YL4Mi2e4T66fNB8F5_QcmKpX4KpAeSbAMGmeyp2L1xw@mail.gmail.com>
 <69C279A1.5040405@adviesenzo.nl> <CAEPPVa3CTSghvNZH6rOaBpksKdsyOpXbG89ExbX9xt1RvSn8Lw@mail.gmail.com>
In-Reply-To: <CAEPPVa3CTSghvNZH6rOaBpksKdsyOpXbG89ExbX9xt1RvSn8Lw@mail.gmail.com>
Date: Fri, 3 Apr 2026 23:57:57 +0900
Message-ID: <CAEPPVa2X-xQE2e3-ARG2Y6UXa5VEg1ff3+d4E0jOZyT3nTDpuA@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=8826=E6=97=A5(=E6=9C=A8) 1:03 youkidearitai <youkidear=
itai@gmail.com>:
>
> 2026=E5=B9=B43=E6=9C=8824=E6=97=A5(=E7=81=AB) 20:46 Juliette Reinders Fol=
mer
> <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 wa=
y. I fully understand that maintaining the Oniguruma library, while it was =
abandoned by the original project is a huge and unenviable task.
> >
> > Having said that, I am very curious what Ruby will be using going forwa=
rd and if PHP could adopt a similar solution.
> > I also wonder if there are no other "blessed" forks of the Oniguruma li=
brary to which PHP could switch.
> > I believe this should be investigated and the results of this investiga=
tion should be added to the RFC to (potentially) strengthen the case for th=
e current proposal, or, depending on the findings, it could be that the cur=
rent proposal could be adjusted based on what this investigation throws up.
> >
> > Secondly, I believe the RFC would benefit from a more detailed section =
about what PHP devs can do to mitigate the deprecation.
> > For example, if the only expected text encoding is UTF-8, people can us=
e `preg_*()` functions with the `u` modifier instead of the `mb_ereg*()` fu=
nctions.
> >
> > I also think it is important to mention that the Symfony Mbstring[1] po=
lyfill 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=
 be 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 ov=
er 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_encodingDeprecat=
ed             25
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregi_replaceDeprecate=
d              20
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replaceDeprecated=
               18
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_matchDeprecated  =
               13
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_initDeprec=
ated           10
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_regsDeprec=
ated           9
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replace_callbackD=
eprecated      6
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_getregsDep=
recated        5
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregDeprecated        =
               4
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_setposDepr=
ecated         4
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregiDeprecated       =
               2
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_posDepreca=
ted            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=
 that most distributed packages will default to/require UTF-8 encoding and =
that code handling non-UTF8 encodings - and therefore needing the Mb regex =
functionality - is mostly found in proprietary packages.
> >
> > The PIE extension would help those packages.
> >
> > Another potential alternative for those packages would be to convert al=
l their data and code to a UTF-8 base, which will be a humongous project fo=
r 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/47ba8b69=
1f82d13dcfe496549c1110d250e18a8c
> > 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 forwa=
rd and if PHP could adopt a similar solution.
> > I also wonder if there are no other "blessed" forks of the Oniguruma li=
brary to which PHP could switch.
> > I believe this should be investigated and the results of this investiga=
tion should be added to the RFC to (potentially) strengthen the case for th=
e current proposal, or, depending on the findings, it could be that the cur=
rent 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
>
> --
> ---------------------------
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -----------------------------

Hi, Internals

I would like to "Voting" phase at next week if there is no any concern.
Next week, re-remind email then go to "Voting" phase at next friday(2026-04=
-10).

If any comment, Feel free to comment.

Regards
Yuya

--=20
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------