qychen1982 / crashpad

Automatically exported from code.google.com/p/crashpad
0 stars 0 forks source link

Tools write wide characters to the console #36

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Currently tools emit FilePaths in error messages. This may or may not actually 
do anything useful given the various conversions going on.

Original issue reported on code.google.com by scottmg@chromium.org on 5 May 2015 at 11:10

GoogleCodeExporter commented 9 years ago
Where we actually have a FilePath and print it with PRFilePath, we should be OK 
(but we should check). Where we’re just printing some UTF-8 with %s, we’re 
likely to run into trouble if the UTF-8 contains non-ASCII.

Original comment by mark@chromium.org on 6 May 2015 at 4:36

GoogleCodeExporter commented 9 years ago
I’m sure this isn’t news to you, but this is the best place I could think 
of to put this note:

I found that in the Windows console, printing UTF-16 to standard output with 
PRFilePath works with chcp 65000, and printing UTF-8 with %s works with chcp 
65001. In each case, the font needs to be set to something that provides the 
relevant characters (the default “raster fonts” doesn’t cut it).

Now I see what you meant when you said that the Windows console has sucky 
Unicode support.

Is there any kind of de facto expectation for how a well-behaved command-line 
tool should behave?

Original comment by mark@chromium.org on 7 May 2015 at 7:31

GoogleCodeExporter commented 9 years ago
I messed with _setmode() and _O_U8TEXT, _O_U16TEXT, and _O_WTEXT for a while 
too, but those only work with wide character output functions like wprintf() 
and wfprintf(). They cause the narrow versions to crash.

SetConsoleOutputCP(CP_UTF7) (equivlent to chcp 65000) might fly, it seems to 
let printf("%" PRFilePath "\n", L"\x00e9") do the right thing.

Original comment by mark@chromium.org on 7 May 2015 at 8:09

GoogleCodeExporter commented 9 years ago
"de facto" is "use 32-127" only, AND LIKE IT, I think. (Or actually, 33-127 for 
most tools, if they have any hint of nix heritage because of differences in 
shell escaping).

If any tool was going to work well it'd probably be PowerShell since .NET 
supports Unicode properly from the beginning. x.ps1 containing """Write-Output 
"Hello, é";""" seems to display correctly in 437, 65000, and 65001.

Unfortunately that's not directly helpful for the problem at hand.

cl.exe might also be a good candidate for experimentation, but I didn't play 
with it yet: https://msdn.microsoft.com/en-us/library/xwy0e8f2.aspx

Original comment by scottmg@chromium.org on 7 May 2015 at 8:42