在一个产品里迭代了三年, 碰到最头疼的问题之一就是跨平台开发的字符集转换的问题. 至今为止, 我以为我懂了, 但可能还是错的, 希望别人能纠正.
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 编程脚本语言在展示页面内容的时候对字符编码集是有要求的
来源: http://www.jianshu.com/p/61c423202623