【发布时间】：2016-12-22 18:47:25
【问题描述】：
控制台函数wincon.h的Windows API部分定义了一个数据结构CHAR_INFO如下：
typedef struct _CHAR_INFO {
union {
WCHAR UnicodeChar;
CHAR AsciiChar;
} Char;
WORD Attributes;
} CHAR_INFO, *PCHAR_INFO;
所以我们有一个 8 位和一个 16 位字符的并集，分别表示 ASCII 和 Unicode 字符。通常，如果您必须在 C 中处理联合，则您已标记联合，即存在一个额外字段，指示正在使用联合的哪个字段。这里不是这种情况（Attributes 用于不同的东西），所以我想知道如何正确使用这种数据类型的值。
如果我们查看 API 的哪些函数实际上使用了这个或类似的结构，我们会发现它只被存在于两个变体中的函数使用：或者以 A 为后缀（对于 ASCII 变体），或者以W（用于 Unicode 变体）。
那么假设这些函数的A 变体将仅使用此结构的AsciiChar 字段，而W 变体仅使用UnicodeChar 字段，是否可以保存？如果不是，您如何知道实际使用的是哪个字段以及如何将一个字段转换为另一字段？ MSDN documentation 似乎没有说明这里的正确用法。
【问题讨论】：
-
没有 8 位和 16 位字符，除非那些全大写的自制程序名称与标准中的类型不同。有什么理由不使用标准名称，但有一些恼人的大写版本？而且您不能“标记工会”。您必须将其包装成
struct（反之亦然）。 -
是的，控制台 API 有两种风格，取决于您是否定义了 UNICODE。是的，A 和 W 变体。这在大约十年前就不再重要了，实际的实现总是 Unicode。 A 风格 api 转换为本地代码页以生成 AsciiChar 变体。编写 Unicode 兼容的 C 或 C++ 代码绝不会发生意外，您总是知道何时要使用 CHAR_INFO.Char.UnicodeChar。有点神秘，为什么他们不使用 TCHAR 或将其命名为 AnsiChar 顺便说一句，它背后的设计师可能认为这都是一个杂牌 :)
-
@Olaf：对不起，我不明白你的评论。上面的结构是来自 Windows API 的
wincon.h头文件中定义的文字副本，大写类型名称是 Windows API 使用的约定，它将CHAR定义为 8 位和WCHAR为 16 位字符（请参阅here）。此外，联合被包装到结构中。 -
@HarryJohnston：我非常有信心至少
char确实当时存在。实际上，当时具有 8 字节/字节以外的系统比今天更普遍。无论如何，这仍然不是不每隔 15 到 20 年左右更新一次 API 的借口。但我该怎么说，他们显然甚至无法支持 17 年的语言标准。 -
@HarryJohnston:
char总是一个字节。您似乎认为一个字节与一个八位字节相同。那是错的。它不是而且从来没有！我不知道“百万第三方开发者”，但我知道很多开发者因为古老的 API 而尖叫。请注意，Apple 多次进行此类更改，包括两个完整的平台，并且进展顺利。其他系统类似。是的，他们用 ca 疯狂地改变了这些变化。可以进行此类更改时 WinAPI 具有的相同数量的单元。但是可以尝试为任何错误的决定开脱，这个讨论没有实际意义。
标签： c++ c windows unicode console