Den 2021-03-22 kl. 12:12, skrev Rowan Tommins:
Hi Björn,
On 22/03/2021 10:28, Björn Larsson wrote:
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!
I realise you can't speak for anyone else, but as a point of interest,
would you be OK with a polyfill having a requirement on ext/mbstring or
ext/iconv, or would you have a strong preference for a replacement built
into the core (i.e. guaranteed available without any optional packages)?
Regards,
Well, both these extensions are part of our environment so I presume it
will also be so in the future.
Now if we have a polyfill dependent on these libraries it's a question
on how these libraries are maintained and that they are not EOL. Just
speaking from a general point here. I'm in slight favour of mbstring,
since I have a small experience of it.
What's important for us is that the polyfill has a simple API and
doesn't have any surprises / side effects. I think though there is
a case for improving these functions and keep them in the core.
We wrap these functions in one place so it's relatively easy to change
the wrapper to accomodate new functionality in the utf8_* functions as
long as we get the same end result.
I also think one should consider which opensource libraries that are
using these functions. E.g. the Revive ad server v5.2 are using both.
r//Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
