Edit report at https://bugs.php.net/bug.php?id=73716&edit=1
ID: 73716
Comment by: anrdaemon at freemail dot ru
Reported by: anrdaemon at freemail dot ru
Summary: PHP 7.1's CHCP switching in console should be
optional
Status: Feedback
Type: Feature/Change Request
Package: Output Control
Operating System: Windows
PHP Version: 7.1.0
Block user comment: N
Private report: N
New Comment:
Reproduction case?
Get Far manager (+FAR Commands plugin, which is part of standard package -
farmanager.com/download.php ), start PHP 7.1 with internal redirectâ¦
view:<? php -d internal_encoding=utf-8 -r "sleep(3);"
â¦observe console corruption for the duration of script execution.
May be not the most self-container demonstration, but very much visual.
Works equally well with CP437.
Previous Comments:
------------------------------------------------------------------------
[2016-12-13 17:41:51] ab@php.net
@anrdaemon, it would be nice, if you could put your language down to the technical level from your
shame theory. You say " half the extensions can't be loaded" - could you post some
reproduce case for this, that can be debugged?
Thanks.
------------------------------------------------------------------------
[2016-12-13 16:01:03] anrdaemon at freemail dot ru
That's just reinforcing my point, that single-minded pseudosolutions are not going to cut it.
Terminal encoding is a known complex problem, and by now people developed a treasure trove of
knowledge in dealing with it.
Why PHP has to "invent" its own ways? The "one size fits all" approach
didn't quite worked for several last centuries only on my memory. I don't want to see
anyone trying to walk that road only to be covered in shame. Yet again.
------------------------------------------------------------------------
[2016-12-13 07:14:25] yohgaki@php.net
Since you seems to using ISO-8859 compatible encoding, your situation is better than CP932(SJIS).
You can simply use CP866, but CP932 cannot be internal_encoding.
Therefore, we(Japanese) has to use UTF-8/EUC-JP for internal_encoding on Windows. Although, web
input/output conversion can be handled by mbstring/iconv, inputs/outputs have to converted manually,
filenames especially. For this reason, I suppose most Japanese PHP users do not use multibyte
filenames with PHP.
If you could use your code page without problems, I suggest to use it as internal_encoding with CLI.
It's a lot easier.
You may try
cmd.exe /f:on /k "chcp 65001
to use UTF-8 with cmd.exe.
I tried it on my Windows. Japanese filenames (CP932) raised error and stopped "dir"ing. If
all of your filenames are UTF-8, it may work. However, other programs like explorer may have
problems with UTF-8 filenames. (I don't know how your version of Windows behave)
Anyway, feasible resolution for mixed encoding environment that treats various encoding
automagically is very tough subject and use of UTF-8 could be problematic as described above.
------------------------------------------------------------------------
[2016-12-13 05:42:28] anrdaemon at freemail dot ru
Said that, let's take *NIX as example.
When you are writing to terminal in *NIX, you don't suddenly change terminal codepage, you
translate your data from your program's internal codepage to the terminal's one.
Why on earth Windows terminal has to be any different?
I can imagine the time it took for you to write all that text, but it's senseless.
How's "UTF-8 is undesirable"? It IS desirable. Internally. I want my application to
use UTF-8 wherever possible.
Emphasis on "possible". As opposed to "wherever it want regardless of my
expectations".
I'm reading your argumentations and all my reaction is an urge to shake my head in an attempt
to get the wrongs out of it.
------------------------------------------------------------------------
[2016-12-13 05:04:08] anrdaemon at freemail dot ru
World doesn't rotate around PHP, and there's other programs writing to the same console at
the same time.
Which totally do not expect random CP changes.
Least of all, I totally do not expect CP changes from INTERNAL program settings.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=73716
--
Edit this bug report at https://bugs.php.net/bug.php?id=73716&edit=1