Windows 命令行：深入 Windows 控制台

这些都是明显的限制:如果你想为 Windows 创建一个替代控制台的应用程序，该怎么办?你将如何发送键盘、鼠标、笔等等外设的信息？如果你无法访问连接你新控制台和命令行应用程序的通信“管道”，用户将怎么对命令行应用程序进行操作?

遗憾的是，这些情况并不好:有一些很棒的用于 Windows 的第三方控制台(和服务器应用程序)(例如 ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH 等)，他们必须通过离奇的跳转才能像正常的控制台一样运行!

举例来说，第三方控制台必须在屏幕外启动一个命令行应用程序，例如(-32000，-32000)。然后，他们必须向屏幕外控制台发送击键信息，然后收集屏幕外控制台的文本内容并在自己的 UI 上重新绘制它们!

我知道,这很疯狂,对吧? !这证明了这些应用程序创造者们的独创性和决心，这些程序甚至还在有效的运行!

这显然是我们急于补救的一种情况。请继续关注这部分内容的更多信息——在这方面有一些好消息!

Windows 控制台 & VT

如上所述，Windows 控制台提供了大量 API。使用控制台 API，命令行应用程序和工具可写入文本，更改文本颜色，移动光标等。并且，由于控制台 API 的存在，Windows 控制台几乎不需要支持 ANSI/VT 序列，这些序列在其他平台上提供非常类似的功能。

实际上，在 Windows 10 之前，Windows 控制台仅实现了对 ANSI/VT 序列的最低限度支持：

从2014年开始，微软组建了一个新的 Windows 控制台团队，使得这一切都发生了变化。控制台团队的最高优先级事项之一是实现对 ANSI/VT 序列的全面支持，以便渲染在 Windows 子系统之Linux（WSL）和远程 *NIX 机器上运行的 *NIX 应用程序的输出。您可以在本系列的上一篇文章中阅读更多关于这个故事的内容。

控制台团队迅速为 Windows 10 的控制台添加了对 ANSI/VT 序列的全面支持，使用户能够使用和享用大量 Windows 和 Linux 命令行工具和应用程序。

该团队继续改进和完善每个操作系统发布版本上的控制台对 VT 的支持，并对您在我们的 GitHub 问题跟踪器上提交的任何问题表示感谢。

处理Unicode

一个快速的Unicode回顾:

Unicode或ISO/IEC 10646是一个国际标准，定义了地球上几乎每个书写系统中所使用的每个字符/字形，以及当今使用的许多非脚本符号和字符大小的图像（例如表情符号）。目前（2018年7月），Unicode 11定义了137439个字符，包含146个现代和历史文字系统！

Unicode还定义了几种字符编码，包括UTF-8, UTF-16, 和UTF-32:

UTF-8: 前127个编码点使用1字节（主要为了维持与ASCII的兼容性），其他字符可选附加长度1-4字节

UTF-16/UCS-2: 每个字符两个字节。UCS-2 (被Windows内部使用)z支持对前65536编码点（统称为基本多语言平面-BMP）。UTF-16通过17个额外的字符平面扩展了UCS-2。

UTF-32: 每个字符4字节

由于UTF-8的高效的存储要求以及在HTML页面中的广泛使用，它是目前最流行的编码。

UTF-16/UCS-2都是常见的，尽管在已存储文档（例如网页、代码等）中其使用比例正在降低。UTF-32是很少使用的，因为它的效率低且存储需要相当大的空间。

很好，所以我们有有效并且高效的方式来表示和存储Unicode字符了！

所以？

哎呀，Windows控制台及其API是在创建Unicode之前创建的！

Windows控制台将文本（随后在屏幕上绘制）存储为每个单元需要2个字节的UCS-2字符。

命令行应用程序使用控制台API将文本写入到控制台中。处理文本的控制台API有两种形式 - 带有A后缀处理的单字节/字符串的函数，带有W后缀处理双字节（wchar）/字符串的函数：

例如，WriteConsoleOutputCharacter()函数编译为ASCII项目的WriteConsoleOutputCharacterA()，或Unicode项目的WriteConsoleOutputCharacterW()。如果需要指定处理方式，代码中可以直接调用... A或...W后缀的函数。

注意：每个W API至少支持UCS-2，因为这是在进行A/W拆分时就存在的事情，我们认为这样做会很棒。但许多W API已更新为在同一渠道上也支持UTF-16

。并非所有W API都可以支持UTF-16，但所有W API至少可以支持UCS-2。