Re: Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
| From: | Hans Henrik Bergan | Date: | Tue, 28 Nov 2023 22:40:40 +0000 |
| Subject: | Re: Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ? | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121832@lists.php.net to get a copy of this message | ||
btw if we come to some consensus to my php2utf8.php script is actually
worthwhile to expand on, i can volunteer to add more encodings (SJIS,
BIG5, anything supported by mbstring),
but it wouldn't surprise me if a better approach exist and the script
should be rewritten entirely~
>add that what's special about UTF-8 isn't that it's "fixed-endian".
should've added this to the last post, but the "zend.detect_unicode"
ini-option is specifically to scan for BOMs, and BOMs are
significantly less useful in fixed-endian encodings (like UTF8) than
bi-endian encodings (like UTF16/UTF32) ^^
On Tue, 28 Nov 2023 at 21:47, Hans Henrik Bergan <divinity76@gmail.com> wrote:
>
> > 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 à 20:56, Kamil Tekiela <tekiela246@gmail.com> a écrit :
> > >
> > >> 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 change the contents of the strings.
> >
> > —Claude
> >