2007年12月28日星期五

对字符集和编码的一些错误认识

字符集和编码一直很头疼的一块,最近为了搞培训,研究了一下,发现以前确实有很多不明白甚至是错误的认识:
  • ISO-8859-1 .. ISO-8859-16 这些都是西欧各国用的字符集,主要的差别在与128-255之间各自代表的字符不同;
  • 仍然不明白为啥GB2312, Big5这些就算MBCS,而同样采用多字节编码的Unicode却不算
  • GBK应该是GB2312的超集,向下兼容GB2312的,记得以前谁跟我说不是,我迷惑了好一阵;
  • 很 多编辑器说可以支持"Unicode编码",并且一些软件说"Unicode"就是两字节编码,这都是基于Unicode 4.0之前的认识。在那之前,Unicode跟GB2312这样的名称一样,即是字符集(charset)名称又是编码(encoding)名称, Unicode字符均是两个字节。但从Unicode 4.0开始,它已经不只65536个字符了,Unicode只是一个字符集名称,而UCS-2, UCS-4,UTF-8, UTF-16, UTF-32这些才是编码名称(当然,历史包袱总是存在的);
  • UCS-2与UTF-16是不一样的,UCS-2固定采用两个字节,它不能表达Unicode 4.0之后增补的字符(当然,那些字符很生僻),而UTF-16里面每个字符可能是2或4个字符组成;
  • UTF-8
    • 从新的理论上而言,UTF-8应该是1-6个字符不等,但目前应该是1-3个字符就可以表达已有的字符了;
    • UTF-8的优点
      • 如果原有数据大都采用ASCII表达,那么这些数据不用转换
      • 如果系统采用ASCII可以表达大多数数据,那么相对UCS-2,UTF-16这些节省空间;
      • 编码中字符边界很容易找到:以0开头的字节肯定是ASCII字符,最高位以11开头的字节肯定是字符的开头字节,以10开头的字节肯定是字符的后续字节;
      • 容错性强一些,偶尔一两个错误不会影响后面,原因同上(想咱们都碰到过GB2312/Big5的半个汉字问题带来的乱码问题吧)
      • 按字节流读取,不用考虑大端(big endian)/小端(little endian)问题
      • 字符串中不会出现0x00这样的字节(而UCS-2这些会),这样char *这样的方式表达缓冲区时不太容易导致错误
    • UTF-8的缺点
      • 对于非ASCII字符,相对以前存储空间增加了,比如非英语的西欧字符集现在都需要两个字节了,而中文等很多都需要三个字节了;
      • 计算字符串长度比较麻烦,只能逐个统计;
    • 综上,现在很多系统内部处理采用UCS-2,只在存储和数据交换中采用UTF-8
  • Java以前内部全部采用Unicode(其实是UCS-2)来处理字符串,但Unicode 4.0以上的那些字符它不能处理。在Java 5.0中加入了一些奇怪的机制来解决这个问题
  • Python也不能同时支持UCS-2和UCS-4,只是可以在编译时挑选(--enable-unicode=ucs2和--enable-unicode=ucs4),看sys.maxunicode是否大于65535就知道是否是UCS-4了。我看Windows上的预编译版本是UCS-2(python2.5)的,而Linux上是UCS-4(Debian testing, python 2.4)。注意这两种版本在二进制上是不兼容的。
参考文档

没有评论: