为了避免乱码应尽量少用GB2312编码

文章是半转载，半原创的。如有表述不对的，还请各位看官淡定！

今天在折腾MySql数据库的时候，SQL-Front里所有的字符串编码，包括my.ini配置文件里的default-character-set=gb2312，在录入个人资料表里的姓名的时候，随手输入“和珅”两个字，SQL-Front居然提示：

SQL 执行错误 # 1366. 从数据库的响应:
Incorrect string value: '珅' for column 'name' at row 1

额 好吧，字串值不匹配，编码全部换成GBK的就OK了。随手写了个简单的C程序，看“坤”这个字的编码：

#include <stdio.h>


int main(void)
{
unsigned char buf[] = "珅" ;
printf("0x%02X, 0x%02X\n", buf[0], buf[1]) ;
return 0 ;
}

结果：0xAB, 0x7C

至于原因查阅以下几种编码

GB2312
双字节，定长
包括一二级汉字和9区符号
高位低位一样，都是从0xA1~0xFE(很明显，“珅”字不在这个范围里面)
汉字编码范围是0xB0A1~0xF7FE

GBK
双字节，定长
兼容GB2312
编码范围：0x8140~0xFEFE
所有字符都可以映射到Unicode2.0

GB18030-2000(GBK2K)
收藏少数民族字型
不定长，包含二字节部分和四字节部分
二字节部分兼容GBK
四字节部分是扩充字符，第一第三字节范围:0x81~0xFE，第二第四字节范围：0x30~0x39

Unicode
包括所有字符字型
各地区语言都可与之建立映射
异种语言的转换是通过Unicode来完成的
汉字从4E00开始

其中gb2312编码所表示的字符最少，这样其实会引起很多问题，其中有些可能你看不懂的乱码问题也是因为这原因而起的。

这里举个例子：

"和珅"这两个字中的"珅"字简体字和繁体字是一样的，但在gb2312编码里是没有的。这样在使用gb2312编码的页面里就会出问题了，可能你在页面中输入是正确的但传输到了服务器端就会乱码，而且他可能会影响下面的字也出现乱码（字节码组合问题）。