> 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.pa...@gmail.com> wrote: > > > > > Le 28 nov. 2023 à 20:56, Kamil Tekiela <tekiela...@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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
