我很长时间以来一直关注Unicode的使用问题。 Unicode允许加速和简化软件开发(就全球化而言),但我担心以下因素:
第一段显而易见......但我不知道其他人的真实与否。是否有人面临着为亚洲国家本地化软件的需要,并准备好分享经验?
目前我尝试使用窄配置文件的编码(cp1251 - 用于俄罗斯,cp1254用于土耳其等)。有人会就这个问题提出建议吗?
答案 0 :(得分:1)
查看官方Unicode FAQ。关于这些问题有很多话要说。
答案 1 :(得分:0)
前两点非常微不足道。您需要有一个非常具体的用例,其中大小和性能的差异会产生可辨别的差异,从而证明混合编码的麻烦。
关于Unihan字符:它们按字符的含义分组,但该字符在不同的书写系统中可能略有不同。这是正确标记语言的问题,它实际上不是编码问题。在HTML文档中,您可以使用lang
属性标记文档和/或使用CSS设置特定字体,这将适当地改变语言字符的外观。如何正确处理这取决于软件的类型(HTML,桌面应用程序等)。我建议你打开一个新的,详细的问题。
答案 2 :(得分:0)
文字大小增加:是的。文本大小最多可增加6倍(对于UTF-8)。但是现在的文本存储并不是什么大问题。
降低文字处理效果:根据我的意见,没有。 UTF-8字符最多可能占用6个字节,但是当扫描到文本时,并且在UTF-8字符的第一个字节处,我们已经知道要读取多少字节(扫描中的当前字符) )。所以很可能扫描性能与O(n)保持一致,其中'n'是文本的长度。为了保持最佳性能,请尽量不要通过索引访问文本中的字符(是的,这是性能的下降点)。 Java字符串不受对字符串字符的随机索引访问的影响,因为Java字符串是一系列2字节字符。
亚洲语言同样受到损害,不利于国家的特殊性:是的,以文本格式呈现的人类语言都是相似的,但是单个笔画的字母'i'或者16个笔画的“长”字母只是一个字符。
答案 3 :(得分:0)
文字大小增加,以下所有内容实际上都是不真实的。
对于unicode的老式编码,例如UTF-16,它们可能是真的。对于仅ASCII字符串,UTF-8不大于或慢于ASCII,但它允许对每个Unicode代码点进行编码。 UTF-8也是当今市场上做Unicode的事实标准。
对http://www.utf8everywhere.org中不同Unicode编码的性能进行了广泛的分析,包括亚洲语言。