|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #72555 CLI output(japanese) on Windows
Submitted: 2016-07-06 17:12 UTC Modified: 2016-12-18 00:15 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: algo13 dot net at gmail dot com Assigned: ab (profile)
Status: Closed Package: CGI/CLI related
PHP Version: Next Minor Version OS: Windows8.1(Japanese editon)
Private report: No CVE-ID: None
 [2016-07-06 17:12 UTC] algo13 dot net at gmail dot com
echo '日本語'; (cp932) with ini_set('default_charset', 'CP932');
=> result 日日本本語語

Test script:
現在のコード ページ: 932

C:\php-7.1.0alpha2-Win32-VC14-x64>type php.ini | findstr "^default_charset"
default_charset = "UTF-8"

C:\php-7.1.0alpha2-Win32-VC14-x64>type iniset.php
ini_set('default_charset', 'CP932');
echo '日本語', PHP_EOL;
/* vim:set fenc=cp932 ff=dos: */

C:\php-7.1.0alpha2-Win32-VC14-x64>php iniset.php



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-07-06 18:07 UTC]
-Assigned To: +Assigned To: ab
 [2016-07-11 13:14 UTC]
-Status: Assigned +Status: Verified
 [2016-07-11 13:14 UTC]
I've investigated so far, and this seems a console issue with the particular codepage. When using php.ini or even "-d default_charset=..." directly, it is fine. A redirection to another program or into a file is also correct.

I currently see no API that would really affect the behavior. Seems when switching the codepage, the console tries to remap chars to another codepage. A simple proof to this theory i made - add the line "fscanf(STDIN, "%s", $dummy);" at the end of the reproduce code. As long as PHP didn't switch back to UTF-8, the output looks correct. 

I suspect, that a similar issue is present on other double byte codepage. With a single byte codepage like 1252, switching codepage on runtime is of a non issue. Currently I can only recommend to use php.ini or -d on console don't switch it, already added a note to UPGRADING. I'm going to keep looking for a solution and keep this ticket open.

 [2016-12-14 02:33 UTC]
-Status: Verified +Status: Feedback
 [2016-12-14 02:33 UTC]
@algo13, a patch landed in 7.1, which implements the separation of the in/out codepage for CLI. Could you please check the latest snapshots? Basically, all that should be needed is setting output_encoding=cp932, while default encoding can stay UTF-8. No default behavior change, though.

 [2016-12-16 22:11 UTC]
@algo13, I come to the point now. It is best described here

DBCS versions of Windows works absolutely different than non-DBCS.
When you run application on DBCS Windows and use double (four) byte codepage (like 932) each CJK takes real two cells. .... the console doubles each CJK (first will have COMMON_LVB_LEADING_BYTE and second - COMMON_LVB_TRAILING_BYTE flag) and you have this glyph in TWO cells, otherwise [A] functions will fail to read 932 codepage!

The only exception is codepage 65001. It uses one unicode (wchar_t) real cell.

This is exactly what happens. One can observe, that when using chcp on a system with default cp 932, that the screen gets cleared every time it is done. It is not for nothing. Of course, the display is not cleared, when ini_set() is called, so it causes the glyph duplication effect. With the new approach now, UTF-8 will be still default, but if you set input_encoding and output_encoding to cp932, the console codepage won't be indeed changed. So you can work with UTF-8 internally, while having 932 on console. Note, that you'll need to care about the automatic I/O conversion, though. 

With this, the issue looks like solved to me.

 [2016-12-18 00:15 UTC]
-Status: Feedback +Status: Closed
 [2016-12-18 00:15 UTC]
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at

 For Windows:
Thank you for the report, and for helping us make PHP better.

The UPGRADING document was updated, please also check the snapshots.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Jul 20 23:01:28 2024 UTC