是否有一种编程语言具有完整和正确的Unicode支持？

Question

大多数编程语言都对Unicode 有一些支持,但是所有编程语言都有一些或多或少的记录的极端情况,其中的东西将无法正常工作.

---

例子

Java: StringBuilder/StringBuffer中的reverse()正常工作.但是如果一个字符需要超过16位进行编码,那么String中的length(),charAt()等就不会出现.

C#: 没有找到正确的反向方法,长度和索引访问返回错误的结果.

Perl:同样的问题.

PHP: 根本没有Unicode的想法,mbstring有一些更好的工作替代品.

---

我想知道是否有一种编程语言,它具有完整和正确的Unicode支持？那里必须做出什么妥协才能实现这样的目标？

• 更复杂的算法？
• 更高的内存消耗？
• 表现较差？

它是如何在内部实施的？

• Ints,链接列表等数组
• 额外的缓冲

我看到Python 3在这方面有一些很大的变化.Python 3现在与正确的实现有多接近？

Answer 1

从不违反Unicode标准的意义上讲,Java实现是正确的.没有规定字符串索引在代码点而不是代码单元上工作,并且记录了行为.只要没有泄漏无效字符串,Unicode标准就为实现者提供了有关优化的极大自由.关于"全力支持",这更难定义.Unicode标准通常不要求将某些功能实现为与Unicode兼容; 只是根据标准实现了实现的功能.有关脚本处理的大部分属于字体或操作系统,编程系统无法控制.如果您想判断某些技术的Unicode支持,

• 系统是否具有使用Unicode编码的字符串数据类型？
• 是否支持标准中描述的所有Unicode(UTF)编码？
• 正常化
• 双向算法
• 是UpperCase("ß") = "SS"吗？
• 上套管区域敏感吗？(例如土耳其语UpperCase("i") = "?")
• 是否有函数可以使用代码点而不是代码单元？
• Unicode正则表达式
• 在解码过程中遇到无效的代码单元序列时,系统会引发异常吗？
• 访问Unicode数据库属性？

我认为Java和.NET对这些问题的回答大多是"是",而Python 3.x的回答几乎总是"不".

Answer 2

去,通过发明在谷歌开发新的语言肯·汤普森和罗布·派克和的C语言中的Plan9从贝尔实验室都充分考虑到使用Unicode内置(UTF-8的发明有,在贝尔实验室,由Ken Thompson).

Answer 3

看起来 Perl 6 获得了很好的 Unicode 支持：

perlgeek.de/en/article/5-to-6#post_17

例如，它为您提供了三种不同的长度方法：

• 字节（字节数）
• 代码（代码点的数量）
• 图（字素的数量）

这也被集成到 Perl 的正则表达式中。

对我来说，这似乎是朝着正确方向迈出的一步。

Answer 4

在Python 3中,字符串总是unicode(有bytesASCII或类似的编码).我不知道任何内置插件无法正常使用它们.可能会有一些,但考虑到已经有一段时间了,我认为他们掌握了日常工作所需的一切.

当然,Unicode具有更高的内存消耗(如果你保持在ASCII范围内,UTF-8并不是真的,但是......)我可以想象多长度编码是内部处理的难点.不过,我对这个实现一无所知.除了它不能是链表,因为它有O(1)随机访问.

Answer 5

以为这是10年前的老问题了，...

是的。斯威夫特确实如此。

• 基本字符串类型String在 Unicode“字素簇”级别执行所有字符处理。因此，您必须在“人类感知的字符”级别以“Unicode 正确”的方式执行每个文本变异操作。

• 该String类型是抽象数据类型，不会公开其内部表示形式，但它具有访问所有 UTF-8、UTF-16、UTF-32 编码的 Unicode 标量值和 Unicode 代码单元的接口。

• 它还存储面包屑，以在摊销 O(1) 时间内提供 UTF-8 和 UTF-16 之间的偏移转换。

• Character类型还提供对 Unicode 标量值的分解。

• Charactertype 有多种基于 Unicode 语义的字符分类方法。例如，Character.isNewline返回trueUnicode 标准中定义的所有换行符字符串，包括 LF、VT、FF、CR、CR-LF、NEL、...。

• 虽然它是抽象的，但 Swift 5.x 在内部默认以 UTF-8 编码形式存储字符串。可以在严格的 O(1) 时间内访问它们，因此您可以使用基于 UTF-8 的函数而不牺牲性能。

• Swift 中的“Unicode”涵盖了 Unicode 标准中定义的“所有”字符，且不限于 BMP。

• String，Character以及它们的所有派生视图类型，例如UTF8View、UTF16View、 、UnicodeScalarView符合BidirectionalCollection协议，因此您可以在所有支持的分段级别中双向迭代组件。它们都共享相同的索引类型，因此如果从一个视图获得的索引指向正确的字形簇边界，则可以在另一视图上使用它们。