中国服务器网

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

如何在Windows控制台上输出Unicodestring

已经有几个与这个问题有关的问题了。 我觉得我的问题有点不一样,因为我没有实际的问题,只是出于学术上的兴趣。 我知道Windows的UTF-16实现有时与Unicode标准(例如sorting规则)相矛盾,或者更接近旧的UCS-2而不是UTF-16,但是我将在这里保留“UTF-16”简单。 背景:在Windows中,一切都是UTF-16。 无论你是在处理内核,graphics子系统还是文件系统,或者其他什么东西,你都会传递UTF-16string。 Unix中没有语言环境或字符集。 为了与Windows的中世纪版本兼容,有一种称为“代码页”的东西已经过时,但仍然受到支持。 AFAIK,只有一个正确和非过时的函数可以将string写入控制台,即WriteConsoleW ,它带有一个UTF-16string。 此外,类似的讨论也适用于inputstream,我也将忽略它。 但是,我认为这代表了Windows API中的一个devise缺陷:有一个通用函数可以用来写入所有名为WriteFilestream对象(文件,pipe道,控制台),但是这个函数是面向字节的, t接受UTF-16string。 文档build议使用WriteConsoleW作为面向文本的控制台输出,而使用WriteFile作为面向字节的其他内容。 由于控制台stream和文件对象都由内核对象句柄表示,并且控制台stream可以redirect,所以必须调用一个函数,以便每次写入标准输出stream时检查该句柄是代表控制台stream还是文件,从而打破多元化。 OTOH,我认为Windows在文本string和原始字节(在许多其他系统,如Java或Python中被镜像)之间的分离在概念上优于Unix的char*方法,忽略了编码,不区分string和字节数组。 所以我的问题是:在这种情况下该怎么办? 为什么即使在微软自己的图书馆里也不能解决这个问题? .NET Framework和C和C ++库似乎都遵循过时的代码页模型。 你将如何deviseWindows API或应用程序框架来规避这个问题? 我认为一般的问题(不容易解决)是所有的库都假设所有的stream都是以字节为导向的,并且在其上面实现面向文本的stream。 但是,我们发现Windows在操作系统级别上有特殊的面向文本的stream,而这些库无法处理这一点。 所以在任何情况下,我们都必须对所有标准库进行重大更改。 一种快速和肮脏的方法是将控制台视为一种特殊的面向字节的stream,只接受一种编码。 这仍然要求C和C ++标准库必须被规避,因为它们没有实现WriteFile / WriteConsoleW开关。 那是对的吗?