2026年3月26日(木) 1:03 youkidearitai <[email protected]>:
>
> 2026年3月24日(火) 20:46 Juliette Reinders Folmer
> <[email protected]>:
> >
> > 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
> > 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
-----------------------------

Reply via email to