字符集GBK升级UTF8

在生产环境中,数据库字符集因为各种原因需要升级,比如为了支持汉字,从latin1字符集升级到GBK,后面为了支持多个语言文字,需要将GBK升级到UTF8等。迁移过程网上有很多,我今天主要想讲下字符集转换后,可能对业务产生的影响,我以GBK转换到UTF8为例说明。主要有两点:

  1. 汉字在GBK编码中占2个字节,在UTF8编码中占3个字节,而mysql的索引要求总长度不超过767个字节,因此索引字符数会被缩短(383->255),特别的,对于唯一索引,要求索引字段长度小于256个字符。
  2. 编码转换后,导致字段排序发生变化。

这篇文章主要为了说明编码转换后,字段排序如何受影响,会结合mysql源代码给出原因和分析。首先看测试用例,假设cmp_t(GBK编码)和cmp_t2(UTF8编码)分别是迁移前后的表。

测试用例:


操作


cmp_t(GBK)


cmp_t2(UTF8)


1


GBK表:

select c1,hex(c1) from cmp_t;

UTF8表:

select c1,hex(c1) from cmp_t2;


+------+---------+

| c1   | hex(c1) |

+------+---------+

| 一  | D2BB

| 二  | B6FE

| 三  | C8FD

| a    | 61

| 1    | 31

+------+---------+


+------+---------+

| c1   | hex(c1) |

+------+---------+

| 一  | E4B880

| 二  | E4BA8C

| 三  | E4B889

| a    | 61

| 1    | 31

+------+---------+


2


GBK表:

select c1,hex(c1) from cmp_t where c1>’a’ order by c1;

UTF8表:

select c1,hex(c1) from cmp_t2 where c1>’a’ order by c1;


+------+---------+

| c1   | hex(c1) |

+------+---------+

| 二  | B6FE    |

| 三  | C8FD

| 一  | D2BB

+------+---------+


+------+---------+

| c1   | hex(c1) |

+------+---------+

| 一  | E4B880

| 三  | E4B889

| 二  | E4BA8C

+------+---------+

从上面操作返回的结果我们可以得到以下几点信息:

  1. 汉字在GBK编码中占2个字节,在UTF8编码中占3个字节
  2. 数字和英文字符在GBK和UTF8编码中都只占一个字节
  3. 汉字在UTF8编码和GBK编码不同,排序后顺序变化了。

原理分析:

Mysql利用sortcmp函数对字符串进行比较,对于GBK的字符串和UTF8的字符串分别采用接口my_strnncollsp_gbk和my_strnncollsp_utf8比较,这两个函数分别在ctype-gbk.c和ctype-utf8.c中实现,两个函数实现逻辑类似,只是各有自己一套比较大小的规则,下面我主要描述下my_strnncollsp_utf8的比较逻辑和比较大小的规则。

比较逻辑:

  1. 获取字符串的第一个字节
  2. 根据UTF8的编码规则(附1),确定字符由几个字节组成
  3. 根据一定的算法算出字符的加权值(附2),比较大小;若不符合UTF8编码规范,认为是乱码,采用二进制比较(附3)
  4. 跳过步骤2返回的字节数,比较下一个字符。

附1:【接口: my_utf8_uni】

根据UTF8编码规则,符合编码规范的字符占用1-6个字节。

取字符串第一个字节 s

if s<0x80

表示字符占1个字节

elif s<0xe0

表示字符占2个字节

elif s<0xf0

表示字符占3个字节

else s<0xf8

表示字符占4个字节

elif s<0xfc

表示字符占5个字节

elif s<0xfe

表示字符占6个字节

英文字符和数字字符编码兼容ASCII,编码值小于0x80,因此都只占1个字节;汉字的utf8编码的首字节都在[0xe0,0xf0]之间,所以占3个字节。

附2:utf8编码比较大小规则

value = ((s[0] & 0x0f) << 12)| ((s[1] ^ 0x80) << 6) | (s[2] ^ 0x80)

s[0],s[1],s[2]表示组成汉字的三个字节,对参与比较的汉子字符进行计算得到value1和value2,通过比较value1和value2的大小,判断字符大小。

附3:二进制比较【接口: bincmp】

memcmp函数比较,即逐字节比较。

因此,如果业务上面需要依赖汉字比较的场景,需要考虑字符集升级(GBK->UTF8)的风险,主要是索引或主键中包含字符串字段需要特别关注,如果字符串中确定只包含有数字和字符,则不会存在问题。

时间: 2024-11-13 21:26:58

字符集GBK升级UTF8的相关文章

MySQL字符集 GBK、GB2312、UTF8区别 解决 MYSQL中文乱码问题 收藏 MySQL中涉及的几个字符集

MySQL中涉及的几个字符集 character-set-server/default-character-set:服务器字符集,默认情况下所采用的.character-set-database:数据库字符集.character-set-table:数据库表字符集.优先级依次增加.所以一般情况下只需要设置character-set-server,而在创建数据库和表时不特别指定字符集,这样统一采用character-set-server字符集.character-set-client:客户端的字符

