MySQL字符集知识总结(2)

下面我通过一个常用的场景来描述字符集转换的流程。用户通过mysql命令行(如果是远程连接:SecureCRT),敲入命令“insert into T values(1,’小明’)”,字符串’小明’在流转过程中二进制存储内容。

a) 用户采用的客户端为utf8字符集,character_set_client=gbk,character_set_connection=gbk, 表T采用gbk字符集。

 

MySQL字符集知识总结

由于character_set_client、character_set_connection和表字符集均为GBK,不涉及编码转换。因此,表虽然为字符集虽然为GBK,但“小明”的编码并非为GBK编码的二进制流,而是UTF8的二进制流,两个汉字占用了6个字节,而读取则是一个逆向的过程,不涉及到编码转换,查询依然能正确返回“小明”。

b)  在a)的情况下,改变character_set_client的设置为utf8,查询插入的值。

 

MySQL字符集知识总结

可以看到返回的值是“灏忔槑”, 这是由于表的字符集是GBK,而客户端请求是UTF8,那么server将二进制流E5B08FE6988E对应的GBK汉字“灏忔槑”转为UTF8汉字对应的二进制流E7818FE5BF94E6A791,因此查询结果在SecureCRT就显示为“灏忔槑”,即通常我们所谓的乱码。

c) 在b)的情况下,设置SecureCRT的字符集为GBK,看看SecureCRT字符集设置对结果影响

 

MySQL字符集知识总结

可以看到返回的是另外一组字符“鐏忓繑妲�”,整个流转过程与b)一样,只是在第一步发生了字节流转换,设置SecureCRT字符集编码,只是改变了显示方式。

字符集相关的SQL语句

1)  查看字符集编码设置

SHOW VARIABLES LIKE%CHARACTER%

2)  设置字符集编码

SET NAMES xxx;

这个语句相当于设置了client的字符集,主要包含3个系统变量,character_set_client,character_set_connection和character_set_results。

3) 修改数据库字符集

ALTER DATABASE DATABASENAME CHARACTER SET XXX;

这个语句只修改库的字符集,影响后续创建的表的默认定义;对于已创建的表的字符集不受影响。

4) 修改表的字符集

ALTER TABLE TABLENAME CHARACTER SET XXX;

这个语句只修改表的字符集,影响后续该表新增列的默认定义,已有列的字符集不受影响。

ALTER TABLE TABLENAME CONVERT TO CHARACTER SET XXX;

 这个语句同时修改表字符集和已有列字符集,并将已有数据进行字符集编码转换。

5) 修改列字符集

ALTER TABLE `TABLE_NAME` MODIFY COLUMN `COLUMN_NAME` CHARACTER SET xxx

6)  查询字符的二进制编码

SELECT HEX(COL_NAME) FROM TABLE_NAME; SELECT LENGTH(COL_NAME) FROM TABLE_NAME;

对于GBK的表,如果查出来一个字符占用了3个字节,比如图1这种情况,则肯定是字符集在某个环节设置统一,图1就是因为客户端是UTF8,而mysqlclient和database都是GBK造成的。

mysql默认的字符集latin1

     mysql 4.x版本之前默认采用的是latin1字符集(又称ISO-8859-1),latin1字符集编码方式采用单字节编码。抛一个问题,latin1字符集的表,用户写入和读取汉字是否有问题?答案是只要合理设置,没有问题。假设SecureCRT为UTF8,character_set_client和表字符集均设置为latin1,参考第3节的分析,那么用户读取和写入数据的过程中,并不涉及字符集编码转换的问题,将UTF8的汉字字符转为二进制流写入database,提取出来后,secureCRT再将对应的二进制解码为对应的汉字,所以不影响用户的使用。但是,若character_set_client,character_set_connection,与表字符集设置等不统一,就可能出现乱码的情况。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/cb321d73a7fa4f71d206ec677c93b18d.html