Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113691
MIME-Version: 1.0
References: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
 <CAESVnVoa2U1ZCsthWCt8Cu8Es-P8WWO=vky4TG5CmtaoumEmUA@mail.gmail.com>
 <e120bf6b-12cd-5b3e-b27c-b746d1a1661b@gmail.com> <CAESVnVqJh3oOM-5CkatiUctRupOdS7mce7QYzv3uxUb3QcpHWw@mail.gmail.com>
 <693767b5-a25b-b4d9-f535-6b985bf26d67@gmail.com> <29d5329c-bea2-7944-4820-515d4a10ae86@alec.pl>
 <16ecfc31-33aa-4223-fb67-b5a4b5895f05@gmail.com> <11e9a312-ed10-412e-506d-ccf9f24457f8@alec.pl>
In-Reply-To: <11e9a312-ed10-412e-506d-ccf9f24457f8@alec.pl>
Date: Mon, 22 Mar 2021 19:24:34 +0200
Message-ID: <CAAwdEzBYXgDj_Do_LPeZXaMnjeLZcjPQmo+u2wTNFLfttoyzQw@mail.gmail.com>
To: Aleksander Machniak <alec@alec.pl>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f28e7a05be2357c7"
Subject: Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000f28e7a05be2357c7
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 22, 2021 at 6:52 PM Aleksander Machniak <alec@alec.pl> wrote:

> On 22.03.2021 16:41, Rowan Tommins wrote:
> > That code will never do anything useful.
>
> I already proved it is useful, regardless of it's name/intention.
>
> This is old code, not even mine, so maybe when it's been written the PHP
> documentation wasn't that clear about the function(s) intention. Or the
> intention was different.
>
> ps. to Kamil,
>
> We use utf8_encode() to make the string safe to be put in utf-8 database
> column/table. We use utf8_decode() to convert that back to what it was
> before.
>

I just searched and found a hotfix I did a few years ago (when I was also
dumber) and the fix was just adding a utf8_encode to some data received in
$_POST before being sent to a logging service. And a utf8_decode after
reading it for further parsing.
The logging service storage was using a mysql database and the specific
column was declared `TEXT` instead of `BLOB`.
Apparently the fix is still in place.


>
> The tests prove that the conversion is lossless.
>

There could have been better ways to fix it.
json_encode / json_decode would have worked just the same.

The problem was that the quickly identified cause was a non-utf8 string
trying to be stored in an utf8 text column and the solution was implemented
based on the fact that utf8_decode/encode sounded like a good idea when
time is limited; and also knowledge in my case.
I think it would be great to deprecate them somehow.

Regards,
Alex

--000000000000f28e7a05be2357c7--