Den 2021-03-21 kl. 22:39, skrev Rowan Tommins:
On 21/03/2021 21:00, Max Semenik wrote:
Just a quick reminder that it's possible to compile PHP without
mbstring and intl, which means that some hosts will provide PHP
without these extensions, and some packagers make them available as
separate packages that users can't or don't know how to install. Maybe
we've got an opportunity to think about making these extensions
mandatory?
It's somewhat relevant that until PHP 7.2, it was also possible for
utf8_encode and utf8_decode to be missing, because they were in ext/xml,
which is also optional.
Bundling mbstring sounds great, until you look into the details of
what's in there and how it works. Its origin as a PHP 4 extension for
handling Japanese-specific character encodings is visible in parts of
its design - there's a lot of global state, and very little support for
the nuances of Unicode.
Bundling intl would be great, but it's a wrapper around ICU, which is
huge (because Unicode is complicated). I have read that incorporating
that into core was one of the icebergs that sunk PHP 6. It's also
extremely sparsely documented (if someone's looking for a project, it
would be great to fill in all the manual stubs with a few details from
the corresponding ICU documentation).
For what its worth, it seems these would be the relevant polyfills:
function utf8_encode(string $string) { return
UConverter::transcode($string, 'UTF8', 'ISO-8859-1'); }
function utf8_decode(string $string) { return
UConverter::transcode($string, 'ISO-8859-1', 'UTF8'); }
Regards,
In our case we use the utf8_decode functions to convert from UTF8 in
the client to ISO-8859-1 on the server, since the site is encoded in
latin1.
Our usage of that function is working flawlessly, so for us it's super
important to have a clear migration path with a good polyfill!
r//Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
