使用Console.ReadKey读取Unicode

不幸的是,Console.ReadKey只能处理键盘事件。键盘事件只能表示可以在键盘上键入的内容(使用ConsoleKey枚举中定义的实键和“虚”键)。因此,当使用ReadKey时,您只会得到两样东西:一种是原始键代码,它对应于键盘上的键;另一种是翻译字符,它是原始键代码在控制台的输入代码页中映射到的Unicode字符(每个代码页最多可以映射256个字符)。您不能使用ReadKey读取任何其他类型的数据(即不能直接键入和/或在输入代码页中没有映射的字符)。

此外,当您将Unicode字符粘贴到控制台中时,ReadKey使用的API会尝试将字符转换为Windows ALT+nnn序列(即,按住ALT键并在键盘上键入代码点编号)。不幸的是,它首先转换字符,使用为输入代码页定义的规则,因此即使您重新构建代码点编号,也无法获得粘贴的实际字符,您将获得代码页映射到的任何字符。

当使用Read或ReadLine时,它都能工作的原因是它们是基于流的方法,而不是基于键盘的方法。显然,任何字符都可以通过输入流输入,因为没有键盘和代码页转换。但您无法使用ReadKey直接访问输入流,只能使用键盘(如果输入流已从键盘以外的位置重定向,ReadKey将彻底失败)。

如果您将控制台API与P/Invoke一起手动使用,可能有一些方法可以使用输入流复制ReadKey的“截取”功能,但这并不重要,而且控制台并不是真正设计用来做这类事情的,因此您可能会一路与之抗争。

Console.ReadKey()返回的ConsoleKeyInfo对象有一个名为KeyChar的属性,该属性包含按下的键或键组合的Unicode字符(如果该键或键组合具有Unicode等效项)。所以

char c = Console.ReadKey().KeyChar;

如果该键没有Unicode等效项(例如,函数键),则会得到一个“\0”字符。

如有必要,您可以使用StringBuilder将这些字符连接到一个Unicode字符串中。

这太奇怪了。IIRC我的测试是32位的,可能是Vista。

现在在Win7 64位上进行了同样的测试,这个该死的东西可以工作了!

所以要么是Vista,要么是32位bug。

有人能确认一下吗?