UTF-8 input/output still a problem. QEMU console case. about terminal HOT 4 CLOSED

Footnotes

1. "chcp.com" is a console application that sets the console's input and output code pages to a given code page via SetConsoleCP(codePageID) and SetConsoleOutputCP(codePageID). This command, as well as "mode.com", were implemented in 1993 for the Windows NT console to emulate the builtin CHCP and MODE commands in the MS-DOS COMMAND.COM shell from back in the 1980s. However, the emulated commands a far cry from the original MS-DOS commands, which controlled not only device code pages but also synchronized the locale (e.g. names of days/months, format characters) and UI language (e.g. system messages and UI text) in the MS-DOS kernel.
   
   The console code page on Windows NT systems has nothing to do with the locale or UI language in use by a console application. Windows applications can use the default user locale and UI language(s), the default system locale and UI language(s), or any ad hoc combination of locale and subset of the available UI languages. There's no setting in a console session for a preferred locale and UI language(s) to use for the session, in contrast to the "LANG", "LC_*", and "LANGUAGE" environment variables on POSIX. This is a serious deficiency.
   
   Fortunately with UTF-8 support finally implemented in the console and the C runtime's locale implementation, at least locale data, system messages, and UI text can always be encoded when legacy applications write to console files, pipes, and disk files. The situation can be far worse if a legacy code page such as 1252 (Latin-1) gets paired with an incompatible locale or UI language. ↩