为什么wchar_t在Linux /相关平台的代码中没有被广泛使用？
这引起了我的兴趣，所以我要问 – 为什么wchar_t在类似Linux / Linux的系统上没有像在Windows上那样广泛使用？ 具体来说，Windows API在内部使用wchar_t而我认为Linux没有，这反映在许多使用char类型的开源软件包中。
我的理解是，给定一个需要多个字节来表示它的字符c ，然后在char[]forms中， c被分成char*几个部分，而它在wchar_t[]形成一个单元。 那么，使用wchar_t总是不容易吗？ 我是否错过了否定这种差异的技术原因？ 或者只是采用问题？
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位为单位进行通信和存储。 它还保留一对字符（hexFFFE和FEFF）来检测传输文本中的字节顺序，需要字节流中的状态。 （Unicode Consortium考虑的是文件，而不是管道。）要采用这种编码，我们必须在ASCII和Unicode之间转换进出Plan 9的所有文本，这是无法完成的。 在一个程序中，在命令其所有输入和输出时，可以将字符定义为16位数量; 在不同制造商 [italics mine]的不同机器上有数百个应用程序的网络系统环境中 ，这是不可能的。
斜体部分与Windows系统不太相关，Windows系统偏好单片应用程序（Microsoft Office），非多样化机器（一切都是x86，因此是小端），以及单个OS供应商。
拥有小型单一目的程序的Unix理念意味着他们需要进行严格的字符操作。
我们的工具和应用程序的源代码已经转换为使用Latin-1，因此它是’8位安全’，但转换为Unicode标准和UTF [-8]更为复杂。 有些程序根本不需要改变：例如，
cat解释它的参数字符串，以UTF [-8]传递，作为它未经解释传递给open系统调用的文件名，然后只是将字节从其输入复制到其输出; 它永远不会根据字节值做出决定……然而，大多数程序都需要适度的改变。……实际上很少有工具需要在内部运行符文[Unicode代码点]; 更典型的是，他们只需要在文件名和类似的简单任务中查找最终的斜杠。 在170个C源程序中……现在只有23个包含
Rune这个词。在内部存储符文的程序主要是那些存在性格操纵的人：sam（文本编辑器），
sed，sort，tr，troff，8½（窗口系统和终端模拟器），等等。 要决定是使用符文还是UTF编码的字节串进行计算，需要在读取和写入时平衡转换数据的成本与按需转换相关文本的成本之间的平衡。 对于像编辑器这样的程序来说，使用相对恒定的数据集运行很长时间，符文是更好的选择……
如果您需要类别和大小写映射等字符属性，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）; 例如，当必须计算字符串中的字符数而不是字节数时。 从utf-8到wchar_t的iconv很快就会这样做。 对于像零宽度空间和组合变音符号这样的更大问题，需要像icu这样更重的东西 – 但是你经常这样做多少次？
wchar_t在所有平台上的大小都不一样。 在Windows上，它是一个使用两个字节的UTF-16代码单元。 在其他平台上，它通常使用4个字节（对于UCS-4 / UTF-32）。 因此，这些平台不太可能使用wchar_t标准化，因为它会浪费大量空间。