告别乱码,针对GBK、UTF-8两种编码的智能URL解码器的java实现(转)

效果图 字符 字符是早于计算机而存在,从人类有文明那时起,人们就用一个个符号代表世间万象.如ABC,如“一.二.三”. 字符集 字符集是所有字符的集合. XXX字符集 给字符集中的每一个字符套上一个序号后的字符集.常见的XXX字符集有ASCLL字符集.Unicode字符集等等,不同种字符集为每个字符编的序号不同,包含的字符数量也不同. GBK.UTF-8 GBK.UTF-8是一种编码编码格式.当然,你也可以说unicode是一种编码格式,因为它的的确确为每个字符编了一个码,没错,可是unicod

GBK和UTF8的区别

GBK的文字编码是双字节来表示的,即不论中.英文字符均使用双字节来表示,只不过为区分中文,将其最高位都定成1. UTF-8编码则是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24位(三个字节)来编码.对于英文字符较多的论坛则用UTF-8节省空间. 以上或许你看不懂,简单的说GBK就是中文字符集,在装有中文GBK编码电脑上能正常显示中文,而如果在国外非中文操作系统的电脑上则会显示成为乱码,所以GBK主要针对国内网站使用. 而UTF8则是国际标准,如果在国外非中文操作

GB2312,GBK,GB18030,UTF8四种汉字编码标准有什么区别和联系

 从GB2312.GBK 到 GB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符.在这些编码中,英文和中文可以统一地处理.区分中文编码的方法是高字节的最高位不为 0.按照程序员的称呼,GB2312.GBK 到 GB18030 都属于双字节字符集 (DBCS). 以下是这四种字符集的包含关系:GB2312 < GBK < GB18030 < UTF8 ---------------------------------------

字符编码GB2312、GBK、UTF-8的区别

本文来自:javaeye网站 UTF8是国际编码,它的通用性比较好,外国人也可以浏览论坛 GBK是国家编码,通用性比UTF8差,不过UTF8占用的数据库比GBK大~ 提示:如果您的网站客户群体主要是面向国内用户的,建议使用GBK版本,因为它可以节省空间,及相对utf-8版本来讲稳定一些.对于DZ论坛来说,很多插件都只支持GBK的,如果需要装较多插件的论坛还是用GBK比较好,而对装较少插件且有特殊用户群的论坛用UTF8比较好. GBK版本与UTF-8版本功能是一样的.只不过编码方式不同. GBK的

网络编码 GB2312、GBK与UTF-8的区别

GB2312.GBK与UTF-8的区别 这是一个异常经典的问题,有无数的新手站长每天都在百度这个问题,而我,作为一个“伪老手”站长,在明白这个这个问题的基础上,有必要详细的解答一下. 首先,我们要明白,GB2312.GBK和UTF-8都是一种字符编码,除此之外,还有好多字符编码.只是对于我们中国人的网站来说,用这三种编码 比较多.简单的说一下,为什么要用编码,在计算机内,储存文本信息用ASC II码,每一个字符对应着唯一的ASCII码.最初计算机是由美国发明的,他们也用的是键盘和上面的字母,所以

解决mysql中表字符集gbk,列字符集Latin1,python查询乱码问题

最近在公司碰到一个异常蛋疼的情况,mysql数据库中,数据库和表的字符集都是'gbk',但是列的字符集却是'latin1',于是蛋疼的事情出现了. 无论我连接字符串的`charset`设置为`gbk`,`utf8`,`latin1`中的任意一种,查询出来的表中数据的中文都是乱码,在查询中加上如下代码也还是无济于事: SET NAMES latin1 在更换各种py链接库,然后疯狂的google和问了各路大神之后,终于找到解决思路如下: 1.通过hex(column)将列中的数据2进制转为16进制

ASCII,Unicode,GBK和UTF-8字符编码的区别联系

ASCII,Unicode,GBK和UTF-8字符编码的区别联系 wyrssktzc11级分类:其他被浏览86次2016.05.27 检举 KingSta逍遥 采纳率:45%7级2016.05.27 ASCII.Unicode.GBK和UTF-8字符编码的区别联系 很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物.他们看到8个开关状态是好的,于是他们把这称为"字节".再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出

GBK与UTF-8编码错误转换后,无法再正确恢复

字符集错误转换导致的问题 UTF-8格式编码的字节流,按GBK字符集转换为字符串,会出现乱码,这很正常.但将其重新转为字节流,再用UTF-8字符集转为字符串,还是乱码.这就让我产生了疑惑,虽然使用错误的字符集必然导致乱码,但字节的信息并没有改变,因此再转为字节流,用正确的字符集解码,应该得到正常的字符串.但事实是,被错误字符集转换过的字符串,无法恢复到原来的字符集. 问题的根本原因 造成该问题的根源是字节发生了变化.GBK或UTF-8遇到无法解析的字符时,会使用特殊的字符代替,因此造成原有字节信