Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113661
To: Rowan Tommins <rowan.collins@gmail.com>
References: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
 <3a4d89fc-c5f8-4720-b2e0-f6f3c28684f9@www.fastmail.com>
 <5f5fd136-e181-d5d3-fe40-1a4cc5c668f2@gmail.com>
 <CAGBsUrcsms0TfnwnrjyaugmDd549gHbTTDj+VoR1sPzm9-8TGw@mail.gmail.com>
 <CAGgaK7LDeX0nGggpQbNROD91Mgg=g0RJTvpP5d47yEYzjOR1hA@mail.gmail.com>
 <25680b8d-af02-c1d4-e630-7bf079881f1c@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <f355da8e-b982-2cba-03d1-0e0dc0721faf@telia.com>
Date: Mon, 22 Mar 2021 11:28:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <25680b8d-af02-c1d4-e630-7bf079881f1c@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: sv
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2021-03-21 kl. 22:39, skrev Rowan Tommins:
> On 21/03/2021 21:00, Max Semenik wrote:
>> Just a quick reminder that it's possible to compile PHP without 
>> mbstring and intl, which means that some hosts will provide PHP 
>> without these extensions, and some packagers make them available as 
>> separate packages that users can't or don't know how to install. Maybe 
>> we've got an opportunity to think about making these extensions 
>> mandatory?
> 
> 
> It's somewhat relevant that until PHP 7.2, it was also possible for 
> utf8_encode and utf8_decode to be missing, because they were in ext/xml, 
> which is also optional.
> 
> Bundling mbstring sounds great, until you look into the details of 
> what's in there and how it works. Its origin as a PHP 4 extension for 
> handling Japanese-specific character encodings is visible in parts of 
> its design - there's a lot of global state, and very little support for 
> the nuances of Unicode.
> 
> Bundling intl would be great, but it's a wrapper around ICU, which is 
> huge (because Unicode is complicated). I have read that incorporating 
> that into core was one of the icebergs that sunk PHP 6. It's also 
> extremely sparsely documented (if someone's looking for a project, it 
> would be great to fill in all the manual stubs with a few details from 
> the corresponding ICU documentation).
> 
> For what its worth, it seems these would be the relevant polyfills:
> 
> function utf8_encode(string $string) { return 
> UConverter::transcode($string, 'UTF8', 'ISO-8859-1'); }
> function utf8_decode(string $string) { return 
> UConverter::transcode($string, 'ISO-8859-1', 'UTF8'); }
> 
> 
> Regards,
> 

In our case we use the utf8_decode functions to convert from UTF8 in
the client to ISO-8859-1 on the server, since the site is encoded in
latin1.

Our usage of that function is working flawlessly, so for us it's super
important to have a clear migration path with a good polyfill!

r//Björn L