假如数据库已经设置了utf-8 ,php文件也设置了utf-8 ,但在php文件的查询语句中未添加了 mysql_query("set names utf8")语句,此时php页面显示正常的汉字,没有乱码。但是会发现用可视化工具连接数据库查看数据时,虽然可视化工具也已经设置了utf8编码,但在可视化工具上显示的就是乱码。因此怀疑实际上存入数据库的真实内容就是乱码,而之所以在浏览器显示正常,可能中间又经过了一个逆转化过程,把存在数据库真实乱码数据由转化为了正常数据,然后返回给浏览器,所以浏览器看上去是正常汉字,但实际上数据库中存的内容缺不是正常汉子。

原理分析:【纯属个人理解,不一定准确】

在mysql数据库中有3个变量:
character_set_client
character_set_connection
character_set_results
你可以分别理解为:客户端、连接器、返回值

客户端 :通常有cmd下的命令行,或者浏览器
连接器 :这个比较抽象,我们看不到,应该是在mysql数据库中的
返回值 :
就是以什么样的字符编码来给客户端

我们一般在cmd下set names gbk 或者php文件中 mysql_query('set names utf8'),其实就是相当于同时设置上面所说的3个变量的值为 gbk 或者 utf8 ,也就是客户端、连接器、返回值都为一样的字符编码,如果你足够耐心也可以再mysql命令行下分别设置这3个变量的值,比如:
set
character_set_client =gbk;
set character_set_connection = gbk;
set
character_set_results = gbk;

 

现在分析最开头提出的问题:数据库已经设置了utf-8 ,php文件也设置了utf-8 ,但未添加了mysql_query("set names utf8")语句,用浏览器查看,如果你的浏览器应该是urf8字符集,那在浏览器上显示正常汉字,但可视化的数据库连接工具显示的是乱码。我怀疑数据库中的内容就是乱码。

其实,问题应该就是出在连接器这个环节上。字符集设置有个限制,那就是字符集编码的大小,应该是这个规律: 客户端 <= 连接器 <= 服务端

那么我在说下连接器的作用,连接器就是接受客户端传来的数据,先接受保存起来,在转换成服务端所需的字符编码。比如客户端是GBK ,连接器也是GBK,服务端是UTF8,那么 连接器就会把客户端传来的GBK数据先存储起来,转换成服务器的UTF8后传给服务器。

那么回到字符集设置规律上,GBK存储汉字需要2个字节,UTF8存储汉字需要3个字节 ,如果你的客户端是UTF8,而连接器是GBK,那么就会在存储上出现问题,所以存入数据库后就会乱码【连接器接收到客户端数据是二进制码,一律认为是GBK码(但实际上客户端可能设置的是utf8码),把这个实际是utf8码的数据当成了GBK码利用公式f(x)转换为了自己认为的utf8码,也就是把真实的utf8数据进行了f(x)转换,也就成了乱码。本来如果不转换就没问题,但它多余的做了一步转换工作,所以最终存在数据库中的数据是乱码了。当我们从浏览器要求取数据时,由于连接器又进行了一步逆转换f'(x),所以数据库中的乱码数据又在页面恢复正常了】。

总结:由上面的分析可见,如果数据库已经设置了utf8编码,在浏览器页面存入数据库数据时,一定要加上mysql_query("set names utf8")语句,这样连接器才不会多余的进行一次f(x)转换,存入数据库的数据才是正常的汉字数据,否则虽然在浏览器看到的数据可能是正常汉字,但数据库中存的可能是乱码。总之,一定要保持连接器和数据库的字符集一样,而mysql_query("set names utf8")语句就是起到这个作用。