Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130429
Subject: Re: [PHP-DEV][RFC][UNDER DISCUSSION] Oniguruma maintenance end and
 future of mbregex(End of mbregex)
To: youkidearitai <youkidearitai@gmail.com>,
 php internals <internals@lists.php.net>
References: <CAEPPVa0YL4Mi2e4T66fNB8F5_QcmKpX4KpAeSbAMGmeyp2L1xw@mail.gmail.com>
Message-ID: <69C279A1.5040405@adviesenzo.nl>
Date: Tue, 24 Mar 2026 12:46:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <CAEPPVa0YL4Mi2e4T66fNB8F5_QcmKpX4KpAeSbAMGmeyp2L1xw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------050706080204000506010308"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------050706080204000506010308
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------050706080204000506010308
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 23-3-2026 1:34, youkidearitai wrote:<br>
    </div>
    <blockquote
cite="mid:CAEPPVa0YL4Mi2e4T66fNB8F5_QcmKpX4KpAeSbAMGmeyp2L1xw@mail.gmail.com"
      type="cite">
      <pre wrap="">Hi, Internals

I decide deprecate mbregex in 8.6 and drop in 9.0.
So I would like to go to Under Discussion phase.
<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/eol-oniguruma">https://wiki.php.net/rfc/eol-oniguruma</a>
<a class="moz-txt-link-freetext" href="https://github.com/php/php-src/pull/21490">https://github.com/php/php-src/pull/21490</a>
</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    Having said that, I am very curious what Ruby will be using going
    forward and if PHP could adopt a similar solution.<br>
    I also wonder if there are no other "blessed" forks of the Oniguruma
    library to which PHP could switch.<br>
    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.<br>
    <br>
    Secondly, I believe the RFC would benefit from a more detailed
    section about what PHP devs can do to mitigate the deprecation.<br>
    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.<br>
    <br>
    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.<br>
    <br>
    With this in mind, I also believe the impact analysis in the RFC
    should be expanded as the MbString extension is widely used.<br>
    <br>
    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).<br>
    <br>
    I've posted the used ruleset and the full results as a gist.<br>
    <a class="moz-txt-link-freetext" href="https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214">https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214</a><br>
    <br>
    Summary of findings:<br>
    <br>
    PHP CODE SNIFFER VIOLATION SOURCE SUMMARY<br>
    <tt>-------------------------------------------------------------------------------------------</tt><tt><br>
    </tt><tt>SOURCE                                                                               
      COUNT</tt><tt><br>
    </tt><tt>-------------------------------------------------------------------------------------------</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_splitDeprecated                     
      30</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_regex_encodingDeprecated            
      25</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregi_replaceDeprecated             
      20</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replaceDeprecated              
      18</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_matchDeprecated                
      13</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_initDeprecated          
      10</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_regsDeprecated          
      9</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_replace_callbackDeprecated     
      6</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_getregsDeprecated       
      5</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregDeprecated                      
      4</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_setposDeprecated        
      4</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_eregiDeprecated                     
      2</tt><tt><br>
    </tt><tt>PHPCompatibility.FunctionUse.RemovedFunctions.mb_ereg_search_posDeprecated           
      1</tt><tt><br>
    </tt><tt>-------------------------------------------------------------------------------------------</tt><tt><br>
    </tt><tt>A TOTAL OF 147 SNIFF VIOLATIONS WERE FOUND IN 13 SOURCES</tt><tt><br>
    </tt><tt>-------------------------------------------------------------------------------------------</tt><br>
    <br>
    So, 147 occurances in the Packagist top 4000 in total.<br>
    <br>
    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.<br>
    <br>
    The PIE extension would help those packages.<br>
    <br>
    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).<br>
    <br>
    Hope this helps.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    <br>
    1: <a class="moz-txt-link-freetext" href="https://symfony.com/packages/polyfill-mbstring">https://symfony.com/packages/polyfill-mbstring</a><br>
    2:
<a class="moz-txt-link-freetext" href="https://github.com/PHPCompatibility/PHPCompatibility/commit/47ba8b691f82d13dcfe496549c1110d250e18a8c">https://github.com/PHPCompatibility/PHPCompatibility/commit/47ba8b691f82d13dcfe496549c1110d250e18a8c</a><br>
    3: <a class="moz-txt-link-freetext" href="https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214">https://gist.github.com/jrfnl/bd0f66f1c185930427db4f093babf214</a><br>
  </body>
</html>

--------------050706080204000506010308--