views:

230

answers:

1

My end goal here is to write some non-latin text output to console in Windows via a C++ program.

cmd.exe gets me nowhere, so I got the latest, shiny version of PowerShell (that supports unicode). I've verified that I can

  • type-in non-unicode characters and
  • see non-unicode console output from windows commands (like "dir")

for example, I have this file, "가.txt" (가 is the first letter in the korean alphabet) and I can get an output like this:

PS P:\reference\unicode> dir .\가.txt

    Directory: P:\reference\unicode

Mode                LastWriteTime     Length  
Name                                                       
----                -------------     ------ 
----                                                       
-a---         1/12/2010   8:54 AM          0 가.txt     

So far so good. But writing to console using a C++ program doesn't work.

int main()
{
    wchar_t text[] = {0xAC00, 0}; // 가 has code point U+AC00 in unicode
    wprintf(L"%s", text);  // this prints a single question mark: "?"
}

I don't know what I'm missing. The fact that I can type-in and see 가 on the console seems to indicate that I have the three needed pieces (unicode support, font and glyph), but I must be mistaken.

I've also tried "chcp" without any luck. Am I doing something wrong in my C++ program?

Thanks!

A: 

From the printf docs:

wprintf and printf behave identically if the stream is opened in ANSI mode.

Check out this blog post. It has this nice short little listing:

#include <fcntl.h>
#include <io.h>
#include <stdio.h>

int main(void) {
    _setmode(_fileno(stdout), _O_U16TEXT);
    wprintf(L"\x043a\x043e\x0448\x043a\x0430 \x65e5\x672c\x56fd\n");
    return 0;
}
Keith Hill
Thanks, this was a lot of help. It turns out that specifying _O_U16TEXT works correctly on cmd.exe, but it doesn't on Powershell. I was ripping my hair out until I discovered that setting it to _O_U8TEXT works on Powershell (but with UTF-16 text!). This strikes me as a bug in Powershell, so I submitted a bug to connect.microsoft.com. Don't know if anyone reads it. I hope it's just a simple mixup on their part, rather than something more fundamentally wrong. Again, thanks for your insight on this.
bcx_2000