Re: [RFC][UNDER DISCUSSION] Oniguruma maintenance end and future of mbregex(End of mbregex)
| From: | youkidearitai | Date: | Fri, 03 Apr 2026 14:57:57 +0000 |
| Subject: | Re: [RFC][UNDER DISCUSSION] Oniguruma maintenance end and future of mbregex(End of mbregex) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130543@lists.php.net to get a copy of this message | ||
2026年3月26日(木) 1:03 youkidearitai <youkidearitai@gmail.com>:
>
> 2026年3月24日(�) 20:46 Juliette Reinders Folmer
> <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 abandoned 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 library to
> > which PHP could switch.
> > I believe this should be investigated and the results of this investigation 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 current 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 use
> >
preg_*() functions with the u
> > modifier instead of the mb_ereg*() functions.
> >
> > I also think it is important to mention that the Symfony Mbstring[1] polyfill 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 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_initDeprecated 10
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_regsDeprecated 9
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replace_callbackDeprecated 6
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_getregsDeprecated 5
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregDeprecated 4
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_setposDeprecated 4
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregiDeprecated 2
> > PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_posDeprecated 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 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/47ba8b691f82d13dcfe496549c1110d250e18a8cÖ6ØcÉ
> > bä@ø\ß‹¼
> > 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 library to
> > which PHP could switch.
> > I believe this should be investigated and the results of this investigation 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 current 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
--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------