Bug->Req #73716 [Nab->Opn]: 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 Updated by: requinix@php.net Reported by: anrdaemon at freemail dot ru -Summary: Setting internal_encoding to value different from console CP corrupts console +Summary: PHP 7.1's CHCP switching in console should be optional -Status: Not a bug +Status: Open -Type: Bug +Type: Feature/Change Request Package: Output Control Operating System: Windows PHP Version: 7.1.0 Block user comment: N Private report: N New Comment: Reproduce script: (Windows 10, en_US) >chcp Active code page: 437 >php -r "system('taskkill /f /pid '.getmypid());" >chcp Active code page: 65001 I wouldn't call this a PHP bug because the "normal" exit situations I tried, including fatal errors, would revert the codepage correctly. The problem comes when the PHP process itself quits, so PHP doesn't have a chance to recover and that could cause other issues on its own. Setting the codepage to match the internal_encoding is a net benefit. That said, I think this could be controlled by an INI setting, default enabled. The normal reasons not to add one don't apply here: for example, the value of the setting does not impact code so PHP libraries don't need to detect the setting's value to alter their behavior. If disabled then code still works the same way, but output may be mojibake-d. And if the output is redirected to a file then the setting doesn't even matter at all. So I'm going to convert this to a feature request. Previous Comments: ------------------------------------------------------------------------ [2016-12-12 00:37:24] yohgaki@php.net BTW, I don't think mbstring converts console input. You might want to create feature request for this. ------------------------------------------------------------------------ [2016-12-12 00:34:54] yohgaki@php.net If you would like to convert input/output encoding, you need to use mbstring/iconv module's conversion feature. This isn't enabled by default and you should enabled them by yourself. ------------------------------------------------------------------------ [2016-12-11 21:01:09] anrdaemon at freemail dot ru Description: ------------ When internal_encoding is set (directly, say, internal_encoding=UTF-8, or indirectly through default_charset) to a value different than the current console charset, PHP will change console charset to that value when executing script, leading to visual corruption of the console buffer. This may not look like much of a problem, since it will try to revert the change before ecript ends, but two moments remain: 1. If startup error occured (f.e. extension not found), console CP will not be restored. 2. While script works, console will remain in corrupted state. 3. This is RATHER surprising behavior, especially when you have both input_encoding and output_encoding set to expected (and desired) values. For my example, I have russian Windows with default console charset being CP866. I set the settings for PHP CLI as follows: default_mimetype = "text/plain" ; superfluous for CLI, but still default_charset = "CP866" ; -- // -- input_encoding = "CP866" ; Presume I gonna read console input directly. output_encoding = "CP866" ; I want program messages to be readable. Then I have common shared configuration that sets internal_encoding = "UTF-8" ...since I'm not stupid and prefer to work with data from different sources with least possible chances for corruption. Boom! Console corruption the moment I try this config with newly installed PHP 7.1. Since half the extensions can't be loaded. Yes, a fast run of "chcp" to realize it is turned into CP65001 AKA UTF-8 and a run of "chcp 866" to quickly put it into place, but that's me. I know what I'm looking at. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=73716&edit=1