最近遇到mysql乱码的问题，找了些资料，先保存，后面慢慢总结自己的处理方法。
笔记：
问题环境总结：
1.前台php代码没有改变
2.原数据库，所有表的都是utf8
mysql> show variables like '%char%';
+--------------------------+----------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /pub/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------+
备份库的编码（mysql主从复制过来的）：
mysql> show variables like '%char%';
+--------------------------+----------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /opt/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------+
8 rows in set (0.00 sec)
另一个数据库（数据库三），数据完全复制的备份库的文件。
问题来了：
1.现有的php前台连接数据库三所读出来的数据都是乱码，连接备份库和原数库都是正常的
2.换了一个php的环境（即前台服务器），连接三个库又都正常了
续：
今天又看了些资料，发现之前有一个误区，就是查变量的时候不应该用（show variables like '%char%';）而应该加上global去查看
这样才是真正php在不加set names ’charname‘的情况下所使用的编码。
mysql> show global variables like '%char%';
+--------------------------+----------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /pub/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------+
8 rows in set (0.00 sec)
以下是解决方法：
生产环境正确做法和步骤：
1.在配置文件my.cnf中 [client] 增加 default-character-set =utf8 ,会立即对本机上的新创建连接生效
2.在配置文件my.cnf中 [mysqld] 增加 default-character-set =utf8 ，待mysqld服务重新启动后生效
3. 执行SET语句修改字符集，对非本机新创建的连接也会生效
SET GLOBAL character_set_clinet=utf8;
SET GLOBAL character_set_connection=utf8;
SET GLOBAL character_set_database=utf8;
SET GLOBAL character_set_results=utf8;
SET GLOBAL character_set_server=utf8;
4.对于之前的连接线程，则没有办法，除非他们自己设置为utf8 或者等待其断开重新连接
转自：http://blog.csdn.net/martinkro/article/details/5352474
1 MYSQL中的字符集概念
Mysql的字符集里有两个概念，一个是"Character set（字符集）"，另一个是"Collations"。
1.1 Collations
Collations翻成中文是"校验"，在网页开发的过程中，这个词汇，只在Mysql里使用，主要作用是指导Mysql对字符的比较，比如， ASCII字符集里，Collations规定了a小于b，a等于a，以及a是否等于A之类的。通常，大家基本可以忽略Collations的存在，因为每个字符集都有一个默认的Collations，通常，使用默认的Collations就可以了。
1.2 Character set
与这对比的是，字符集是个更广的概念，即使是Windows下普通的文本文件，也渗及到字符集的问题。不同的字符集，规定了不同的字符的编码方式。一个 character set (字符集)是一组符号和编码，比如，ASCII字符集，包括的字符有：数字，大小写字母，分号、换行之类的符号，编码方式是用一个7bit表示一个字符（A的编码是65，b的编码是98）。ASCII只规定了英文字母的编码，非英文语言不能用ASCII编码表示，为此，不同的国家，都为自己的语言做了编码，比如，我们国家，就有GB2312编码。但每个国家之间的编码不同，也存在着一些跨平台的问题，为此，一些国际化标准组织，就制定了一些国际通用的编码，最常用的就是UTF8了。ASCII只对英文符号和英文字母做了编码，GB2312对英文符号，英文字母，汉字做了编码，UTF8对世界上所有的语言文字做了编码，所以，GB1212的字符包含了ASCII字符，UTF8包含了GB2312字符。由此可见，UTF8是所含最广字符的字符集，所以，在一些多语言的WEB系统中，一般用UTF8字符集（PHPMyAdmin使用UTF8编码）。
任何文本的存储，都渗及到字符集的概念。包括数据库，也包括普通的文本文件。
编码和字符集两个概念极易混淆，因为一般情况下，编码的名字和字符集的名字相同，如：GB2312既是一种字符集的名字，也是一种编码格式的名字。
字符：汉字，英文字母，标点符号，拉丁文等等。
编码：将字符转换成计算机存储的格式，比如，A用65表示。
字符集：一组字符以及对应的编码方式。
可见字符集和编码是两个不同的概念。一个字符集可以有多种编码方式，如Unicode字符集就有UTF-8、UTF-16、UTF-32等编码方式。 charset=utf-8，在网页中的意思是该页面时采用Unicode字符集，并采用UTF-8编码方式。
1.3 Mysql的字符集
Mysql目前支持多字符集，并且，支持在不同的字符集之间转换（便于移植和支持多语言）。
Mysql可以设置服务器级字符集、数据库级字符集、数据表级字符集、表列的字符集，实际上，最终使用字符集的地方是存储字符的列，比如，你设置 table1中col1列是字符类型，col1才用到了字符集，如果table1表的col2列是int类型，col2不使用字符集的概念。
服务器级字符集、数据库级字符集、数据表级字符集都是为列的字符集做默认选项的。
Mysql 一定有一个字符集，可以通过启动时加参数指定，也可以编译时指定，也可以在配置文件里指定。Mysql服务器字符集，只是做为数据库级的默认值。创建数据库时，你可以指定字符集，如果没指定，就使用服务器的字符集。同理，创建表时，你可以指定表级的字符集，如果没指定，使用数据库的字符集做为表的字符集。创建列时，你可以指定某列的字符集，如果没指定，就使用表的字符集。
通常情况下，您只需设置服务器级的字符集，其它的数据库级，表级，以及列级的字符集，都继承自服务器级字符集。
由于UTF8是最广的字符集，所以，一般情况下，我们设置Mysql服务器级的字符集为UTF8。
MYSQL中字符集的继承关系
服务器字符集(在配置文件中设置字符集的方式：my.ini [mysqld] default-character-set=utf8)
|
|
|
数据库级字符集(如果创建数据库是指定了字符集，则使用指定的字符集。如果没有，则使用服务器级的字符集)
|
|
|
表级字符集(创建表时指定了字符集，则使用指定的字符集。如果没有，则使用数据库级的字符集)
|
|
|
列级字符集(创建表时指定了列的字符集，则使用指定的字符集。如果没有，则使用表级的字符集)
可见最终使用字符集的地方是存储文本的列。
2 普通文本的字符集问题
任何文本的存储，都存在着字符集的问题，普通文本文件也不例外。
Windows2000+的系统中，打开记事本，"保存为..."对话框，就有一个选项，可以让你选择存储文本的编码方式。
通常情况下，大家都使用Windows2000+的系统，都使用默认的编码，所以，不会碰到字符集的问题。
Windows下，保存文本文件时，可以选择编码方式，但打开文本文件时，都是自动判断编码方式的。网上有一个用Windows2000+的记事本玩移动，联通的笑话，大家可以搜搜，就是因为Windows在打开文本文件时，编码判断错误引起的问题。
因为自动判断编码有时会错误，所以，有的文本文件，规定了如何识别自身所使用的编码。HTML文件就是一个这样的例子。
HTML是文本文件。存储HTML文件的时候，需要使用一个编码，并且，在HTML文件里，也使用HTML语法，指定了该文件所使用的编码（比如）。如果HTML文件没有指定编码，则浏览器自动识别文件的编码。如果HTML指定了编码，则浏览器使用HTML指定的编码。
通常情况下，HTML文件指定的charset和HTML文件自身的编码是一致的，但也有不一致的情况，如果不一致，就会导致网页乱码(此处乱码，只和文本文件有关，和数据库无关。)使用专门的网页编辑工具（比如Dreamwave），会自动根据网页中的charset值来编码文件。
例如：test.html
内容如下：
<h1>123地方活动家恢复搭街坊456</h1>
不管上述文件保存时使用什么编码方式，用浏览器打开都会正常，不会出现乱码。这是因为浏览器能自动识别编码格式。
将上述文件内容该为:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<h1>123地方活动家恢复搭街坊456</h1>
这时test.html不使用UTF-8编码格式保存，浏览器打开一定会出现乱码。因为浏览器将使用UTF-8编码来解析收到的数据。
3 php+mysql的字符集问题
PHP最终生成的是文本文件，但他要取数据库里的文本，或将文本存进数据库。
由于Mysql支持多字符集，默认情况下，Mysql不知道PHP发给他的是什么编码的字符，所以，Mysql要求客户端（PHP）告诉他存取的字符集是什么。
PHP通过设置character_set_client，告诉Mysql，PHP存进数据库的是什么编码方式。
PHP通过设置character_set_results，告诉Mysql，PHP需要取什么样编码的数据。
PHP通过设置character_set_connection，告诉Mysql，PHP查询中的文本，使用什么编码。
MYSQL使用设置的编码方式存储文本。
假设Mysql使用setserver来存储文本，PHP的character_set_client是setclient，PHP的 character_set_results是setresult。那么，Mysql将PHP发来的文本，从setclient编码方式，转换成 setserver编码方式，再存入数据库，如果PHP取文本，Mysql将文本从setserver转换成setresult，再发送给PHP。
PHP文件（最终生成的HTML文件）本身有个编码，如果Mysql传过来的编码，与PHP文件自身的编码不同，那么，整个网页，必然乱码。所以，PHP一般将自己的编码方式，告诉Mysql。
要保证不乱码，就必须将三个编码统一：一是网页自身的编码，二是HTML里指定的编码，三是PHP告诉Mysql的编码(包括character_set_client和character_set_results)。
第一和第二个编码，如果使用DW之类的编辑器写的网页，通常是一致的，但用记事本写的网页，有可能不一致。
第三个编码，需要手工通知Mysql。这步可以通过在PHP里使用mysql_query("set names characterX")来实现。