索引 wchar_t 数组中的字符[关闭]答案

【问题标题】：Index a character in a wchar_t array [closed]索引 wchar_t 数组中的字符[关闭]
【发布时间】：2014-10-13 01:32:40
【问题描述】：

线程“Size of wchar_t* for surrogate pair”显示，保存 wchar_t 值所需的内存大小可能不同，因为它可能需要更多空间来编码某些字符（代理对）。这让我想到了以下问题：然后我如何沿着 wchar_t 值的数组导航？因为我现在不仅可以将当前地址增加或减少固定大小的 wchar_t。

更正：“我如何然后沿着 wchar_t 值的数组导航”是指您如何在代码点之间导航，这些代码点可能由可变数量的 wchar_t 值表示。

【问题讨论】：

对不起：这是 C 还是 C++？
@Sam 我认为您需要返回并重新阅读该问题的答案。关键是wchar_t 和wchar_t* 的大小不同。存储wchar_t 所需的大小将在您的程序中保持一致。
也许你误读了你链接的问题；那只是在谈论sizeof(wchar_t) 和sizeof(wchar_t *)。它没有谈论使用多少个字符来编码代理对（OP认为它确实如此，但他错了）。你能澄清你的问题吗？
我认为问题是例如 Han character 使用 2 个 wchar_t 字符。所以ptr++ 和ptr-- 在这里不起作用，因为它只移动 1 个 wchar_t。如何导航？
威梅尔成功了。正是我的意思

标签： c++ c arrays unicode wchar-t

【解决方案1】：

这个答案澄清了wchar_t 作为一种类型的性质。在问题添加“更正”之前，这似乎被误解了。

与任何具体类型一样，sizeof(wchar_t) 对于特定系统来说是常量，sizeof(wchar_t *) 也是如此。

在语言方面，您可以导航 wchar_t 数组，就像导航任何其他类型的数组一样。

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

【讨论】：

你是对的。我确实纠正了我的错误问题。
我不知道为什么我的票数一直在下降。我试图澄清我的答案。对于为什么这个答案值得投反对票的任何反馈，我将不胜感激？
我也不知道为什么有人对你的答案投了反对票。我给了你一个赞成票来抵消反对票=）。

【解决方案2】：

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

您可以通过运算符sizeof 检索其大小，也可以像其他类型一样对其进行迭代。

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

但是，这是wchar_t 字符串中唯一亮的部分。将它们用作存储任意字符串的一般方法并非易事。所以，你应该使用 Unicode 感知的东西。相关问答是here。

【讨论】：

我觉得MM的回答对我很有帮助。是的，我的问题可能根本不那么清楚，因为关于编码的整个事情都很混乱。

【解决方案3】：

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

【讨论】：

+1 为自己难以解决的情况提供实用建议

【解决方案4】：

这里存在多个问题，使用 ICU 等库将帮助您避免很多问题。如果您尝试计算“字符”，则 UTF-16 中的代理字符问题并不是唯一的问题。

如果您只需要遍历 wchar_t 字符串，则代理值的值被唯一地定义为前导值（0xd800 到 0xdbff），后跟一个尾随值（0xdc00 到 0xdfff）。您可以使用这些知识在计算“字符”的数组中前进或后退。这假设您有一组有效的值。

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

【讨论】：