在这里让我们一起学习，一起提高！
Mysql数据库的字符编码转换还真是相当的麻烦
当初不小心用了GBK现在要回到utf-8，而数据已经非常大了
网上找了无数资料，一般都是利用mysqldump加iconv再导回去，但做了之后发现会有错误。还有比较夸张的方法是用编辑器来转换编码，这对于海量数据根本行不通。
最后还是利用了Navicat来解决。
我使用的方法比较保险，用了远程和本地两个数据库。
远程的是gbk编码，想转成utf-8的。
直接在Navicat中建立两条连接，一条是连接远程的，将连接字符编码设置为gbk。
本地设置为utf-8或者数据库默认是utf-8就选择默认的连接字符编码。
选择使用DATA TRANSFER并按步骤将远程数据库中的数据传到本地上。
完成后可以检查本地的数据，应该就是utf-8格式了，修改连接字符编码再将本地的数据导到远程的。
这样就实现了数据库字符编码的转换工作，而且相当的安全。
当初不小心用了GBK现在要回到utf-8，而数据已经非常大了
网上找了无数资料，一般都是利用mysqldump加iconv再导回去，但做了之后发现会有错误。还有比较夸张的方法是用编辑器来转换编码，这对于海量数据根本行不通。
最后还是利用了Navicat来解决。
我使用的方法比较保险，用了远程和本地两个数据库。
远程的是gbk编码，想转成utf-8的。
直接在Navicat中建立两条连接，一条是连接远程的，将连接字符编码设置为gbk。
本地设置为utf-8或者数据库默认是utf-8就选择默认的连接字符编码。
选择使用DATA TRANSFER并按步骤将远程数据库中的数据传到本地上。
完成后可以检查本地的数据，应该就是utf-8格式了，修改连接字符编码再将本地的数据导到远程的。
这样就实现了数据库字符编码的转换工作，而且相当的安全。
MySQL数据库字符集的默认配置：
在mysql的配置文件中把默认的字符集改成utf8，这样创建数据库和表的时候，默认的字符集就是utf8。
MySQL的几个变量：
当一个 PHP 程序与 MySQL 建立连接后，这个程序发送给 MySQL 的数据采用的是什么字符集？mysql如何检测并判断使用何种字符集？要注意以下几个变量：
character_set_server：这是设置服务器使用的字符集
character_set_database：这是设置数据库使用的字符集
character_set_client ：这是设置客户端发送Query串使用的字符集
character_set_connection ：这是设置服务器需要将收到的查询串转换成的字符集
character_set_results ：这是设置服务器要将结果数据转换到的字符集，转换后才发送给客户端
因为配置文件设置的 default_character_set 是 utf8，数据表默认采用的就是 utf-8 建立的。这也应该是所有采用 MySQL 4.1 的主机提供商应该采用的配置。所以我们要保证的只是客户端与 MySQL 交互之间指定编码的正确。
这只有两种可能，客户端以 gb2312 格式发送数据，或者以 utf-8 格式发送数据。
如果以 gb2312 格式发送:
SET character_set_client='gb2312'
SET character_set_connection='utf8' 或者
SET character_set_connection='gb2312'
都是可以的，都能够保证数据在编码转换中不出现丢失，也就是保证存储入数据库的是正确的内容。
怎么保证取出的是正确的内容呢？考虑到绝大部分客户端 (包括 WP)，发送数据的编码也就是它所希望收到数据的编码，所以:
SET character_set_results='gb2312'
可以保证取出给浏览器显示的格式就是 gb2312。不过这样的缺点是不论是插入、更新、删除还是查询操作，只要是操纵数据库，都要先执行SET NAMES "gb2312"，这样才能保证插入和显示的正确性。如果插入操作前没有执行这条语句，仅在查询时执行该语句，则仍然无法保证显示的正确性。
如果是第二种情况，客户端以 utf-8 格式发送 (WP 的默认情况)，可以采用下述配置:
SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'
这个配置就等价于 SET NAMES ‘utf8′。
在mysql的配置文件中把默认的字符集改成utf8，这样创建数据库和表的时候，默认的字符集就是utf8。
MySQL的几个变量：
当一个 PHP 程序与 MySQL 建立连接后，这个程序发送给 MySQL 的数据采用的是什么字符集？mysql如何检测并判断使用何种字符集？要注意以下几个变量：
character_set_server：这是设置服务器使用的字符集
character_set_database：这是设置数据库使用的字符集
character_set_client ：这是设置客户端发送Query串使用的字符集
character_set_connection ：这是设置服务器需要将收到的查询串转换成的字符集
character_set_results ：这是设置服务器要将结果数据转换到的字符集，转换后才发送给客户端
因为配置文件设置的 default_character_set 是 utf8，数据表默认采用的就是 utf-8 建立的。这也应该是所有采用 MySQL 4.1 的主机提供商应该采用的配置。所以我们要保证的只是客户端与 MySQL 交互之间指定编码的正确。
这只有两种可能，客户端以 gb2312 格式发送数据，或者以 utf-8 格式发送数据。
如果以 gb2312 格式发送:
SET character_set_client='gb2312'
SET character_set_connection='utf8' 或者
SET character_set_connection='gb2312'
都是可以的，都能够保证数据在编码转换中不出现丢失，也就是保证存储入数据库的是正确的内容。
怎么保证取出的是正确的内容呢？考虑到绝大部分客户端 (包括 WP)，发送数据的编码也就是它所希望收到数据的编码，所以:
SET character_set_results='gb2312'
可以保证取出给浏览器显示的格式就是 gb2312。不过这样的缺点是不论是插入、更新、删除还是查询操作，只要是操纵数据库，都要先执行SET NAMES "gb2312"，这样才能保证插入和显示的正确性。如果插入操作前没有执行这条语句，仅在查询时执行该语句，则仍然无法保证显示的正确性。
如果是第二种情况，客户端以 utf-8 格式发送 (WP 的默认情况)，可以采用下述配置:
SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'
这个配置就等价于 SET NAMES ‘utf8′。
一直对utf8_unicode_ci与utf8_general_ci这2个校对集很迷惑，今天查了手册有了点眉目。不过对中文字符集来说采用utf8_unicode_ci与utf8_general_ci时有何区别还是不清楚？
下面摘录一下Mysql 5.1中文手册中关于utf8_unicode_ci与utf8_general_ci的说明：
当前，utf8_unicode_ci校对规则仅部分支持Unicode校对规则算法。一些字符还是不能支持。并且，不能完全支持组合的记号。这主要影响越南和俄罗斯的一些少数民族语言，如：Udmurt 、Tatar、Bashkir和Mari。
utf8_unicode_ci的最主要的特色是支持扩展，即当把一个字母看作与其它字母组合相等时。例如，在德语和一些其它语言中‘ß’等于‘ss’。
utf8_general_ci是一个遗留的 校对规则，不支持扩展。它仅能够在字符之间进行逐个比较。这意味着utf8_general_ci校对规则进行的比较速度很快，但是与使用utf8_unicode_ci的 校对规则相比，比较正确性较差）。
例如，使用utf8_general_ci和utf8_unicode_ci两种 校对规则下面的比较相等：
Ä = A
Ö = O
Ü = U
两种校对规则之间的区别是，对于utf8_general_ci下面的等式成立：
ß = s
但是，对于utf8_unicode_ci下面等式成立：
ß = ss
对于一种语言仅当使用utf8_unicode_ci排序做的不好时，才执行与具体语言相关的utf8字符集 校对规则。例如，对于德语和法语，utf8_unicode_ci工作的很好，因此不再需要为这两种语言创建特殊的utf8校对规则。
utf8_general_ci也适用与德语和法语，除了‘ß’等于‘s’，而不是‘ss’之外。如果你的应用能够接受这些，那么应该使用utf8_general_ci，因为它速度快。否则，使用utf8_unicode_ci，因为它比较准确。
下面摘录一下Mysql 5.1中文手册中关于utf8_unicode_ci与utf8_general_ci的说明：
当前，utf8_unicode_ci校对规则仅部分支持Unicode校对规则算法。一些字符还是不能支持。并且，不能完全支持组合的记号。这主要影响越南和俄罗斯的一些少数民族语言，如：Udmurt 、Tatar、Bashkir和Mari。
utf8_unicode_ci的最主要的特色是支持扩展，即当把一个字母看作与其它字母组合相等时。例如，在德语和一些其它语言中‘ß’等于‘ss’。
utf8_general_ci是一个遗留的 校对规则，不支持扩展。它仅能够在字符之间进行逐个比较。这意味着utf8_general_ci校对规则进行的比较速度很快，但是与使用utf8_unicode_ci的 校对规则相比，比较正确性较差）。
例如，使用utf8_general_ci和utf8_unicode_ci两种 校对规则下面的比较相等：
Ä = A
Ö = O
Ü = U
两种校对规则之间的区别是，对于utf8_general_ci下面的等式成立：
ß = s
但是，对于utf8_unicode_ci下面等式成立：
ß = ss
对于一种语言仅当使用utf8_unicode_ci排序做的不好时，才执行与具体语言相关的utf8字符集 校对规则。例如，对于德语和法语，utf8_unicode_ci工作的很好，因此不再需要为这两种语言创建特殊的utf8校对规则。
utf8_general_ci也适用与德语和法语，除了‘ß’等于‘s’，而不是‘ss’之外。如果你的应用能够接受这些，那么应该使用utf8_general_ci，因为它速度快。否则，使用utf8_unicode_ci，因为它比较准确。
