Linux 命令行厉害 其实Windows 的也很强：深入 Windows 控制台(4)

例如，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。

此外，控制台不支持一些较新的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 和需要零宽度连接符的字符

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

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

【编辑推荐】

1. 微软放大招？Windows 10 将加入原生虚拟机支持
2. 微软计划将Windows变成按月收费的桌面即服务
3. 谷歌下架百款携带Windows木马的App，居然是怕程序员“中毒”
4. Linux仍然是Windows的威胁吗？
5. 因侵犯Windows商标 Chrome时间线扩展被下架

（编辑：ASP站长网）