Unicode在软件中的使用

长期以来，关于Unicode使用的问题一直困扰着我。Unicode允许加速和简化软件开发（就全球化而言），但我担心以下因素：

增加内存和磁盘空间的使用

文本处理性能的降低

亚洲语言一视同仁，损害了各国的特殊性

第一段很明显。。。但我不知道其他的是真是假。是否有人面临着为亚洲国家本地化软件的需要，并愿意分享经验

---

目前，我尝试使用窄剖面的编码（cp1251-俄罗斯，cp1254-土耳其，等等）。有人能就这个问题提出建议吗？

前两点可以忽略不计。您需要有一个非常具体的用例，其中大小和性能的差异会产生明显的差异，从而证明混合编码的头痛是合理的

关于Unihan字符：它们根据字符的含义进行分组，但在不同的书写系统中，该字符的书写可能略有不同。这是正确标记语言的问题，实际上不是编码问题。在HTML文档中，您可以使用

lang

属性标记文档和/或使用CSS设置特定字体，这将适当改变语言字符的外观。如何正确处理此问题取决于软件的类型（HTML、桌面应用程序等）。我建议你就此提出一个新的、详细的问题

增加的文本大小：是。文本大小最多可增加6倍（对于UTF-8）。但如今，文本存储并不是什么大问题

文本处理性能的降低：根据我的意见，不是。一个UTF-8字符可能最多需要6个字节，但当扫描文本时，就在UTF-8字符的第一个字节处，我们已经知道它需要读取多少字节（扫描中的当前字符）。因此，扫描性能很可能与O（n）相同，其中“n”是文本的长度。为了保持最佳性能，尽量不要按索引访问文本中的字符（是的，这是性能的一个下降点）。Java字符串不受对字符串的随机索引访问的影响，因为Java字符串是一系列2字节字符

亚洲语言被一视同仁，损害了国家的特殊性：是的，人类语言在以文本形式呈现时都是一模一样的，只有一个笔划的字母“i”或一个笔划的字母“i”長' 16个笔划中的一个笔划就是一个字符

对以字节为单位的数据大小的影响受Unicode编码的选择和数据类型的影响。例如，使用UTF-8（网络上唯一有用的Unicode编码），英语文本的大小与8位编码中的大小相同，但排版正确的标点符号除外，每个标点符号可能需要两个字节；对于土耳其语文本，任何非Ascii字母都是2字节而不是1字节；对于俄语文本，任何西里尔字母都是2字节。在大多数情况下，这并不重要

文本处理性能取决于您所做的事情以及如何做到这一点。合理的预期是没有值得担心的问题。如果处理速度足够快，那么使用8位编码是否会快10%就无关紧要了

统一Unicode有其影响，但亚洲语言肯定不是一视同仁的。Unicode标准对亚洲脚本和语言中字符的具体处理有很多规定。如果您指的是不同语言中不同形状的CJK字符，那么通常的解决方案是使用为所用语言设计的字体。（此外，原则上，当使用OpenType字体时，它至少也可以在字体内处理。）

---

看看这位官员。关于这些问题，它有很多话要说。

增加了文本大小，而以下所有内容实际上都是不真实的

对于旧式的unicode编码，例如UTF-16，它们可能是正确的。UTF-8不比ASCII更大，也不比ASCII慢，但它允许对每个Unicode码点进行编码。UTF-8也是当今市场上使用Unicode的事实标准

---

对不同的Unicode编码的性能进行了广泛的分析，包括亚洲语言。

你真的认为“增加的文本大小”是一个真正的问题吗？o、 我不清楚你所说的第三点是什么意思——你的第一点在记忆中是什么意思？（如果你和大多数人谈论文本大小，他们会认为你谈论的是屏幕上字形的大小…）最后一个很大程度上取决于细节和你正在开发的软件类型。如果可用，请提供更多上下文。所有代码页最终都映射到Unicode，因此不清楚您的替代方案是什么。内存使用没有增加。使用UTF8。感谢您对“郎”的建议。。。我只是看了一下，发现Unihan字符并没有我想象的那么大问题。

lang

属性对渲染的影响很小（尽管它的影响可能会增加）。它可能会影响默认字体的选择，从而使CJK字符以中文或日文字体显示。但网页大多都有自己的字体设置，默认字体通常并不重要。UTF-8编码的字符形式最多有4个字节。关于6字节的信息已经过时（从将Unicode编码空间限制为0..10FFFF之前的时间段）。我认为使用Unicode更合理（但需要保留用户语言）。