wchar_t是具有平台定义宽度的宽字符，这并没有太大帮助。
UTF-8 字符跨越每个字符 1-4 个字节。UCS-2，每个字符正好跨越 2 个字节，现在已经过时，不能代表完整的 Unicode 字符集。
支持 Unicode 的 Linux 应用程序倾向于在字节存储层之上正确执行此操作。Windows 应用程序倾向于做出这种愚蠢的假设，即只有两个字节可以。
wchar_t的维基百科文章简要地谈到了这一点。
第一个在基于 Unix 的平台上使用 UTF-8 的人解释说：
Unicode 标准 [当时的 1.1 版] 定义了一个适当的字符集，但一个不合理的表示 [UCS-2]。它指出所有字符都是 16 位宽 [不再是真的]，并且以 16 位单元进行通信和存储。它还保留了一对字符（十六进制 FFFE 和 FEFF）来检测传输文本中的字节顺序，需要字节流中的状态。（Unicode 联盟考虑的是文件，而不是管道。）要采用这种编码，我们必须在 ASCII 和 Unicode 之间转换进出 Plan 9 的所有文本，这是无法做到的。在单个程序中，根据其所有输入和输出，可以将字符定义为 16 位量；在由不同制造商 [斜体字我的] 在不同机器上具有数百个应用程序的网络系统的背景下，这是不可能的。
斜体部分与 Windows 系统的相关性较低，Windows 系统偏好单一应用程序（Microsoft Office）、非多样化机器（一切都是 x86，因此是 little-endian）和单一操作系统供应商。
Unix 拥有小型、单一用途的程序的理念意味着更少的程序需要进行认真的字符操作。
我们的工具和应用程序的源代码已经转换为使用 Latin-1，因此它是“8 位安全的”，但转换为 Unicode 标准和 UTF[-8] 更复杂。有些程序根本不需要更改：
cat例如，将其参数字符串解释为以 UTF[-8] 传递的文件名，将其未经解释地传递给open系统调用，然后仅将字节从其输入复制到其输出；它从不根据字节的值做出决定……然而，大多数程序都需要适度的改变。...实际上很少有工具需要在内部对符文 [Unicode 代码点] 进行操作；更典型的是，他们只需要查找文件名中的最后一个斜杠和类似的琐碎任务。在 170 个 C 源程序中……现在只有 23 个包含单词
Rune。在内部存储符文的程序大多是那些其存在理由是字符操作的程序：sam（文本编辑器）、、、、、、（
sed窗口sort系统tr和终端仿真器）等等troff。8½要决定是使用符文还是使用 UTF 编码的字节字符串进行计算，需要平衡读取和写入时转换数据的成本与按需转换相关文本的成本。对于像编辑器这样运行时间相对恒定的数据集的程序来说，runes 是更好的选择……
如果您需要诸如类别和大小写映射之类的字符属性，则可以直接访问代码点的 UTF-32 确实更方便。
但是宽字符在 Linux 上使用起来很尴尬，原因与 UTF-8 在 Windows 上使用起来很尴尬一样。GNU libc 没有_wfopen或没有_wstat功能。
UTF-8 与 ASCII 兼容，可以在一定程度上忽略 Unicode。
通常，程序不关心（事实上，不需要关心）输入是什么，只要不存在可以终止字符串的 \0 即可。看：
char buf[whatever];
printf("Your favorite pizza topping is which?\n");
fgets(buf, sizeof(buf), stdin); /* Jalapeños */
printf("%s it shall be.\n", buf);
我发现我需要 Unicode 支持的唯一时候是我必须将多字节字符作为一个单元 (wchar_t)；例如，当必须计算字符串中的字符数而不是字节数时。iconv 从 utf-8 到 wchar_t 将很快做到这一点。对于像零宽度空间和组合变音符号这样的更大问题，需要像 icu 这样更重的东西——但你多久这样做一次？
wchar_t在所有平台上的大小都不相同。在 Windows 上，它是一个使用两个字节的 UTF-16 代码单元。在其他平台上，它通常使用 4 个字节（对于 UCS-4/UTF-32）。因此，这些平台不太可能标准化使用wchar_t，因为这会浪费大量空间。