- 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)。注意这两种版本在二进制上是不兼容的。
2007年12月28日星期五
对字符集和编码的一些错误认识
字符集和编码一直很头疼的一块，最近为了搞培训，研究了一下，发现以前确实有很多不明白甚至是错误的认识:
订阅：
博文评论 (Atom)
没有评论:
发表评论