On Mon, Mar 22, 2021 at 6:52 PM Aleksander Machniak <a...@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
