很久以来,我对Unicode的使用问题感到折磨。 Unicode允许加速和简化软件开发(就全球化而言),但我担心以下因素:软件中的Unicode使用情况
- 增加的内存和磁盘空间使用率;
- 减少文本处理性能;
- 亚洲语言对待所有这些都损害了国家的特殊性。
随着第一段的所有这是显而易见的......但我不知道真的或不是其他人。有没有人需要为亚洲国家本地化软件,并准备分享经验?
目前我尝试使用窄轮廓编码(cp1251 - 对于俄罗斯,cp1254对于土耳其等)。有人会就这个问题提出建议吗?
很久以来,我对Unicode的使用问题感到折磨。 Unicode允许加速和简化软件开发(就全球化而言),但我担心以下因素:软件中的Unicode使用情况
随着第一段的所有这是显而易见的......但我不知道真的或不是其他人。有没有人需要为亚洲国家本地化软件,并准备分享经验?
目前我尝试使用窄轮廓编码(cp1251 - 对于俄罗斯,cp1254对于土耳其等)。有人会就这个问题提出建议吗?
前两点非常可忽略不计。您需要有一个非常具体的用例,其中大小和性能的差异会产生可辨别的差异,证明混合编码的麻烦是正确的。
关于Unihan字符:它们按照字符的含义分组,但是该字符在不同的书写系统中可能会略有不同。这是正确标记语言的问题,它不是一个真正的编码问题。在HTML文档中,您可以使用lang
属性标记文档和/或使用CSS设置特定的字体,这将相应地改变该语言字符的外观。如何正确处理这取决于软件的类型(HTML,桌面应用程序等)。我建议你打开一个新的,详细的问题。
谢谢关于“lang”的建议......我只看了http://en.wikipedia.org/wiki/Han_unification#Examples_of_language_dependent_characters,看到Unihan角色并不像我想的那么大。 – user1717043
'lang'属性对渲染只有边缘效应(尽管其影响可能会增加)。它可能会影响*默认*字体的选择,因此CJK字符以中文或日文字体显示。但网页主要是自己的字体设置,然后默认字体通常不重要。 –
增加文字大小:是的。文字大小可增加至6倍(对于UTF-8)。但现在的文本存储不是什么大问题。
降低文本处理性能:根据我的意见,没有。一个UTF-8字符最多可能需要6个字节,但是当扫描文本时,以及在UTF-8字符的第一个字节处,我们已经知道需要多少字节才能读取它(扫描中的当前字符)。因此,扫描性能很可能与O(n)保持一致,其中“n”是文本的长度。为了保持最佳性能,尽量不要通过索引访问文本中的字符(是的,这是性能的一个下降点)。 Java字符串不受字符串字符的随机索引访问影响,因为Java字符串是一系列2字节字符。
亚洲语言的处理都是一样的国家的具体的损害:是的,当以文本格式呈现的人类语言都是相似的,但一个字母“I”一个中风或信的“长” 16招只是一个角色。
字符的UTF-8编码形式最多为4个字节。有关6个字节的信息已过时(从将Unicode编码空间限制为0..10FFFF之前的时间段开始)。 –
查看官方Unicode FAQ。对这些问题有很多要说的。
我决定使用Unicode更合理(但需要保留用户语言)。 – user1717043
增加文本大小,以下所有内容实际上都是不真实的。
对于unicode的老派编码,比如UTF-16,它们可能是正确的。对于仅ASCII字符串,UTF-8不会更大或比ASCII更慢,但它允许对每个Unicode代码点进行编码。 UTF-8也是今天在市场上做Unicode的事实上的标准。
对http://www.utf8everywhere.org中的不同Unicode编码的性能有广泛的分析,包括亚洲语言。
你真的认为“增加文字大小”是一个真正的问题? o.O – 2012-11-01 06:59:27
你的第三点意味着什么并不清楚 - 你的第一点意味着什么?*记忆*? (如果你和大多数人谈论文字大小,他们会认为你在谈论屏幕上字形的大小......) –
最后一个很大程度上取决于你正在开发的软件的细节和种类。如果有的话,请更多的背景。 – deceze