漫谈字符集（ascii、gbk及unicode）--跨平台开发绕不过去的一道坎

在一个产品里迭代了三年，碰到最头疼的问题之一就是跨平台开发的字符集转换的问题。至今为止，我以为我懂了，但可能还是错的，希望别人能纠正。

ascii，7位美国国家信息交换标准码，基本能搞定英文。但是里面的128个字符不能满足需求，于是出来了一个ascii的扩展标准，及ANSI/ISO8859-1-1987标准草案（美国国家信息处理标准--8位单字节编码图形字符集），windows ANSI字符集基于该标准制定。一个char类型占8位（bit）等于一个字节（byte），所以char基本上能和ascii一一对应。

问题如此简单就不对了，中文、日文、韩文等象形文字怎么办？于是继续扩展，现在单字节已经无法满足需求了，于是双字节字符集出现，比如中文最初有个GB2312版本的字符集，后续扩容有出了一个GDK字符集，最后还扩容了一部分不常见字符变成了GB18030。这些编码是向下兼容的，那么问题也就出现，一部分字符（如ascii）是由一个字节组成所以判断字符串长度的时候要解析之后才能判断。

基于上面的单双字节的问题，于是又出现了unicode字符集（16位），他几乎涵盖了世界上所有的字符，由于实现方式的不一样，比较节省空间的实现方式是UTF-8字符集，虽然出现的晚了一些，但是希望所有程序员们能够消灭其他字符，统一使用uft-8。各种unicode编码的的区别在下面的链接里面，我认为很详细了，但是对错我缺乏专业的资料去判断，各位只能去研究一下老外指定的标准了。

16位字符的出现也导致ANSI/ISO9899-1990标准的产生，及“美国国家为程序设计语言C指定的标准”，通过一种叫“宽字符”的概念来支持多个字节代表一个字符的字符集。这些多字节字符集被当作单字节值的字符串去使用。宽字符不一定是unicode，unicode只是宽字符编码的一种实现而已。相应的出现了一些宽字符的处理函数。在不同的系统wchar_t可能是16位也可能是32位。

那么在实际项目中会碰到什么问题了？下面我列出我所碰到的一些问题：

1.使用openldap导入windows域控的信息的时候获取到的字符串是GBK编码，后台数据库如果要求字符集是非GBK编码的话，那么你就需要转码了。

2.加密解密，如果需要对文本或者字符串加密解密，那么就需要注意文本或者key（hash散列）的编码格式，统一即可

3.乱码的问题，部分浏览器或者web编程脚本语言在展示页面内容的时候对字符编码集是有要求的

注：参考来源

《windows程序设计》（第5版）第二章，unicode字符集

http://www.cnblogs.com/xiaomia/archive/2010/11/28/1890072.html

http://www.cppblog.com/lf426/archive/2010/06/25/118707.html