Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116713
Message-ID: <9e93269e-986f-ffa4-7433-cf2c548a133f@gmail.com>
Date: Wed, 22 Dec 2021 09:00:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Content-Language: en-GB
To: internals@lists.php.net
References: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
 <3a4d89fc-c5f8-4720-b2e0-f6f3c28684f9@www.fastmail.com>
 <CABXx6-y=5-OV2PnOy5f8xr4Nu-=7rkz9c4Q51sfsDj5wb1XJhA@mail.gmail.com>
In-Reply-To: <CABXx6-y=5-OV2PnOy5f8xr4Nu-=7rkz9c4Q51sfsDj5wb1XJhA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
From: rowan.collins@gmail.com (Rowan Tommins)

On 21/12/2021 23:20, Wade Rossmann wrote:
> I would suggest adding optional source/destination encoding parameters to
> the functions, eg:
>
> utf8_encode(string $string, string $source_encoding = "ISO-8859-1")
> utf8_decode(string $string, string $destination_encoding = "ISO-8859-1")


That's an interesting idea, and definitely worth considering. In the 
much longer term, we could make the parameter mandatory rather than 
deprecating the entire function.

As you say, the challenge is how to implement the other encodings / what 
to do if ext/mbstring is not installed. It would be very tempting to 
support Windows-1252 directly, because it's just a few characters on top 
of the existing mappings, and is so commonly mistaken for ISO-8859-1. 
Anything else could then perhaps give a run-time error if ext/mbstring 
wasn't found.


On 22/12/2021 00:31, Kris Craig wrote:
> Now might be a good time to make this into an RFC.  :)


I have a draft kicking around with a lot of analysis of current usage. I 
will try to pick it back up after Christmas.


Regards,

-- 
Rowan Tommins
[IMSoP]