Windows编码相关知识 & VC与MySQL交互数据乱码问题
2011-02-21 14:14
706 查看
字符必须编码后才能被计算机处理。最早的编码是7位的ASCII编码。ASCII码没有办法处理中文、阿拉伯文等复杂的文字。
各个国家为了处理自己的文字,纷纷制定了自己的文字编码规范,其中中文的文字编码规范叫做“GB2312—80”,它是和ASCII兼容 的一种编码规范,其实就是利用扩展ASCII没有真正标准化这一点,把一个中文字符用两个扩展ASCII字符来表示,以区分ASCII码部分。
由于各国和各地区都有自己的文字编码规则,它们互相冲突,这给各国和各地区交换信 息带来了很大的麻烦。
要真正解决这个问题,不能从扩展ASCII的角度入手,而必须有一个全新的编码系统,这个系统要可以将中文、法文、 德文……等等所有的文字统一起来考虑,为每一个文字都分配一个单独的编码。
于是,Unicode诞生了。
Unicode也是一种字符编码方法,它占用两个字节 (0000H—FFFFH),容纳65536个字符,这完全可以容纳全世界所有语言文字的编码。
在Unicode里,所有的字符被一视同仁,汉字不再使用“两个扩展ASCII”,而是使用“1个Unicode”,也就是说,所有的文字都按一个字符来处理,它们都有一个唯一的Unicode码。
需要注意的是,Unicode只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储。
UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32,不过在互联网上基本不用。重复一遍,这里的关系是,UTF-8是Unicode的实现方式之一。这是一种国际标准。
中国的国家标准有以下3种:
# GB 13000::完全等同于ISO 10646-1/Unicode 2.1,今后也将随ISO 10646/Unicode的标准更改而同步更改。
# GBK: 对GB2312的扩充, 以容纳GB2312字符集范围以外的Unicode 2.1的统一汉字部分, 并且增加了部分unicode中没有的字符。
# GB 18030-2000: 基于GB 13000,作为Unicode 3.0的GBK扩展版本,覆盖了任何unicode编码,地位等同于UTF-8, UTF-16, 是一种Unicode编码形式。 变长编码, 用单字节/双字节/4字节对字符编码. GB18030向下兼容GB2312/GBK。
GB 18030是中国任何非手持/嵌入式电脑系统的强制实施标准。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:
GBK、 GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312
目前,Windows使用的中文编码标准是GBK。虽然微软提供了GB18030的升级包,但是这个升级包并不改变内码。
有了前面的知识,对不同程序之间的乱码问题,就有很直接的答案,无非就是编码不一致的问题。当两种程序使用同一种编码时,就不会出现乱码。
前面已经说过,Windows使用的中文编码标准是GBK,因此在MySQL中将编码设为GBK(其他亦可,但是要与程序保持一致)。
使用MySQL C API与MySQL交互数据的时候,需要在查询之前,设置查询语句的编码为GBK:
mysql_query(&m_mysql,"set names 'GBK'");
VC中为了使程序支持中文等文字,需要将程序的字符集设为Unicode(上面提到的Windows使用的中文编码GBK,我的理解是程序接受、输出中文使用的是GBK,但是系统内部真正处理数据的时候会转化为Unicode):
到这里问题还没有结束,因为MySQL返回的字符是单字节(我对此的理解是返回的是ASCII),Unicode是双字节,直接显示查询结果肯定不正确。所以需要进行转化。
转换是用 MultiByteToWideChar()和WideCharToMultiByte()这两个Windows API,前者完成ANSI > Unicode, 后者完成Unicode > ANSI。
Unicode > ANSI:
//cstring是要转化的对象
DWORD dwNum = WideCharToMultiByte(CP_OEMCP, NULL, cstring, -1, NULL, 0, NULL, FALSE);
char* pChar = new char[dwNum];
WideCharToMultiByte(CP_OEMCP, NULL, cstring, -1, pChar, dwNum, NULL, FALSE);
上面得到的pCharke可以用来初始化std::string。
当然,别忘了删除pChar:
delete [] pChar;
ANSI > Unicode:
DWORD dwMinSize = MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1, NULL, 0);
wchar_t *pWchar = new wchar_t[dwMinSize];
MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1,pWchar , dwMinSize);
当然,别忘了删除pWchar:
delete [] pWchar;
各个国家为了处理自己的文字,纷纷制定了自己的文字编码规范,其中中文的文字编码规范叫做“GB2312—80”,它是和ASCII兼容 的一种编码规范,其实就是利用扩展ASCII没有真正标准化这一点,把一个中文字符用两个扩展ASCII字符来表示,以区分ASCII码部分。
由于各国和各地区都有自己的文字编码规则,它们互相冲突,这给各国和各地区交换信 息带来了很大的麻烦。
要真正解决这个问题,不能从扩展ASCII的角度入手,而必须有一个全新的编码系统,这个系统要可以将中文、法文、 德文……等等所有的文字统一起来考虑,为每一个文字都分配一个单独的编码。
于是,Unicode诞生了。
Unicode也是一种字符编码方法,它占用两个字节 (0000H—FFFFH),容纳65536个字符,这完全可以容纳全世界所有语言文字的编码。
在Unicode里,所有的字符被一视同仁,汉字不再使用“两个扩展ASCII”,而是使用“1个Unicode”,也就是说,所有的文字都按一个字符来处理,它们都有一个唯一的Unicode码。
需要注意的是,Unicode只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储。
UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32,不过在互联网上基本不用。重复一遍,这里的关系是,UTF-8是Unicode的实现方式之一。这是一种国际标准。
中国的国家标准有以下3种:
# GB 13000::完全等同于ISO 10646-1/Unicode 2.1,今后也将随ISO 10646/Unicode的标准更改而同步更改。
# GBK: 对GB2312的扩充, 以容纳GB2312字符集范围以外的Unicode 2.1的统一汉字部分, 并且增加了部分unicode中没有的字符。
# GB 18030-2000: 基于GB 13000,作为Unicode 3.0的GBK扩展版本,覆盖了任何unicode编码,地位等同于UTF-8, UTF-16, 是一种Unicode编码形式。 变长编码, 用单字节/双字节/4字节对字符编码. GB18030向下兼容GB2312/GBK。
GB 18030是中国任何非手持/嵌入式电脑系统的强制实施标准。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:
GBK、 GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312
目前,Windows使用的中文编码标准是GBK。虽然微软提供了GB18030的升级包,但是这个升级包并不改变内码。
有了前面的知识,对不同程序之间的乱码问题,就有很直接的答案,无非就是编码不一致的问题。当两种程序使用同一种编码时,就不会出现乱码。
前面已经说过,Windows使用的中文编码标准是GBK,因此在MySQL中将编码设为GBK(其他亦可,但是要与程序保持一致)。
使用MySQL C API与MySQL交互数据的时候,需要在查询之前,设置查询语句的编码为GBK:
mysql_query(&m_mysql,"set names 'GBK'");
VC中为了使程序支持中文等文字,需要将程序的字符集设为Unicode(上面提到的Windows使用的中文编码GBK,我的理解是程序接受、输出中文使用的是GBK,但是系统内部真正处理数据的时候会转化为Unicode):
到这里问题还没有结束,因为MySQL返回的字符是单字节(我对此的理解是返回的是ASCII),Unicode是双字节,直接显示查询结果肯定不正确。所以需要进行转化。
转换是用 MultiByteToWideChar()和WideCharToMultiByte()这两个Windows API,前者完成ANSI > Unicode, 后者完成Unicode > ANSI。
Unicode > ANSI:
//cstring是要转化的对象
DWORD dwNum = WideCharToMultiByte(CP_OEMCP, NULL, cstring, -1, NULL, 0, NULL, FALSE);
char* pChar = new char[dwNum];
WideCharToMultiByte(CP_OEMCP, NULL, cstring, -1, pChar, dwNum, NULL, FALSE);
上面得到的pCharke可以用来初始化std::string。
当然,别忘了删除pChar:
delete [] pChar;
ANSI > Unicode:
DWORD dwMinSize = MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1, NULL, 0);
wchar_t *pWchar = new wchar_t[dwMinSize];
MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1,pWchar , dwMinSize);
当然,别忘了删除pWchar:
delete [] pWchar;
相关文章推荐
- Linux/Windows下MySQL5.6的修改字符集编码为UTF8(解决中文乱码问题)
- windows下MySQL 插入数据时,中文乱码问题的解决
- vc传输字符===>java servlet====>hibernate====>mysql乱码问题
- 如何解决python连接数据库编码问题(python传数据到mysql乱码)'ascii' codec can't encode _mysql_exceptions.OperationalError: (1366, "Incorrect string value:?
- mysql导入导出数据中文乱码解决方法小结(1、navicat导入问题已解决,创建连接后修改连接属性,选择高级->将使用Mysql字符集复选框去掉,下拉框选择GBK->导入sql文件OK;2、phpmyadmin显示乱码的问题也解决,两步:1.将sql文件以utf8的字符集编码另存,2.将文件中sql语句中的字段字符集编码改成utf8,导入OK)
- mysql反向生成hbm.xml后,由hibernate向sql写数据中文出现乱码问题
- PHP+MySQL存储数据出现中文乱码的问题
- 用sqlyog导入mysql中文数据乱码问题
- 前端传数据到mysql乱码问题解决方案
- MySQL修改编码设置及乱码问题
- 2015.10.22小结Mysql中文乱码问题完美解决方案(包括建库、导入数据、网页)
- mysql导入数据,涉及到时间转换,乱码问题解决
- 解决SpringBoot更新数据到MySQL乱码问题
- MySQL 命令行查询乱码 编码问题
- 探讨PHP获取Oracle数据乱码的相关问题解决办法
- MySQL 插入数据时,中文乱码问题的解决
- MySQL 乱码问题相关资料汇集
- Windows 系统 MySQL 数据库相关问题
- 在WINDOWS下使用PHP+MYSQL的乱码问题--统一换成UTF-8
- MySQL 插入数据时,中文乱码问题的解决