首页  > 计算机 >

MySQL的字符集架构有必要这样吗?

本文按署名·非商业用途·保持一致授权
作者:  ,发表于2009年02月20日21时46分 

最近几个月,我每次用MySQL,几乎都会想:MySQL现在如此层次分明的字符集架构作用真的很大吗?

MySQL的字符集处理是这样的:
1)发送请求
客户端(character_set_client)=》数据库连接(character_set_connection)=》存储(table,column)
2)返回请求
存储(table,column)=》数据库连接(character_set_connection )=》客户端(character_set_results)

在每一个非初始节点,都会做一次从上一个结点到当前节点的字符集转换操作。举个例子,有如下环境:
* character_set_connection utf-8
* character_set_results gbk
* character_set_client gb2312
* 有表A,字段字符集全部为BIG5

发送请求的时候,首先数据从gbk转换为utf-8,再转换为BIG5,然后再存储。
返回请求的时候,首先数据从BIG5转换为utf-8,再转换为gb2312,然后再发送给客户端。

这样的架构到底有什么用呢?
1)允许不同的客户端具有不同的字符集。典型的例子就是,我有一个utf-8的站点,这个站点就是一个charset client为utf-8的客户端。与此同时,我有可能需要在一个gbk的终端上读写数据库,这又是一个客户端,不过它的字符集是gbk。
2)通过数据库操作文件系统的时候,需要把文件路径转为文件系统的字符集。例如我的客户端是gbk,而服务器文件系统是utf-8。操作”/A片/Rina.rmvb”,发送过去的数据里,“片”的数据和服务器是不一样的。这时候就需要有个办法可以把转换GBK的“片”到utf-8。在这里MySQL引入了一个叫character_filesystem的东西来完成这个事情。

除此之外,我暂时想不到其他的作用了。但是仔细想想,我们真的需要这样的处理吗?很多网站,无非就是希望自己的数据能怎么进去就怎么出来。这里又有两种情况了。
1)希望可以根据数据进行排序或者做like操作。首先说排序,对于包含中文的字段来说,根据字符集排序的概念如同鸡肋。简体中文排序,一般都是希望按拼音来排序。我没有去真正了解过MySQL里的校验,但是从我接触过的程序来看,需要做此类排序,都是专门建一个存放拼音的字段来排序。而拼音又存在多音字的情况。如果是UTF-8,还存在某个区间的中文同时被中日韩三国共用的情况。实现起来不是这么容易,所以MySQL无论的GBK还是UTF-8的校验集应该都没有实现拼音。我敢说,现在国内使用MySQL的大多数网站,所用到的校验集,只是一个byte排序而已。而byte排序,根本不需要使用什么字符集。所以说对于中文站点,MySQL字符校验在排序上没任何意义。

但是在like操作上,倒是有了一点点意义。例如我like ‘%a%’,就有可能匹配到某个中文某个部分含有a。当然这种情况在utf-8下不会遇到,因为utf-8的存储格式导致a只可能是a,不可能是一个多字节字符的一部分。但是在其他字符集可能就会有这个问题了。说到最后,like又变得和order一样使得校验没意义了。晕倒。

2)如果完全不需要对数据进行排序,like或者全文检索,那么请停止使用char,varchar,text之类的吧。binary,varbinary,BLOB才是正确的选择。binary之类的在存储,取出的时候都不会进行字符集转换,而在排序时候,只根据二进制内容排序,所以在效率上高出char,varchar,text很多。

这种情况更不需要字符集了。但是按照目前MySQL的架构,在client和connection之间的字符集操作,是忽略字段类型的,在这两个节点之间,依然会进行字符集转换。

说了这么多,我都不知道说什么了。本来是想说MySQL的字符集看似强大实则无用。但是写下来,发现勉强还有一点作用。另外前段时间想总结一下MySQL的字符集,不过没写完。

另外提一下PHP里的设置字符集。大家请不要再使用mysql_query(“set names utf8″)这样的语句了。mysql_set_charset()才是最完整的字符集设置方式。后者比前者多一个设置,就是把struct MySQL的charset成员也设置了。这个成员变量在escape的时候起着很重要的作用,特别是对于GBK这种运行把“\”作为字符一部分的编码格式。如果你只使用mysql_query(“set names XXX”),那么在某些字符集,会有重大的安全漏洞,导致mysql_real_escape_string变得和addslashes一样不安全。

在计算机技术里,字符集是我很喜欢研究的一个东西。我接触的东西,我都希望把字符集处理方式弄清楚。这是因为我在3年前,对字符集完全不理解。对于完全不理解的东西,我总是很渴望去完全理解它。

BTW:随着各种多字节字符集的广泛应用,而在软件开发里人数比例非常高的操英文的程序员对多字节字符并不是很了解,这是最近几年很多漏洞都是多字节引起的一个原因。我们中日韩的程序员在这方面有优势,顶了!



2个评论

  1. ShiningRay:

    虽然我比较和楼主一样讨厌这个问题
    我听说过这样一种情况,对于中文而言,gb2312编码后的字符串大小要比utf-8小,更比unicode小
    比如尤其在海量存储的时候,就更加明显了,不知道有没有这方面的意图。

  2. SurfChen:

    @ShiningRay
    首先想提一点,unicode并非一种存储格式,而是一个抽象的字符集。你说的unicode,实际上是utf-16。utf-8和utf-16都是unicode的一种存储格式。

    相同的中文,gb2312的存储空间当然是比utf-8和utf-16要小的。当然gb2312并不能完全存储所有unicode的字符,所以无论是utf-8,还是utf-16,都无法和gbk对等替换,因此也无法在前端使用utf-8,后端使用gb2312了。

    而且,既然希望用GB2312作为存储格式,那么为何不直接在前端也使用GB2312呢?

    不过我倒是觉得可以用utf-16来存储中文信息比较多的数据,因为中文几乎都是属于BMP,在utf-16里,BMP都是二字节的。

发表评论

  本站文章若无注明,则以署名·非商业用途·保持一致授权
  桂ICP备05004302号 感谢WordPress提供本程序 本模板下载