Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113652
MIME-Version: 1.0
References: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
 <3a4d89fc-c5f8-4720-b2e0-f6f3c28684f9@www.fastmail.com> <5f5fd136-e181-d5d3-fe40-1a4cc5c668f2@gmail.com>
In-Reply-To: <5f5fd136-e181-d5d3-fe40-1a4cc5c668f2@gmail.com>
Date: Sun, 21 Mar 2021 19:08:02 +0000
Message-ID: <CAGBsUrcsms0TfnwnrjyaugmDd549gHbTTDj+VoR1sPzm9-8TGw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b3baaa05be10abfb"
Subject: Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
From: tekiela246@gmail.com (Kamil Tekiela)

--000000000000b3baaa05be10abfb
Content-Type: text/plain; charset="UTF-8"

Option A, please.

I have never had a reason to use either of these two functions. I assume
there's plenty of valid applications for converting between ISO-8859-1 and
UTF-8, but that function causes more harm than good.
I have seen plenty of people use it, but I have never seen anyone use it
properly. Most of the time people use it to fix their mojibake text when
they forget to set the connection charset in PDO or mysqli. I was a little
surprised to learn that these functions had something to do with XML.

The reason why I consider them dangerous is that people using them are most
likely solving the wrong problem. The problem isn't the conversion from ISO
to UTF but having the text in the wrong format in the first place. They are
used as some kind of magical solution that fixes an annoying problem. I
would have no quarrel with them if they were named correctly though.
Another reason why I do not like these functions is that they let you shoot
yourself in the foot very easily. They don't warn about invalid or missing
code points, which often leads to more data corruption. When doing the same
with ICONV you at least get a notice.

I think we really do not need to keep these functions. As for the
alternative that we can offer, iconv seems to be doing exactly the same
thing and even better. mb_convert_encoding does the same but also silently
ignores invalid characters. So we already offer plenty of alternatives. We
don't need to add anything new.

-- Kamil

--000000000000b3baaa05be10abfb--