索引wchar_t数组中的字符

不要使用wchar_t对Unicode字符串执行操作。说真的，千万不要。正如您已经观察到的，wchar_t对象和Unicode代码点之间没有一对一的对应关系。使用诸如ICU之类的库来操作Unicode文本。

这里有很多问题，使用像ICU这样的库可以帮助您避免很多问题。如果您试图计数"字符"，那么UTF-16中代理字符的问题并不是唯一的问题。

如果您只需要遍历一个wchar_t字符串，代理值的值被唯一地定义为一个前导值(0xd800到0xdbff)，后跟一个尾随值(0xdc00到0xdfff)。您可以使用这些知识来向前或向后遍历数组，对"字符"进行计数。这假定您有一组有效的值。

另一个问题是流中的值本身不是字符。例如，U+0301是"合并急性重音"，在前面的值上添加重音。无论使用UTF-8、UTF-16还是UTF-32，这都可能是一个问题。

wchar_t的大小在不同的系统中可能不同，但是在机器的运行时或编译时是确定和固定的。

您可以通过操作符sizeof检索它的大小，也可以像其他类型一样迭代它。

基于特定语言环境的类型wchar_t具有存储字符的最大大小。因此，字符串的代码单元到文本字符之间的映射是一对一的，因此不必担心像其他类型一样遍历宽字符串的字符以读取下一个或上一个字符。(不同于Unicode)

然而，这是wchar_t字符串中唯一明亮的部分。使用它们作为存储任意字符串的通用方法并不是一件容易的事。所以，你应该使用Unicode感知的东西。

这个答案澄清了wchar_t作为一种类型的本质。在问题中加上"更正"之前，这句话似乎被误解了。

与任何具体类型一样，sizeof(wchar_t)和sizeof(wchar_t *)对于特定系统都是常数。

用语言术语来说，你可以像导航其他类型的数组一样导航wchar_t数组。

然而，使用不同数量的wchar_t s编码的文本字符是另一个更复杂的问题。其他答案在一定程度上解决了这个问题。