长期以来,我一直被有关使用 Unicode 的问题所困扰。Unicode 允许加速和简化软件的开发(就全球化而言),但我担心以下因素:
- 增加内存和磁盘空间的使用;
- 降低文本处理性能;
- 亚洲语言一视同仁,不利于民族特色。
第一段很明显......但我不知道真实与否。有没有人面临亚洲国家软件本地化的需求,并准备分享经验?
目前我尝试使用窄配置文件的编码(cp1251 - 用于俄罗斯,cp1254 用于土耳其等)。有人会就这个问题提出建议吗?
长期以来,我一直被有关使用 Unicode 的问题所困扰。Unicode 允许加速和简化软件的开发(就全球化而言),但我担心以下因素:
第一段很明显......但我不知道真实与否。有没有人面临亚洲国家软件本地化的需求,并准备分享经验?
目前我尝试使用窄配置文件的编码(cp1251 - 用于俄罗斯,cp1254 用于土耳其等)。有人会就这个问题提出建议吗?
查看官方Unicode 常见问题解答。关于这些问题,它有很多话要说。
增加了文本大小,以下所有内容实际上都是不真实的。
对于 unicode 的老式编码,例如 UTF-16,它们可能是正确的。对于纯 ASCII 字符串,UTF-8 并不比 ASCII 大或慢,但它允许对每个 Unicode 代码点进行编码。UTF-8 也是当今市场上执行 Unicode 的事实上的标准。
http://www.utf8everywhere.org中对不同 Unicode 编码的性能进行了广泛的分析,包括亚洲语言。
前两点可以忽略不计。您需要有一个非常具体的用例,其中大小和性能的差异会产生明显的差异,从而证明混合编码令人头疼。
关于 Unihan 字符:它们按字符的含义分组,但该字符在不同的书写系统中可能略有不同。这是正确标记语言的问题,而不是真正的编码问题。在 HTML 文档中,您可以使用lang
属性标记文档和/或使用 CSS 设置特定字体,这将适当地改变语言字符的外观。如何正确处理这取决于软件的类型(HTML、桌面应用程序等)。我建议您就此提出一个新的详细问题。
增加文字大小:是的。文本大小最多可增加 6 倍(对于 UTF-8)。但是现在的文本存储已经不是什么大问题了。
降低文本处理性能:根据我的观点,没有。一个 UTF-8 字符最多可能占用 6 个字节,但是当扫描文本时,就在 UTF-8 字符的第一个字节处,我们已经知道要读取多少字节(扫描中的当前字符) )。因此,扫描性能很可能与 O(n) 相同,其中“n”是文本的长度。为了保持最佳性能,尽量不要按索引访问文本中的字符(是的,这是性能下降点)。Java 字符串不受随机索引访问字符串字符的影响,因为 Java 字符串是一系列 2 字节字符。
亚洲语言一视同仁,不利于民族特性.