Req #73716 [Com]: PHP 7.1's CHCP switching in console should be optional

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: @yohgaki, no, the answer is way simpler. The path to PHP binaries is not only non-unicode, it is rather short and not containing spaces. I just didn't bothered to properly install extensions for the first run. Extensions relied on external DLL's crashed the party and I noticed broken console. @ab, you are not sure about Far Manager because it's a good program? :) Jokes aside, I checked 7.1.r33e96c9 and it no longer corrupts console when changing internal_encoding. There's some related behavior I'm chasing, but present issue is now resolved. As a fallout of our discussion, I feel the issue needs a deeper revision and a clearer definition of meaning for each of the four settings. Ideally, an automatic conversion between encodings, where it is sensible. Where it is more appropriate to discuss these parts of PHP behavior? Previous Comments: ------------------------------------------------------------------------ [2016-12-14 18:09:57] ab@php.net On my side - when i switch to "Japanese (Japan)" as system codepage, so it's 932, "MS ゴシック" is the default console font. The empty boxes would indeed appear on cmd, if the system codepage is an incompatible one and the font contains no glyphs. For example, with chcp 437 it even won't let to chcp 932 or others multibyte codepages, and with 65001 the Japanese glyphs are still missing. For that case however, a custom font can be installed for the console, that contains more glyphs. Or, some more advanced console emulator can be used. Probably can be more of effort with Far, as to see, but ConEmu showed me the most of Glyphs I reqired while writing tests on the machine with 437 system codepage. There are many other good term emulators out there, but we still should be cmd.exe oriented. Thanks for checking, Yasuo. @algo13 was also supporting the development by checks and hints, that's where #72555 came from. One or another not critical issue is still present unfortunately, but the main goal is still to improve and extend the UTF-8 support, not moving back into the stone age of ANSI. Thanks. ------------------------------------------------------------------------ [2016-12-14 03:43:29] yohgaki@php.net @anatol It is known for Japanese that console (cmd.exe and powershell) font should be "MS ゴシック" (MS Gothic) to work with UTF-8/UTF-16. So I tried to set it to "MS ゴシック" on my Windows 10/7, but there is no choice for "MS ゴシック" only "Consolas"(TrueType), "Lucida Console"(TrueType) and "ラスターフォント"(Raster Font - Non TrueType). Recent versions of Windows seems only predefined and associated fonts for the codepage are selectable. Raster Font doesn't work (got "The system cannot write to the specified device." error with Japanese file name), TrueType fonts work but no Japanese font(Glyph) and got □ (Tofu - glyph not found) for Japanese characters. However, it is encoded correctly so copy&pasted from console is readable(correct, not broken text) in UTF aware editor/etc. Even if there is font issue for console, but it seems PHP 7.1 should work well. (Much better than older PHP at least for Japanese users) ------------------------------------------------------------------------ [2016-12-14 02:47:11] ab@php.net Ups, bug #72555 is what i wanted to mention. Thanks. ------------------------------------------------------------------------ [2016-12-14 02:45:32] ab@php.net Related To: Bug #73716 ------------------------------------------------------------------------ [2016-12-14 02:45:30] ab@php.net @anrdaemon, i'm really not sure about Far manager - it is a good software, and it also can support Unicode. Any program can update codepage at runtime, but that's not going to work well, especially if no TrueType font is used. Nevertheless, I've pushed a patch to support output_encoding different from the internal one, please test latest snapshots. There is no default behavior change. You can experience any kind of mojibake, if you work internally with the encoding different from the output, but that is your responsibility then. Yasuo, I've also asked teh reporter in bug #73716 to check the usecase with Japanese locale. To the times I was testing the multibyte implementation, I was able to verify it and it seems a quite weird issue with both codepage and the font. I guess, this can also fix issues with similar multibyte codepages, however i saw not reports yet. I'm going to document the crashing case in the UPGRADING, and also the changes done in this patch, if it goes well. Thanks. ------------------------------------------------------------------------ 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