Windows 命令行：深入 Windows 控制台

此外，控制台不支持一些较新的Unicode功能，包括零宽度连接符（ZWJ），该符号被用于连接阿拉伯语和印度语中的其他单独字符，并将表情符号字符组合成一个可视字形！

那么如果你想在控制台上输出一个ninjacat表情符号或复杂的多字节中文/阿拉伯字符会怎样呢？ 糟糕的是，你做不到！

Console API不仅不支持长度超过2字节/字形的Unicode字符（NinjaCat表情符号需要8个字节！），但Console内部的UCS-2缓冲区不能存储该数据的额外字节，更糟糕的是 ，Console当前的基于GDI的渲染器甚至无法绘制字形，即使缓冲区可以存储它！

可叹！ 这就是遗留代码的乐趣。

但是，我也会希望你们到此打住 - 我们将在本系列的新一篇文章中回到这个主题。 敬请关注！

所以,我们在哪里?

再一次，亲爱的读者，如果你读过以上的所有内容，谢谢你，也祝贺你 —— 你现在比你的大多数朋友都更了解 Windows 控制台，甚至可能比你想知道的还要多！祝你幸运！

在这篇文章中，我们涵盖了很多内容:

Windows控制台的主要构建模块:

API Server —— 通过 IOCTL 消息向驱动程序发送或从驱动程序接收序列化的 API 调用和文本数据。

API——控制台的功能函数。

Buffers —— 输入缓冲用于存储用户输入，输出缓冲用于存储输出和显示文本。

输入缓冲存储用户输入，输出缓冲存储输出和显示文本。

VT Parser —— 将嵌入文本流的 ANSI/VT 序列转换为 API 调用

Console UX —— 控制台的用户界面状态、设置和功能

Other —— Misc 生命周期、安全性等。

Condrv.sys —— 控制台通信驱动程序

ConHost.exe —— 控制台用户体验、内部构件和管道:

控制台做什么？

向连接的命令行应用程序发送用户输入

接收并显示连接的命令行应用程序输出

控制台与 *NIX 终端有什么不同

*NIX：“一切都是文件/文本流”

Windows：“一切都是对象，可以通过 API 进行访问”

控制台存在的问题

大部分都在 Windows 10 中得到了修复

只有 ConHost.exe 可以附加到命令行应用程序

第三方终端被迫创建屏幕外控制台，并向它发送按键和屏幕信息，或从中接收按键和屏幕信息

远程操作 Windows 命令行应用程序和工具存在困难

来自 Windows 的端口命令行 APP 的工作变得更多

控制台和命令行应用程序通过序列化 API 调用请求和文本组成的 IOCTL 消息进行通信

只有 Windows 命令行应用程序能调用控制台 API

应用程序调用 Windows API 与控制台交互

对 IOCTL 的依赖打破了“字符交换”原则的终端设计

使从非 Windows 机器操作远程 Windows 命令行工具变得困难

启动 Windows 命令行应用程序是“不常用的”

Windows一直不识别ANSI/VT序列

控制台对 Unicode 的支持有限，目前正在努力处理存储和展现现代 UTF-8 和需要零宽度连接符的字符

在本系列的后续文章中，我们将深入探讨控制台，并讨论如何处理这些问题……和更多其他内容！

像往常一样，请继续关注我们。