Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121831
MIME-Version: 1.0
References: <CAJmy8YFy5RmW1yWuA6akPU31xRz_i1io5uWgt1GWo0n5rzY9EQ@mail.gmail.com>
 <1BA05C1A-AFAE-4E86-BAA2-420B22549519@gmail.com> <0D8856BC-DDEE-47F8-8C59-7F4DC7A64237@woofle.net>
 <CAGBsUrd=5WhKERySavP=9yQM-RSkVCwhTJ2oQ4tAQOKTNFoCew@mail.gmail.com> <A00495F3-EEB5-4D49-9433-84E94C6920D0@gmail.com>
In-Reply-To: <A00495F3-EEB5-4D49-9433-84E94C6920D0@gmail.com>
Date: Tue, 28 Nov 2023 21:47:59 +0100
Message-ID: <CAJmy8YG91ki8M-n7id=DUDUsG+1XBvtpSNdf6sJx3Y1B1Rytsg@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Kamil Tekiela <tekiela246@gmail.com>, Dusk <dusk@woofle.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte +
 zend.script_encoding + zend.detect_unicode ?
From: divinity76@gmail.com (Hans Henrik Bergan)

> What is the migration path for legacy code that use those directives?

The migration path is to convert the legacy-encoding PHP files to UTF-8.
Luckily this can be largely automated, here is my attempt:
https://github.com/divinity76/php2utf8/blob/main/src/php2utf8.php
but that code definitely needs some proof-reading and additions - idk
if the approach used is even a good approach, it was just the first i
could think of, feel free to write one from scratch


>Can you share a little more details about how this works?

I hope someone else can do that, but it allows PHP to parse and
execute scripts not written in UTF-8 and scripts utilizing
BOM/byte-order-masks.

>add that what's special about UTF-8 isn't that it's "fixed-endian".

one of multiple good things about UTF-8 is that it's fixed-endian, and
UTF8 don't need a BOM to specify endianess (unlike UTF16 and UTF32
which are bi-endian, and a BOM helps identify endianess used~)

>If the solution is as easy as just converting the encoding of the
source file, then why did we even need to have this setting at all?
Why did PHP parser support encodings that demanded the introduction of

I've read your question but don't have an answer to it, hopefully
someone else knows.


On Tue, 28 Nov 2023 at 21:09, Claude Pache <claude.pache@gmail.com> wrote:
>
>
>
> > Le 28 nov. 2023 =C3=A0 20:56, Kamil Tekiela <tekiela246@gmail.com> a =
=C3=A9crit :
> >
> >> Convert your PHP source files to UTF-8.
> >
> > If the solution is as easy as just converting the encoding of the
> > source file, then why did we even need to have this setting at all?
> > Why did PHP parser support encodings that demanded the introduction of
> > this declare?
>
> It is not necessary as simple: because your code base may contain literal=
 strings, and changing the encoding of the source file will effectively cha=
nge the contents of the strings.
>
> =E2=80=94Claude
>