-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix PHP 8.2 deprecated utf8_encode & utf8_decode #324
Conversation
Removed usages of deprecated functions utf8_decode & utf8_encode
Where can I read about the deprecation? It doesn't appear to be on the docs: https://www.php.net/manual/en/function.utf8-decode.php I'm generally not so hot on adding a polyfill dep. I'd rather just do a |
OK, so this suggests using |
We could but that requires |
It looks like UConverter is bundled by default in php 5.3 or later so that would be a good pick too |
ext/intl is bundled since 5.3 but I believe UConverter wasn't added until later: docs indicate 5.5. Also, I think the reference to intl being "bundled" means only that its source is shipped with PHP's (it was previously a PECL extension), not that it's built by default. That's just to say that mbstring is also a "bundled" extension in the same sense that intl is: both are included in the PHP source distribution and both are not built by default. Actually, ext/intl has an external dependency on ICU, whereas PHP directly includes the dependency library for ext/mbstring, so intl is a little "less bundled" than mbstring is. utf8_encode and _decode are very simple functions since they only support going to/from ISO 8559-1, so you could also feasibly just directly include substitute methods for them... they'd come to something in the tens of lines. |
ok if someone wants to copy paste in the polyfill that's cool too |
I think the simplest solution is to keep using It's also worth noting that the
|
yeah I'm also ok with dumping this support too without iconv |
I tried replacing Edit: that change caused unit tests to fail |
Looks like this was solved by #326, big thanks to @zerocrates. |
Removed usages of deprecated functions
utf8_decode
&utf8_encode
This definitely isn't the way to solve the issue in the long run, but would at least keep backwards compatibility with minimal changes apart from dropping PHP 5.2 support. Removing
utf8_encode
andutf8_decode
completely would require quite a bit of changes to related tests and would also break backwards compatibility.