Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Andreas Heigl]

Hey all.

On 22.12.21 10:00, Rowan Tommins wrote:

On 21/12/2021 23:20, Wade Rossmann wrote:

I would suggest adding optional source/destination encoding parameters to
the functions, eg:

utf8_encode(string $string, string $source_encoding = "ISO-8859-1")
utf8_decode(string $string, string $destination_encoding = "ISO-8859-1")

On 22/12/2021 00:31, Kris Craig wrote:

That's an interesting idea, and definitely worth considering. In the much longer term, we could make the parameter mandatory rather than deprecating the entire function. As you say, the challenge is how to implement the other encodings / what to do if ext/mbstring is not installed. It would be very tempting to support Windows-1252 directly, because it's just a few characters on top of the existing mappings, and is so commonly mistaken for ISO-8859-1. Anything else could then perhaps give a run-time error if ext/mbstring wasn't found. >

Now might be a good time to make this into an RFC.  :)

Regards,

I have a draft kicking around with a lot of analysis of current usage. I will try to pick it back up after Christmas.

To be quite honest: Despite the huge outcry that might provoke: I'd rather remove them today than keep them or deprecate them. And I'd declare the removal as a bug-fix!

Just my 0.02€

Cheers

Andreas
--
                                                              ,,,
                                                             (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andr...@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

Due to the way those functions are currently working they have caused more harm than actually good. One had to very explicitly know what they are doing to use them in the right way. And most certainly when they worked as expected that was more likely due to sheer luck than because someone knew what they were doing. So giving those functions a continued lifetime either as an alias to mb_convert_encoding or by implementing the conversion to/from Windows-1252 would still leave people under the impression that it is a magic function. I'd rather prefer to get rid of them and point people to the proper way of converting one character set to another one with all the possible mishaps that will occur.

OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature