巴蛮子的万花筒

• 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)。注意这两种版本在二进制上是不兼容的。

• Joel Spolsky: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• 每一个软件开发人员绝对必须掌握的关于 Unicode 和字符集的最基础的知识(上文的简体翻译，居然木野狐翻译的，好久不见他了)
• 对字符编码与Unicode,ISO 10646,UCS,UTF8,UTF16,GBK,GB2312的理解

标签： python, tech.misc

# 发表者巴蛮子 : 下午10:07