Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113665 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 49507 invoked from network); 22 Mar 2021 13:02:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Mar 2021 13:02:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 31DEF1804F4 for ; Mon, 22 Mar 2021 05:58:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from v-smtpout1.han.skanova.net (v-smtpout1.han.skanova.net [81.236.60.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 22 Mar 2021 05:58:04 -0700 (PDT) Received: from [192.168.7.11] ([213.64.245.126]) by cmsmtp with ESMTPA id OK8AlEuKw3UCOOK8AlTKA4; Mon, 22 Mar 2021 13:58:02 +0100 To: Rowan Tommins References: <3a4d89fc-c5f8-4720-b2e0-f6f3c28684f9@www.fastmail.com> <5f5fd136-e181-d5d3-fe40-1a4cc5c668f2@gmail.com> <25680b8d-af02-c1d4-e630-7bf079881f1c@gmail.com> Cc: PHP internals Message-ID: Date: Mon, 22 Mar 2021 13:58:06 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: sv Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfPdvxbY3ETesmDFN0Q8bwyRy4nYCjPf0DWZxzq7bewO8RQcBEy/mF44R2mGd7QBuUnq50OS0gqCPqjQFr0wpUiwSRyO6AVBAcNdlCbXwZmlO//Bu/THL VkOFX3hH17PTzUDOaztk4d/pnzZL1jN4B6zgoTziE+vEaeUmMMvHHHfrUjVPvRQ5rY0iGm6Sg7iYGPqBTWGveZQoTw9bH0bvYsZtlXeuJberZEz+IZypz5OM 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-22 kl. 12:12, skrev Rowan Tommins: > Hi Björn, > > On 22/03/2021 10:28, Björn Larsson wrote: >> 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! > > > I realise you can't speak for anyone else, but as a point of interest, > would you be OK with a polyfill having a requirement on ext/mbstring or > ext/iconv, or would you have a strong preference for a replacement built > into the core (i.e. guaranteed available without any optional packages)? > > Regards, > Well, both these extensions are part of our environment so I presume it will also be so in the future. Now if we have a polyfill dependent on these libraries it's a question on how these libraries are maintained and that they are not EOL. Just speaking from a general point here. I'm in slight favour of mbstring, since I have a small experience of it. What's important for us is that the polyfill has a simple API and doesn't have any surprises / side effects. I think though there is a case for improving these functions and keep them in the core. We wrap these functions in one place so it's relatively easy to change the wrapper to accomodate new functionality in the utf8_* functions as long as we get the same end result. I also think one should consider which opensource libraries that are using these functions. E.g. the Revive ad server v5.2 are using both. r//Björn L