Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Testcase
--------

http://bugs.idsl.pl/php/shell_exec.7z


Actual result
-------------

C:\htdocs\wwwroot\a>chcp 1250 
Active code page: 1250

C:\htdocs\wwwroot\a>echo ���� 
����

C:\htdocs\wwwroot\a>chcp 65001 
Active code page: 65001

C:\htdocs\wwwroot\a>echo żółć 
żółć


Expected result
---------------

C:\htdocs\wwwroot\a>chcp 1250 
Active code page: 1250

C:\htdocs\wwwroot\a>echo żółć 
żółć

C:\htdocs\wwwroot\a>chcp 65001 
Active code page: 65001

C:\htdocs\wwwroot\a>echo żółć 
żółć


...because PHP 7.1 introduces "Windows Support" https://github.com/php/php-src/blob/php-7.1.0beta3/UPGRADING

Thanks for the further info. This is not specific to 7.1 changes or shell_exec, however. The content-type header imply, that all of the output is in the given charset.

Specific to 7.1 on Windows is, that the default_charset affects how the filenames are handled, but not the output from an external program. Internally, PHP will convert the given filename to/from UTF-16 using the specified default_charset. If default_charset=UTF-8, any possible filenames can be handled. Otherwise, fe default_charset=cp1250 like in this case, some filenames like Asian or Cyrillic, are likely not to be supported correctly. That will OFC also affect, how the filenames are read to PHP, and how they're output (fe in error messages, etc.). PHP already sends the corresponding headers for server SAPIs, and with 7.1 it also switches to the corresponding codepage on CLI. For instance, notice the length returned:

php.exe -r "$f = 'żółć'; touch($f); var_dump(pathinfo($f)); unlink($f);"
array(3) {
  ["dirname"]=>
  string(1) "."
  ["basename"]=>
  string(8) "żółć"
  ["filename"]=>
  string(8) "żółć"
}

php.exe -d default_charset=cp1250 -r "$f = 'żółć'; touch($f); var_dump(pathinfo($f)); unlink($f);"
array(3) {
  ["dirname"]=>
  string(1) "."
  ["basename"]=>
  string(4) "żółć"
  ["filename"]=>
  string(4) "żółć"
}

The encoding information is vital for Windows, to do the correct conversion of the filename. But, and it is even not Windows specific, not even 7.1 specific, PHP won't convert an output from some program to the default_charset. The recommendation in the UPGRADING tells exactly that - from 7.1 on the script needs to use a homogeneous encoding across all its parts, specifically filenames. Before 7.1, only Window APIs with ANSI codepage support are used, despite default_charset=utf-8.

Thanks.