C 编程：如何为 Unicode 编程？
进行严格的 Unicode 编程需要哪些先决条件？
这是否意味着我的代码不应该在任何地方使用 char 类型并且需要使用可以处理 wint_t 和 wchar_t 的函数？
而多字节字符序列在这个场景中起到什么作用呢？
C99 或更早版本
标准 (C99) 提供了宽字符和多字节字符，但由于无法保证这些宽字符可以容纳什么，因此它们的价值受到了一定的限制。对于给定的实现，它们提供了有用的支持，但是如果您的代码必须能够在实现之间移动，则不能充分保证它们是有用的。
因此，Hans van Eck 建议的方法（即围绕 ICU - Unicode 的国际组件 - 库编写一个包装器）是合理的，IMO。
UTF-8 编码有许多优点，其中之一是如果您不弄乱数据（例如通过截断它），那么它可以被不完全了解 UTF-8 复杂性的函数复制编码。 wchar_t 绝对不是这种情况。
完整的 Unicode 是 21 位格式。也就是说，Unicode 保留了从 U+0000 到 U+10FFFF 的代码点。
关于 UTF-8、UTF-16 和 UTF-32 格式（其中 UTF 代表 Unicode 转换格式 - 请参阅 Unicode）的有用之处之一是您可以在三种表示之间进行转换而不会丢失信息。每个人都可以代表其他人可以代表的任何事物。 UTF-8 和 UTF-16 都是多字节格式。
众所周知，UTF-8 是一种多字节格式，其结构严谨，可以可靠地找到字符串中字符的开头，从字符串中的任何点开始。单字节字符的高位设置为零。多字节字符的第一个字符以位模式 110、1110 或 11110（对于 2 字节、3 字节或 4 字节字符）之一开头，后续字节始终以 10 开头。连续字符始终位于范围 0x80 .. 0xBF。有一些规则要求 UTF-8 字符必须以尽可能少的格式表示。这些规则的一个后果是字节 0xC0 和 0xC1（也是 0xF5..0xFF）不能出现在有效的 UTF-8 数据中。
U+0000 .. U+007F 1 byte 0xxx xxxx
U+0080 .. U+07FF 2 bytes 110x xxxx 10xx xxxx
U+0800 .. U+FFFF 3 bytes 1110 xxxx 10xx xxxx 10xx xxxx
U+10000 .. U+10FFFF 4 bytes 1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx
最初，人们希望 Unicode 是一个 16 位的代码集，并且一切都适合 16 位的代码空间。不幸的是，现实世界更加复杂，不得不将其扩展到当前的 21 位编码。
因此，UTF-16 是“基本多语言平面”的单个单元（16 位字）代码集，这意味着具有 Unicode 代码点 U+0000 .. U+FFFF 的字符，但使用两个单元（32 位）来表示此范围之外的字符。因此，使用 UTF-16 编码的代码必须能够处理可变宽度编码，就像 UTF-8 一样。双单元字符的代码称为代理。
代理是来自两个特殊范围的 Unicode 值的代码点，保留用作 UTF-16 中成对代码单元的前导和尾随值。前导（也称为高）代理从 U+D800 到 U+DBFF，尾随或低代理从 U+DC00 到 U+DFFF。它们被称为代理，因为它们不直接表示字符，而只是作为一对。
当然，UTF-32 可以在单个存储单元中编码任何 Unicode 代码点。它对计算有效，但对存储无效。
您可以在 ICU 和 Unicode 网站上找到更多信息。
C11 和
C11 标准改变了规则，但即使是现在（2017 年年中），也不是所有的实现都赶上了这些变化。 C11 标准将 Unicode 支持的更改总结为：
Unicode 字符和字符串 (
以下是功能的最小概述。该规范包括：
6.4.3 通用字符名称 语法 Universal-character-name: \u hex-quad \U hex-quad hex-quad hex-quad: hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit 7.28 Unicode 实用程序
（翻译交叉引用：<stddef.h> 定义 size_t，<wchar.h> 定义 mbstate_t，<stdint.h> 定义 uint_least16_t 和 uint_least32_t。）<uchar.h> 标头还定义了一组最小的（可重新启动) 转换函数：
mbrtoc16() c16rtomb() mbrtoc32() c32rtomb()
使用 \unnnn 或 \U00nnnnnn 表示法可以在标识符中使用哪些 Unicode 字符有一些规则。您可能必须主动激活对标识符中此类字符的支持。例如，GCC 要求 -fextended-identifiers 允许在标识符中使用这些。
请注意，macOS Sierra (10.12.5) 仅举一个平台，不支持 <uchar.h>。
请注意，这不是关于“严格的 unicode 编程”本身，而是一些实践经验。
我们在我公司所做的是围绕 IBM 的 ICU 库创建一个包装库。包装库有一个 UTF-8 接口，在需要调用 ICU 时转换为 UTF-16。在我们的例子中，我们并不太担心性能下降。当性能成为问题时，我们还提供了 UTF-16 接口（使用我们自己的数据类型）。
应用程序可以基本保持原样（使用 char），尽管在某些情况下它们需要注意某些问题。例如，我们使用包装器代替 strncpy() 来避免切断 UTF-8 序列。在我们的例子中，这已经足够了，但也可以考虑检查组合字符。我们还有用于计算代码点数量、字素数量等的包装器。
在与其他系统交互时，我们有时需要进行自定义角色组合，因此您可能需要一些灵活性（取决于您的应用程序）。
我们不使用 wchar_t。使用 ICU 避免了可移植性方面的意外问题（但不是其他意外问题，当然 :-)。
strncpy 与 UTF-8 一起使用是完全安全的。
strcpy （使用 UTF-8 确实是安全的）。使用 strncpy 的人可能会这样做，因为他们不知道目标缓冲区是否足够大，因此他们希望传递最大数量的字节来复制 - 这确实可能会创建无效的 UTF-8序列。
这个 FAQ 是一个丰富的信息。在该页面和 this article by Joel Spolsky 之间，您将有一个良好的开始。
我在此过程中得出的一个结论：
wchar_t 在 Windows 上是 16 位，但在其他平台上不一定是 16 位。我认为这在 Windows 上是必要的邪恶，但可能可以在其他地方避免。它在 Windows 上很重要的原因是您需要它来使用名称中包含非 ASCII 字符的文件（以及 W 版本的函数）。
请注意，采用 wchar_t 字符串的 Windows API 需要 UTF-16 编码。另请注意，这与 UCS-2 不同。注意代理对。这个测试页面有启发性的测试。
如果您在 Windows 上编程，则不能使用 fopen()、fread()、fwrite() 等，因为它们只接受 char * 并且不理解 UTF-8 编码。使便携性变得痛苦。
f* 和朋友在 每个 平台上都使用 char *，因为标准是这样规定的——使用 wcs* 代替 wchar_t。
要进行严格的 Unicode 编程：
仅使用支持 Unicode 的字符串 API（不是 strlen、strcpy、...，而是它们的宽字符串对应物 wstrlen、wsstrcpy、...）
处理文本块时，使用允许存储 Unicode 字符（utf-7、utf-8、utf-16、ucs-2、...）而不会丢失的编码。
检查您的操作系统默认字符集是否与 Unicode 兼容（例如：utf-8）
使用与 Unicode 兼容的字体（例如 arial_unicode）
多字节字符序列是一种早于 UTF-16 编码（通常与 wchar_t 一起使用的编码）的编码，在我看来，它仅适用于 Windows。
我从未听说过wint_t。
最重要的是始终明确区分文本和二进制数据。尝试遵循 Python 3.x str vs. bytes 或 SQL TEXT 与 BLOB 的模型。
不幸的是，C 将 char 用于“ASCII 字符”和 int_least8_t，从而混淆了这个问题。您需要执行以下操作：
typedef char UTF8; // for code units of UTF-8 strings
typedef unsigned char BYTE; // for binary data
您可能还需要 UTF-16 和 UTF-32 代码单元的 typedef，但这更复杂，因为未定义 wchar_t 的编码。您只需要一个预处理器#if。 C 和 C++0x 中一些有用的宏是：
__STDC_UTF_16__ — 如果定义，类型 _Char16_t 存在并且是 UTF-16。
__STDC_UTF_32__ — 如果定义，类型 _Char32_t 存在并且是 UTF-32。
__STDC_ISO_10646__ — 如果已定义，则 wchar_t 为 UTF-32。
_WIN32 — 在 Windows 上，wchar_t 是 UTF-16，尽管这违反了标准。
WCHAR_MAX — 可用于确定 wchar_t 的大小，但不能确定操作系统是否使用它来表示 Unicode。
这是否意味着我的代码不应该在任何地方使用 char 类型并且需要使用可以处理 wint_t 和 wchar_t 的函数？
也可以看看：
UTF-8 或 UTF-16 或 UTF-32 或 UCS-2
Unicode 支持需要 wchar_t 吗？
不。UTF-8 是使用 char* 字符串的完全有效的 Unicode 编码。它的优点是，如果您的程序对非 ASCII 字节透明（例如，作用于 \r 和 \n 但通过其他字符不变的换行符），则您根本不需要进行任何更改！
如果您使用 UTF-8，则需要更改 char = 字符（例如，不要在循环中调用 toupper）或 char = 屏幕列（例如，用于文本换行）的所有假设）。
如果您使用 UTF-32，您将拥有固定宽度字符的简单性（但不是固定宽度字素，但需要更改所有字符串的类型）。
如果您使用 UTF-16，您将不得不放弃固定宽度字符的假设和 8 位代码单元的假设，这使得这是从单字节编码升级最困难的路径。
我建议积极避免 wchar_t，因为它不是跨平台的：有时是 UTF-32，有时是 UTF-16，有时是预 Unicode 东亚编码。我建议使用 typedefs
更重要的是，avoid TCHAR。
const char *，则采用 char * 的函数可能会出现问题（但我对此以及哪些函数含糊不清，因此请稍加注意）。仅仅因为它与其他语言更复杂并不意味着它是一个糟糕的设计。
char 进行签名，因此对 UTF8 使用普通 char 可能会出现符号扩展问题。对 UTF8 也使用 unsigned char — 或 uint8_t。
我不会相信任何标准库的实现。只需滚动您自己的 unicode 类型。
#include <windows.h>
typedef unsigned char utf8_t;
typedef unsigned short utf16_t;
typedef unsigned long utf32_t;
int main ( int argc, char *argv[] )
{
int msgBoxId;
utf16_t lpText[] = { 0x03B1, 0x0009, 0x03B2, 0x0009, 0x03B3, 0x0009, 0x03B4, 0x0000 };
utf16_t lpCaption[] = L"Greek Characters";
unsigned int uType = MB_OK;
msgBoxId = MessageBoxW( NULL, lpText, lpCaption, uType );
return 0;
}
您基本上希望将内存中的字符串作为 wchar_t 数组而不是 char 来处理。当您执行任何类型的 I/O（例如读/写文件）时，您可以使用 UTF-8（这可能是最常见的编码）进行编码/解码，这很容易实现。只需谷歌 RFC。所以在内存中没有什么应该是多字节的。一个 wchar_t 代表一个字符。然而，当你开始序列化时，你需要编码为 UTF-8 之类的东西，其中一些字符由多个字节表示。
您还必须为宽字符串编写新版本的 strcmp 等，但这不是一个大问题。最大的问题将是与只接受 char 数组的库/现有代码的互操作。
对于 sizeof(wchar_t)（如果您想正确处理，您将需要 4 个字节），如果需要，您可以随时使用 typedef/macro hack 将其重新定义为更大的大小。
关注公众号
不定期副业成功案例分享
wchar_t和朋友有点短。这些类型对于允许 C 库以 any 编码（包括非 Unicode 编码）处理文本至关重要。如果没有广泛的字符类型和函数，C 库将需要一组文本处理函数来处理每个支持的编码：想象一下 koi8len、koi8tok、koi8printf 仅用于 KOI-8 编码文本和 utf8len， utf8tok, utf8printf 用于 UTF-8 文本。相反，我们很幸运只有 一个 组这些函数（不包括原始的 ASCII 函数）：wcslen、wcstok和wprintf。mbstowcs和朋友）将任何支持的编码转换为wchar_t。一旦采用wchar_t格式，程序员就可以使用 C 库提供的一组宽文本处理函数。一个好的 C 库实现将支持大多数程序员需要的几乎任何编码（在我的一个系统上，我可以访问 221 种唯一编码）。wchar_t足够宽以包含实现支持的任何字符。这意味着（可能有一个明显的例外）大多数实现将确保它们足够宽，以使使用wchar_t的程序可以处理系统支持的任何编码（Microsoft 的wchar_t只有 16 位宽，这意味着它们的实现确实不完全支持所有编码，尤其是各种 UTF 编码，但它们是例外而不是规则）。