windows - 如何在 Windows 控制台上输出 Unicode 字符串

Question

已经有一些与此问题相关的问题。我认为我的问题有点不同，因为我没有实际问题，我只是出于学术兴趣而问。我知道 Windows 的 UTF-16 实现有时与 Unicode 标准(例如归类)相矛盾，或者更接近旧的 UCS-2 而不是 UTF-16，但出于以下原因，我将在此处保留“UTF-16”术语简单。

背景:在 Windows 中，一切都是 UTF-16。无论您是在处理内核、图形子系统、文件系统还是其他任何东西，您都在传递 UTF-16 字符串。没有 Unix 意义上的语言环境或字符集。为了与中世纪版本的 Windows 兼容，有一种叫做“代码页”的东西已经过时但仍然受支持。据我所知，只有一个正确且未过时的函数可以将字符串写入控制台，即 WriteConsoleW，它采用 UTF-16 字符串。此外，类似的讨论也适用于输入流，我也将忽略它。

但是，我认为这代表了 Windows API 中的设计缺陷:有一个通用函数可用于写入所有流对象(文件、管道、控制台……)，称为 WriteFile，但是这个函数是面向字节的，不接受 UTF-16 字符串。文档建议使用 WriteConsoleW 进行控制台输出，这是面向文本的，而 WriteFile 用于其他所有内容，这是面向字节的。由于控制台流和文件对象都由内核对象句柄表示，并且可以重定向控制台流，因此每次写入标准输出流时都必须调用一个函数来检查句柄是代表控制台流还是文件，从而破坏了多态性。 OTOH，我确实认为 Windows 在文本字符串和原始字节之间的分离(这在许多其他系统(如 Java 或 Python 中反射(reflect))在概念上优于 Unix 的 char* 方法，后者忽略编码并且不区分在字符串和字节数组之间。

所以我的问题是:在这种情况下该怎么办？为什么即使在 Microsoft 自己的库中也没有解决这个问题？ .NET Framework 以及 C 和 C++ 库似乎都遵循过时的代码页模型。您将如何设计 Windows API 或应用程序框架来规避此问题？

我认为普遍的问题(不容易解决)是所有库都假设所有流都是面向字节的，并在此基础上实现面向文本的流。但是，我们看到 Windows 在操作系统级别确实有特殊的面向文本的流，而库无法处理这个问题。因此无论如何我们都必须对所有标准库进行重大更改。一种快速而肮脏的方法是将控制台视为一种特殊的面向字节的流，它只接受一种编码。这仍然要求必须规避 C 和 C++ 标准库，因为它们没有实现 WriteFile/WriteConsoleW 开关。对吗？

Answer 1

我/我们在大多数(跨平台)应用程序/项目中使用的一般策略是:我们到处都使用 UTF-8(我的意思是真正的标准)。我们使用 std::string 作为容器，我们只是将 everything 解释为 UTF8。我们也以这种方式处理所有文件 IO，即我们期望 UTF8 并保存 UTF8。如果我们从某处得到一个字符串并且我们知道它不是 UTF8，我们会将其转换为 UTF8。

我们偶然发现 WinUTF16 的最常见情况是文件名。因此对于每个文件名处理，我们总是将 UTF8 字符串转换为 WinUTF16。反之亦然，如果我们在目录中搜索文件。

在我们的 Windows 构建中并没有真正使用控制台(在 Windows 构建中，所有控制台输出都包装到一个文件中)。因为我们到处都是 UTF8，所以我们的控制台输出也是 UTF8，这对大多数现代系统来说都很好。此外，Windows 控制台日志文件的内容采用 UTF8 格式，Windows 上的大多数文本编辑器都可以毫无问题地读取它。

如果我们更多地使用 WinConsole 并且非常关心所有特殊字符是否正确显示，我们可能会编写一些自动管道处理程序，我们将其安装在 fileno=0 之间。和真正的stdout这将使用 WriteConsoleW正如您所建议的那样(如果真的没有更简单的方法)。

如果您想知道如何实现这样的自动管道处理程序:我们已经为所有类 POSIX 系统实现了这样的东西。该代码可能无法按原样在 Windows 上运行，但我认为应该可以移植它。我们当前的管道处理程序类似于tee。做。 IE。如果你做 cout << "Hello" << endl ，它们都将打印在 stdout 上在一些日志文件中。看the code如果您对这是如何完成的感兴趣。