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