假如数据库已经设置了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")语句就是起到这个作用。
