使用Console.ReadKey（）方法和ConsoleKeyInfo变量将扩展的ASCII字符转换为正确的表示形式

Question

Readed about 30 minutes, and didn't found some specific for this in this site.

Suppose the following, in C#, console application:

ConsoleKeyInfo cki;
cki = Console.ReadKey(true);
Console.WriteLine(cki.KeyChar.ToString()); //Or Console.WriteLine(cki.KeyChar) as well
Console.ReadKey(true);

Now, let's put ¿ in the console entry, and asign it to cki via a Console.ReadKey(true) . What will be shown isn't the ¿ symbol, the ¨ symbol is the one that's shown instead. And the same happens with many other characters. Examples: ñ shows ¤ , ¡ shows - , ´ shows ï .

Now, let's take the same code snipplet and add some things for a more Console.ReadLine() like behavior:

string data = string.Empty;
ConsoleKeyInfo cki;
for (int i = 0; i < 10; i++)
{
    cki = Console.ReadKey(true);
    data += cki.KeyChar;
}
Console.WriteLine(data);
Console.ReadKey(true);

The question, how to handle this by the right way, end printing the right characters that should be stored on data , not things like ¨ , ¤ , - , ï , etc?

Please note that I want a solution that works with ConsoleKeyInfo and Console.ReadKey() , not use other variable types, or read methods.

EDIT:

Because ReadKey() method, that comes from Console namespace, depends on Kernel32.dll and it definetively bad handles the extended ASCII and unicode, it's not an option anymore to just find a valid conversion for what it returns.

The only valid way to handle the bad behavior of ReadKey() is to use the cki.Key property that's written in cki = Console.ReadKey(true) execution and apply a switch to it, then, return the right values on dependence of what key was pressed.

For example, to handle the Ñ key pressing:

string data = string.Empty;
ConsoleKeyInfo cki;
cki = Console.ReadKey(true);
switch (cki.Key)
{
    case ConsoleKey.Oem3:
        if (cki.Modifiers.ToString().Contains("Shift")) //Could added handlers for Alt and Control, but not putted in here to keep the code small and simple
            data += "Ñ";
        else
            data += "ñ";
        break;
}
Console.WriteLine(data);
Console.ReadKey(true);

So, now the question has a wider focus... Which others functions completes it's execution with only one key pressed, and returns what's pressed (a substitute of ReadKey())? I think that there's not such substitutes, but a confirmed answer would be usefull.

Answer 1

The problem is not that the Console doesn't know how to deal with Unicode (it does, and correctly, check out this thread ). The problem lies in your understanding of a keypress on your keyboard, the translation into keycodes, the translation of keycodes into characters and how the ReadKey() method works.

First of all: if you want to read consecutive characters, use Console.ReadLine() instead, it does all the math for you, and better.

Let's take a look at the following program:

Console.WriteLine("Press a key to start (Enter to stop).");

var key = Console.ReadKey();
var allKeys = "";

while(key.Key != ConsoleKey.Enter)
{
    Console.WriteLine(key.KeyChar);
    allKeys += key.KeyChar;
    key = Console.ReadKey();
}

It reads a key from the input, than it appends it to string. Nothing to worry, right? Wrong! On a US International keyboard you can do this:

• Type ` + a becomes à
• Type Alt+123 becomes {
• Type Alt+3355 becomes ←
• Type ; as if on a Spanish keyboard, becomes ñ

Depending on your keyboard, you will hit a different key for a certain character. Sometimes you will hit a combination of keys. The first combination above is recorded as \\0a as a string and keycode 0 (not in the enum) and then ConsoleKey.A . The total resulting string is now "\\0á{←ñ" .

The Alt+123/3355 is recorded as a keycode 18 (this is the Alt-key). The translation of the numeric keys to a character is done by the OS before it is send to the console.

Typing ; on a US keyboard or ñ on a Spanish keyboard will show you the ConsoleKey.Oem1 (US) and ConsoleKey.Oem3 (Spanish).

While I cannot mimic your behavior, this is probably because I don't have your screen, but it seems very much that the font you have as Console font doesn't support non-Unicode characters. On Windows 7, by default it does, I don't know for other Windows versions. It is also possible that the codepage of your console is set incorrectly.

To summarize
What constitutes a character is dependent on keyboard layout, selected keyboard in international settings, selected language, selected code page in the Console and whether or not combinations of keys are allowed (it gets worse with IME!). To go from KeyChar to normal char is often trivial, but depends on whether your system settings are in sync with each other.

When I run your examples on my system, I do not have the same behavior. But then again, I don't have your system.

Going from a key to a character is tricky business. I suggest you don't rely on your own ability to reinvent what's already in the system. It's good practice to try to see what's going on, but really, move back to ReadLine ;).

EDIT:
I just saw your latest edit. Note that you can have different encodings for input and output ( Console.InputEncoding and Console.OutputEncoding ). I'd also like to quote the other thread to emphasize that when you switch to Unicode, the codepage doesn't matter anymore. This is the default behavior on recent Windows versions:

If you select a Unicode font, such as Lucida Console or Consolas, then you will be able to see and type Unicode characters on the console, regardless of what chcp says:

Answer 2

ReadLine() reconfigures the codepage to use properly the extended ASCII and Unicode characters. ReadKey() leaves it in EN-US default (codepage 850).

Just use a codepage that prints the characters you want, and that's all. Refer to http://en.wikipedia.org/wiki/Code_page for some of them :)

So, for the Ñ key press, the solution is this:

Console.OutputEncoding = Encoding.GetEncoding(1252); //Also 28591 is valid for `Ñ` key, and others too
string data = string.Empty;
ConsoleKeyInfo cki;
cki = Console.ReadKey(true);
data += cki.KeyChar;
Console.WriteLine(data);
Console.ReadKey(true);

Simple :)

And a side note: in some cases it's also necessary to reconfigure the Console.InputEncoding property!

Also, note that if you select another font for the console (Lucida Console/Consolas), this trouble STILLS happen. Lotta thanks to user Abel for this, he appointed to the font changing for solution and made myself discover that this is false .