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

From: Date: Wed, 14 Dec 2016 03:43:31 +0000
Subject: Req #73716 [Fbk]: PHP 7.1's CHCP switching in console should be optional
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-205983@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73716&edit=1

 ID:                 73716
 Updated by:         yohgaki@php.net
 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:

@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)


Previous Comments:
------------------------------------------------------------------------
[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.

------------------------------------------------------------------------
[2016-12-14 01:28:03] yohgaki@php.net

> console corruption the moment I try this config with newly installed PHP 7.1. Since half the
> extensions can't be loaded.

1) I guess you installed half of extensions under multibyte pathname. Is this correct?

2) I suppose if you locate these extensions to single byte pathname, then they are loaded. Is this
correct?

3) I use Windows version on occasion so I could be wrong, but doesn't multibyte pathname cause
file access problem on older PHPs?

4) Your problem is code page change on Windows, so you are suggesting enable it like

php --chcp some.php

on Windows? (or --chcp-off to disable)

5) In case of abnormal exit, user may execute "chcp CODEPAGE". This could be documentation
problem. Is this enough for you?

------------------------------------------------------------------------
[2016-12-13 19:29:46] anrdaemon at freemail dot ru

"Extensions not loaded" with subsequent process interruption was how I first stumbled upon
this issue. A worst case scenario, if you wish.
I since found the way to reliable trigger it under normal circumstances.
Asking for "reproduction with cmd" isn't fair, CMD itself doesn't update console
buffer in realtime (nor is CMD strictly required to be present, to begin with… 99% of the time
I don't use it at all, running PHP scripts straight from other programs though its
association).

------------------------------------------------------------------------


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


Thread (23 messages)

« previous php.bugs (#205983) next »