C 11中的Unicode

Question

我一直在阅读Unicode的主题 - 特别是，UTF-8 - C 11中的（非）支持，我希望Stack Overflow上的大师可以向我保证我的理解是正确的，或者指出我在哪里误解或遗漏了一些东西，如果是这样的话。

首先，好处是：您可以在源代码中定义UTF-8、UTF-16和UCS-4文本。此外，

[编辑：Cubbi在评论中指出，我忽略了<代码>

C 11还包括C99/C11

但是，这就是它的范围。虽然您当然可以将UTF-8文本存储在std：：字符串中，但我看不到任何真正有用的方法。例如，除了在代码中定义文本之外，您无法验证字节数组是否包含有效的 UTF-8，也无法找出包含 std：：字符串的 UTF-8 的长度（即 Unicode 字符数，对于“字符”的某些定义），并且不能以除逐字节以外的任何方式迭代 std：：字符串。

类似地，即使是添加了std:：u16string的C11也不真正支持UTF-16，只支持旧的UCS-2——它不支持代理项对，只支持BMP。

鉴于UTF-8是几乎所有Unix派生系统（包括 <罢工> Mac OS X和 在很大程度上已经成为网络上事实上的标准，缺乏对现代C语言的支持似乎是一个相当严重的遗漏。即使在Windows上，新的std::u16string并不真正支持UTF-16的事实似乎有些令人遗憾。

< sub>*正如评论中所指出的，Mac OS的BSD衍生部分使用UTF-8，而Cocoa使用UTF-16。

如果您设法阅读了所有这些内容，谢谢！只是几个简短的问题，因为这是堆栈溢出毕竟...

>

上述分析是否正确，或者我是否缺少其他Unicode支持工具？

标准委员会在过去的几年里做了出色的工作，推动C语言快速向前发展。他们都是聪明人，我认为他们很清楚上述缺点。C中Unicode支持如此之差有什么众所周知的原因吗？

展望未来，有人知道任何纠正这种情况的建议吗？对isocpp.org的快速搜索似乎没有任何发现。

编辑：谢谢大家的回复。我不得不承认，我觉得他们有点令人沮丧——看来在不久的将来，现状不太可能改变。如果在认知界达成共识，那么完全支持Unicode似乎太难了，任何解决方案都必须重新实现大部分ICU才能被视为有用。

我个人不同意这一点。我认为有宝贵的中间立场可以找到。例如，UTF-8 和 UTF-16 的验证和规范化算法由 Unicode 联盟明确指定，并且可以由标准库作为免费函数提供，例如 std：：unicode 命名空间。仅这些对于需要与期望 Unicode 输入的库接口的 C 程序来说就有很大的帮助。但根据下面的答案（必须说，带有一丝苦涩），小狗关于这种有限功能的建议似乎并不受欢迎。




Answer 1

匿名用户

上述分析是否正确，或者我是否缺少其他Unicode支持工具？

你也错过了UTF-8文字的彻底失败。它们没有与窄字符文字不同的类型，窄字符文字可能有完全不相关的(例如代码页)编码。因此，他们不仅没有在C 11中添加任何重要的新功能，还打破了仅有的一些功能，因为现在你甚至不能假设< code>char*是你的平台的窄字符串编码，除非UTF-8是窄字符串编码。因此，这里的新功能是“我们在每个平台上完全打破了基于< code>char的字符串，其中UTF-8不是现有的狭义字符串编码”。

标准委员会在过去的几年里做了出色的工作，推动C语言快速向前发展。他们都是聪明人，我认为他们很清楚上述缺点。C中Unicode支持如此之差有什么众所周知的原因吗？

委员会似乎根本没有对Unicode嗤之以鼻。

此外，许多Unicode支持算法只是算法。这意味着要提供一个体面的界面，我们需要范围。我们都知道，委员会无法弄清楚他们想要的w.r.t.范围。埃里克·尼布勒的新迭代器可能会有一个机会。

展望未来，有人知道任何纠正这种情况的建议吗？对isocpp.org的快速搜索似乎没有任何发现。

这是我写的N3572。但当我去布里斯托尔展示时，出现了许多问题。

首先，事实证明，委员会不会在会议间隙费心反馈非委员会成员撰写的提案，当你重复他们不想要的设计时，会导致数月的工作损失。

其次，事实证明，这是由当时路过的人投票决定的。这意味着，如果你的论文被重新安排，你会有一大群相对随机的人，他们可能知道也可能不知道这个主题。或者说，什么都可以。

第三，出于某种原因，他们似乎并不认为当前的情况是一个严重的问题。你可以得到关于到底是如何可选的无休止的讨论

第四，每份报纸都需要一个有效的拥护者来展示和维护它。考虑到之前的问题，再加上我负担不起去参加其他会议的费用，这个人肯定不会是我，将来也不会是我，除非你愿意捐出我所有的差旅费，并支付我的薪水，而且似乎没有其他人足够在乎付出努力。

Answer 2

以上分析是否正确

让我们看看。

您无法验证包含有效 UTF-8 的字节数组

不正确。std::codecvt_utf8

你找不到长度

部分正确。可以转换成char32_t并找出结果的长度。没有简单的方法可以在不进行实际转换的情况下确定长度(但请参见下文)。我必须说计数字符的需要(在任何意义上)很少出现。

您不能以除逐字节以外的任何方式迭代 std：：字符串

不正确。std::codecvt_utf8

并不真正支持UTF-16

不正确。用户可以使用例如< code>std::codecvt_utf8_utf16在UTF-16之间进行转换

演示说明了这些要点。

如果我错过了其他一些“你不能”，请指出它，我会解决它。

重要增编。这些设施在 C 17 中已弃用。这可能意味着它们将在C的某个未来版本中消失。使用它们需要您自担风险。原始问题中列举的所有这些事情现在不能（安全地）再次完成，仅使用标准库。