|
|
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » [solved] TheIDE "Run Options..." bug
[solved] TheIDE "Run Options..." bug [message #43621] |
Mon, 15 September 2014 16:01 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
I spent the better part of the day trying to find out why when selecting Standard output: File from TheIDE with an application that sets UTF8 (UTF16 does not work for me in the console) as a console output I got gibberish.
At first I blamed Windows API, but ultimately I discovered that TheIDE introduces those extra characters.
If the code that invokes the .exe is able to detect that the output is UTF8 it should interpret the data as such. If this is not possible, we need a new option Standard Output: UTF8 File.
[Updated on: Tue, 03 January 2017 12:00] Report message to a moderator
|
|
|
|
Re: TheIDE "Run Options..." bug [message #43625 is a reply to message #43624] |
Mon, 15 September 2014 19:16 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
During my day of testing, I found that it is near impossible to write Utf16 to the console and maintain the ability to reroute the output.
Also what I found on Google suggests that the only way it works (and it does; I tested) is to set Utf8 console output and write raw Utf8 without BOM.
My API is almost identical to Cout().
So while Cout may be changed, just adding an option for TheIDE to not convert that output to whatever encoding it uses should help.
Currently, I can reproduce with these test cases:
1. Cout() like stream, Utf8 console, Utf8 write, Run from TheIDE on cmd.exe. Works.
2. Cout() like stream, Utf8 console, Utf8 write, Run from cmd.exe with redirection (i.e. text.exe > out.txt). Works.
3. Cout() like stream, Utf8 console, Utf8 write, Run from with "File" option. Does not work.
AFAIK WriteConsole does not redirect. It did not for me.
[Updated on: Mon, 15 September 2014 19:17] Report message to a moderator
|
|
|
|
|
|
|
Re: TheIDE "Run Options..." bug [message #43673 is a reply to message #43652] |
Fri, 19 September 2014 11:02 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
[quote title=mirek wrote on Thu, 18 September 2014 08:47]
Can you show me the code please? I know it sounds trivial, but there are more interpretations to this...
[quote title=Quote:]
That's not that easy since technically I am not written C++ code .
Anyway, here is a bare bones WinAPI sequence that prints thing as expected:
SetConsoleOutputCP(65001);
uint8 s[] = { 0xC3, 0x80 };
uint8* h = GetStdHandle(4294967285u);
uint32 dummy = 0u;
WriteFile(h, s, 2, &(dummy), 0);
The console is set to UTF8. The À (0xC0) codepoint is encoded with two Utf8 code units 0xC3, 0x80. Now, if the console is set to use a non-bitmap font, it will work very well with a wide range of characters. If the character is not supported, one or more empty little rectangles are rendered. The good news is that you can copy&paste them and the correct information is preserved.
So technically if the String is Utf8, it should work. It works in my code and even with Utf8 U++ Strings prior to your changes. But TheIDE/LocalProcess messes up these values.
I did not manage to encode À as 0x00C0 (or even 0xC000) in Utf16 and send it to the console. Google seems to suggest that the console is inherently 8bit.
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Nov 01 01:02:29 CET 2024
Total time taken to generate the page: 0.07241 seconds
|
|
|