MySQL GBK→UTF-8编码转换

前言：
第一次写教程，其实算不得教程，只是想总结个转换的手记。如果中间有错误,或者办法不够理想，大家回贴研究下。
另外，我也希望我们论坛不仅仅作为闲聊的地方，也希望大家能活跃我们论坛的学习气氛，毕竟我们都来自一个应该给我们知识的地方，不论你从那里获得了多少你需要的知识。

好了，言归正传。

一准备：
环境：MySQL4.1.x及以上版本。
Convertz——文本编码转换工具，molyx上介绍的，我采用的。其实这类工具很多。

二理论：
MySQL从4.1版本开始内部存储字符集支持了UTF-8，这个我也是这几天才看到的。因为升级论坛过程中，服务器数据库环境为4.0.26当时不知道并不支持utf-8字符集，还废了些周折。这样如果涉及到UTF-8转储还要升级MySQL版本到4.1以上。
转换的大概思路是——备份（有备无缓）→修复数据库→mysqldump导出→Convertz转换编码→修改转换后文件→mysqldump导入恢复

三实践：
1、备份。这个不需要太多说了你可以采用任何一种常规的备份方式只要你自己恢复的了。
2、修复。mysqlcheck -r -u user -p 如果全OK那就OK了，如果不全OK，再来遍。还没全OK，不知道怎么弄了。
3、导出。由于latin1为默认存储，所以你需要事先确定你数据库的编码格式。举例，lncz.net原为gbk编码，但存储为latin1，这样导出时应该指定编码为latin1，导出后才能以ANSI形式正确显示gbk的文字。
导出命令：mysqldump database_name field > path --default-character-set=latin1 -u user -p
数据库大需要分段，不然接下来的操作会很麻烦。我是单独把每个表导出来的。当时想法比较简单，因为数据库有坏表，只想在恢复的时候知道哪个表出错单独修复。
4、转换。Convertz用这个软件很简单，不必多说了。
5、修改。我在尝试直接导入恢复数据库时，失败了N次，每次都乱码。仔细想过之后才明白，如果你直接导回去，数据库还是用默认的latin1去存储，而你的现在的编码是utf-8所以它会再进行一次转换便出错了。这里MySQL到底怎么处理的我还不是十分清楚，谁知道麻烦相告。这时我们需要对转换好的文件加入语句 “set names utf8;”注意不是utf-8；并且需要将文件中“CHARSET=latin1;”改为“CHARSET=utf8;”来指定表的存储编码。
6、恢复。恢复过程按道理应该是很简单的，都是mysqldump处理。需要注意一点就是如果你的数据库大，要做全局变量的修改max_allowed_packet默认为1M，看你数据库表的大小，相应修改my.ini文件。
导入命令：mysqldump database_name < path -u user -p 导入顺利的话你的数据库编码就已经转换为utf-8了。


在下比较菜，如果有错误请指正，表笑我。以上仅供参考。 

最新评论