Hi, Internals
I wrote an RFC that drop support mbregex.
https://wiki.php.net/rfc/eol-oniguruma
I wrote this as one idea.
What do you think?
Regards
Yuya
--
Yuya Hamada (tekimen)
2025年8月22日(金) 9:55 youkidearitai youkidearitai@gmail.com:
Hi, Internals
I wrote an RFC that drop support mbregex.
https://wiki.php.net/rfc/eol-onigurumaI wrote this as one idea.
What do you think?Regards
Yuya--
Yuya Hamada (tekimen)
Hello, internals
I improvement this RFC.
https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions.
What do you think about Oniguruma maintenance ended.
Please watch and feel free to comment.
Regards
Yuya
--
Yuya Hamada (tekimen)
I improvement this RFC.
https://wiki.php.net/rfc/eol-onigurumaAdded more information about maintenance versions.
What do you think about Oniguruma maintenance ended.
Please watch and feel free to comment.
First, thank you for caring about this! I agree that we need a long
term solution for this issue. As I understand it, Oniguruma's greatest
advantage over PCRE2 is that it supports other character encodings than
Unicode and ANSI, so deprecating mbregex might be a problem for some users.
Still, the alternative would likely be to bundle liboniguruma, and I
don't think that would be a good idea. So deprecating mbregex as of PHP
8.6.0 seems prudent; if there would be lots of objections, we could
still reconsider.
Now I wonder how much trouble it would be to separate mbregex from
ext-mbstring. If that can be done with a reasonable amount of work,
that would likely be the best course of action (in addition to
deprecating mbregex). We could than move the extension to PECL/PIE, and
let users deal with it (I'm not happy what happened to ext-imap, but
it's still better than relying on an unmaintained library from a bundled
extension).
Christoph
I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions. What do you think
about Oniguruma maintenance ended. Please watch and feel free to
comment.First, thank you for caring about this! I agree that we need a long
term solution for this issue. As I understand it, Oniguruma's
greatest advantage over PCRE2 is that it supports other character
encodings than Unicode and ANSI, so deprecating mbregex might be a
problem for some users.
Yes, but I think Yuya mentioned somewhere else (I can't find it now) in
an earlier discussion, that many of these users now also moved to UTF-8.
It would also be possible to rewrite these uses from using mbregex to
UConverter::convert+pcre.
Incidently, icu also has a regular expression engine, but of course
that'll operate on UTF-16, and we'd have to create a full new
implementation for that:
Still, the alternative would likely be to bundle liboniguruma, and I
don't think that would be a good idea. So deprecating mbregex as of
PHP 8.6.0 seems prudent; if there would be lots of objections, we
could still reconsider.
I agree with that.
Now I wonder how much trouble it would be to separate mbregex from
ext-mbstring. If that can be done with a reasonable amount of work,
that would likely be the best course of action (in addition to
deprecating mbregex). We could than move the extension to PECL/PIE,
and let users deal with it (I'm not happy what happened to ext-imap,
but it's still better than relying on an unmaintained library from a
bundled extension).
Seeing code like in mbstring.c
#ifdef HAVE_MBREGEX
PHP_MINIT(mb_regex) (INIT_FUNC_ARGS_PASSTHRU);
#endif
And:
php_mbregex.h:PHP_MINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_MSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_RINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_RSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_MINFO_FUNCTION(mb_regex);
makes it feel that it already sort-of operates as a sub-extension, and
it wouldn't be too much work. But it will still be work. Is it worth
it?
cheers,
Derick
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
2025年8月26日(火) 19:15 Derick Rethans derick@php.net:
I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions. What do you think
about Oniguruma maintenance ended. Please watch and feel free to
comment.First, thank you for caring about this! I agree that we need a long
term solution for this issue. As I understand it, Oniguruma's
greatest advantage over PCRE2 is that it supports other character
encodings than Unicode and ANSI, so deprecating mbregex might be a
problem for some users.Yes, but I think Yuya mentioned somewhere else (I can't find it now) in
an earlier discussion, that many of these users now also moved to UTF-8.
It would also be possible to rewrite these uses from using mbregex to
UConverter::convert+pcre.Incidently, icu also has a regular expression engine, but of course
that'll operate on UTF-16, and we'd have to create a full new
implementation for that:Still, the alternative would likely be to bundle liboniguruma, and I
don't think that would be a good idea. So deprecating mbregex as of
PHP 8.6.0 seems prudent; if there would be lots of objections, we
could still reconsider.I agree with that.
Now I wonder how much trouble it would be to separate mbregex from
ext-mbstring. If that can be done with a reasonable amount of work,
that would likely be the best course of action (in addition to
deprecating mbregex). We could than move the extension to PECL/PIE,
and let users deal with it (I'm not happy what happened to ext-imap,
but it's still better than relying on an unmaintained library from a
bundled extension).Seeing code like in mbstring.c
#ifdef HAVE_MBREGEX
PHP_MINIT(mb_regex) (INIT_FUNC_ARGS_PASSTHRU);
#endifAnd:
php_mbregex.h:PHP_MINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_MSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_RINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_RSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_MINFO_FUNCTION(mb_regex);makes it feel that it already sort-of operates as a sub-extension, and
it wouldn't be too much work. But it will still be work. Is it worth
it?cheers,
Derickhttps://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Hi, Internals
I created extension mb_onig that separate mbregex functions.
This package include Oniguruma that my update(Unicode 17.0).
https://packagist.org/packages/mb_onig/mb_onig
(This package is experimental)
With this idea, I think it would be good to separate mbregex.
What do you think?
Regards
Yuya
--
Yuya Hamada (tekimen)
2025年8月26日(火) 19:15 Derick Rethans derick@php.net:
I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions. What do you think
about Oniguruma maintenance ended. Please watch and feel free to
comment.First, thank you for caring about this! I agree that we need a long
term solution for this issue. As I understand it, Oniguruma's
greatest advantage over PCRE2 is that it supports other character
encodings than Unicode and ANSI, so deprecating mbregex might be a
problem for some users.
Which users, exactly?
Where in the wild are people using something other than ANSI, Unicode, and
UTF-8?
Been 10 year since I was involved with a system reliant on Windows-1252,
and the first thing I did after getting hired was to convert it to UTF-8
(Norway, a system written in PHP requiring æøåÆØÅ support running on
Windows-1252~)
2025年8月26日(火) 19:15 Derick Rethans derick@php.net:
I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions. What do you think
about Oniguruma maintenance ended. Please watch and feel free to
comment.First, thank you for caring about this! I agree that we need a long
term solution for this issue. As I understand it, Oniguruma's
greatest advantage over PCRE2 is that it supports other character
encodings than Unicode and ANSI, so deprecating mbregex might be a
problem for some users.Which users, exactly?
Where in the wild are people using something other than ANSI, Unicode, and UTF-8?
Been 10 year since I was involved with a system reliant on Windows-1252, and the first thing I did after getting hired was to convert it to UTF-8
(Norway, a system written in PHP requiring æøåÆØÅ support running on Windows-1252~)
I found this example on Wikipedia view-source:https://kakaku.com/
https://kakaku.com/
2026年3月18日(水) 2:31 Kamil Tekiela tekiela246@gmail.com:
2025年8月26日(火) 19:15 Derick Rethans derick@php.net:
I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions. What do you think
about Oniguruma maintenance ended. Please watch and feel free to
comment.First, thank you for caring about this! I agree that we need a long
term solution for this issue. As I understand it, Oniguruma's
greatest advantage over PCRE2 is that it supports other character
encodings than Unicode and ANSI, so deprecating mbregex might be a
problem for some users.Which users, exactly?
Where in the wild are people using something other than ANSI, Unicode, and UTF-8?
Been 10 year since I was involved with a system reliant on Windows-1252, and the first thing I did after getting hired was to convert it to UTF-8
(Norway, a system written in PHP requiring æøåÆØÅ support running on Windows-1252~)I found this example on Wikipedia view-source:https://kakaku.com/
https://kakaku.com/
Hi
I explain why create mb_onig package.
First, many users reported depends on Oniguruma and mbregex.
For example, Phiki https://github.com/phikiphp/phiki users reported.
https://github.com/php/php-src/pull/19258#issuecomment-3249570139
In Wikipedia, we can see many depends on Oniguruma.
https://en.wikipedia.org/wiki/Oniguruma
Second, FreeBSD supports end Oniguruma in Dec 2026(this year).
https://github.com/php/php-src/pull/19258#issuecomment-3506659061
Therefore, FreeBSD can't compile mbregex after Dec 2026.
I want to avoid it.
Been 10 year since I was involved with a system reliant on Windows-1252, and the first thing I did after getting hired was to convert it to UTF-8
This point is good perspective, Not opensource products maybe depends
mbregex in old codes.
It is maintenance very long time.(My company products depends mbregex)
So I want to maintenance Oniguruma and mbregex other way.
My solution(mb_onig) is one way.
Regards
Yuya
--
Yuya Hamada (tekimen)
2026年3月18日(水) 2:31 Kamil Tekiela tekiela246@gmail.com:
On Tue, 17 Mar 2026 at 17:07, Hans Henrik Bergan divinity76@gmail.com
wrote:On Tue, 17 Mar 2026 at 09:43, youkidearitai youkidearitai@gmail.com
wrote:2025年8月26日(火) 19:15 Derick Rethans derick@php.net:
I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
Added more information about maintenance versions. What do you
think
about Oniguruma maintenance ended. Please watch and feel free to
comment.First, thank you for caring about this! I agree that we need a
long
term solution for this issue. As I understand it, Oniguruma's
greatest advantage over PCRE2 is that it supports other character
encodings than Unicode and ANSI, so deprecating mbregex might be a
problem for some users.Which users, exactly?
Where in the wild are people using something other than ANSI, Unicode,
and UTF-8?Been 10 year since I was involved with a system reliant on
Windows-1252, and the first thing I did after getting hired was to convert
it to UTF-8
(Norway, a system written in PHP requiring æøåÆØÅ support running on
Windows-1252~)I found this example on Wikipedia view-source:https://kakaku.com/
https://kakaku.com/
Wow, you're right, kakaku.com really does run on shift_jis. Neat. (
Kakaku.com runs on C-sharp and ASP.net, not PHP, though:
https://kakaku-techblog.com/entry/compare-rust-with-csharp )
Hi
I explain why create mb_onig package.First, many users reported depends on Oniguruma and mbregex.
For example, Phiki https://github.com/phikiphp/phiki users reported.
https://github.com/php/php-src/pull/19258#issuecomment-3249570139
In Wikipedia, we can see many depends on Oniguruma.
https://en.wikipedia.org/wiki/OnigurumaSecond, FreeBSD supports end Oniguruma in Dec 2026(this year).
https://github.com/php/php-src/pull/19258#issuecomment-3506659061Therefore, FreeBSD can't compile mbregex after Dec 2026.
I want to avoid it.Been 10 year since I was involved with a system reliant on
Windows-1252, and the first thing I did after getting hired was to convert
it to UTF-8
This point is good perspective, Not opensource products maybe depends
mbregex in old codes.
It is maintenance very long time.(My company products depends mbregex)So I want to maintenance Oniguruma and mbregex other way.
My solution(mb_onig) is one way.Regards
Yuya--
Yuya Hamada (tekimen)
I see. Wish you the best of luck.