Re: Console codepage setting via chcp?

["andy.koppe" <andy dot koppe at gmail dot com>]

2009/9/24 Corinna Vinschen:
> Unfortunately there's another problem when utilizing the Console
> codepage. ÂWhile testing I found that I was unable to switch the console
> codepage to 932, even though the codepage 932 is installed, and
> MultiByteToWideChar and WideCharToMultiByte both work fine using that
> charset. ÂSame for 936, 949, and 950. ÂSetConsoleOutputCP() fails with
> ERROR_INVALID_PARAMETER.
>
> I asked on the microsoft newsgroup m.p.w.p.kernel and the replies
> suggested that it's possible to use the codepages in the console only
> when switching the system default locale to an appropriate language.
>
> So I switched the default system locale to Japanese, rebooted, and when
> starting my shell in a console window, my default codepage was set to
> 932. ÂNow I could use 932, but 936, 949, and 950 were still invalid. ÂSo
> I switched to Chinese, rebootedd and, voila, I was able to use codepage
> 950. ÂThen I switched back to English, rebooted and, voila, 932 and 950
> were both invalid again.
>
> Given that in the Japanese and Chinese locale all other singlebyte
> codepages are still available, I have a hard time to understand the
> scheme behind this.

Dissuading people from using DBCSs? Can't blame 'em.


> Do you think this is a problem? ÂIt's certainly an annoyance when
> testing locale-specific changes, but is it relevant to users?

Difficult to imagine. If it is, there are workarounds: setting the
console to UTF-8 and using luit for conversion. Or using another
terminal.


> Last but not least, the alternative would be to store the Console
> character set as an environment variable, just as the
> "CYGWIN=codepage:[ansi:oem]" setting back in 1.5 times. ÂSigh.

Hmm. How about simply using the standard locale variables again?
Except unlike now the console charset would be set at startup rather
than by setlocale.

Andy