MySQL的字符集怎么处理

　　发送请求

　　客户端(character_set_client)=》数据库连接(character_set_connection)=》存储(table,column)

　　返回请求

　　存储(table,column)=》数据库连接(character_set_connection)=》客户端(character_set_results)

　　在每一个非初始节点，都会做一次从上一个结点到当前节点的字符集转换操作。举个例子，有如下环境：

　　character_set_connectionutf-8character_set_resultsgbkcharacter_set_clientgb2312有表A，字段字符集全部为BIG5

　　发送请求的时候，首先数据从gbk转换为utf-8，再转换为BIG5，然后再存储。

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

　　MySQL字符集架构作用有哪些

　　1.允许不同的客户端具有不同的字符集。典型的例子就是，我有一个utf-8的站点，这个站点就是一个charsetclient为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之间的字符集操作，是忽略字段类型的，在这两个节点之间，依然会进行字符集转换。

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

　　计算机要准确的处理各种字符集文字，需要进行字符编码，以便计算机能够识别和存储各种文字。