从旧版升级到MySql4.1上的中文乱码问题解决方案

MySQL 4.1 对多语言的支持有了很大变化 (这导致了问题的出现)；
尽管大部分的地方 (包括个人使用和主机提供商)，MySQL 3 仍然占主导地位；但 MySQL 4.1 是 MySQL 官方推荐的数据库，已经有主机提供商开始提供并将会越来越多；
许多 PHP 程序以 MySQL 作为默认的数据库管理软件，但它们一般不区分 MySQL 4.1 与 4.1 以下版本的区别，笼统地称“MySQL 3.xx.xx 以上版本”就满足安装需求了；
因为 latin1 在许多地方 (下边会详细描述具体是哪些地方) 作为默认的字符集，成功的蒙蔽了许多 PHP 程序的开发者和用户，掩盖了在中文等语言环境下会出现的问题；
简单的说，MySQL 自身的变化和使用 MySQL 的 PHP 程序对此忽略，导致了问题的出现和复杂化，而由于大部分用户使用的是英文，使这种问题不被重视。这里提到的 PHP 程序，主要就 WordPress 而言。

MySQL 4.1 字符集支持的原理MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；
安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集，如果没指定，这个值继承自编译时指定的；
启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集，如果没指定，这个值继承自配置文件中的；
此时 character_set_server 被设定为这个默认的字符集；
当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server；
当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；
在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database，也就是这个数据库默认的字符集；
当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；
这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；
简单的总结一下，如果什么地方都不修改，那么所有的数据库的所有表的所有栏位的都用 latin1 存储，不过我们如果安装 MySQL，一般都会选择多语言支持，也就是说，安装程序会自动在配置文件中把 default_character_set 设置为 UTF-8，这保证了缺省情况下，所有的数据库的所有表的所有栏位的都用 UTF-8 存储。

当一个 PHP 程序与 MySQL 建立连接后，这个程序发送给 MySQL 的数据采用的是什么字符集？MySQL 无从得知 (它最多只能猜测)，所以 MySQL 4.1 要求客户端必须指定这个字符集，也就是 character_set_client，MySQL 的怪异之处在于，得到的这个字符集并不立即转换为存储在数据库中的那个字符集，而是先转换为 character_set_connection 变量指定的一个字符集；这个 connection 层究竟有什么用我不大明白，但转换为 character_set_connection 的这个字符集之后，还要转换为数据库默认的字符集，也就是说要经过两次转换；当这个数据被输出时，又要由数据库默认的字符集转换为 character_set_results 指定的字符集。

一个典型的环境典型的环境以我自己的电脑上安装的 MySQL 4.1 为例，我自己的电脑上安装着 Apache 2，PHP 5 和 WordPress 1.5.1.3，MySQL 配置文件中指定了 default_character_set 为 utf8。于是问题出现了：

WordPress 按照默认情况安装，所以所有的表都用 UTF-8 存储数据；
WordPress 默认采用的浏览字符集是 UTF-8 (Options->Reading 中设置)，因此所有 WP 页面的 meta 中会说明 charset 是 utf-8；
所以浏览器会以 utf-8 方式显示所有的 WP 页面；这样一来 Write 的所有 Post，和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache，再由 Apache 交给 PHP；
所以 WP 从所有的表单中得到的数据都是 utf-8 编码的；WP 不加转换的直接把这些数据发送给 MySQL；
MySQL 默认设置的 character_set_client 和 character_set_connection 都是 latin1，此时怪异的事情发生了，实际上是 utf-8 格式的数据，被“当作 latin1”转换成……居然还是转换成 latin1，然后再由这个 latin1 转换成 utf-8，这么两次转换，有一部分 utf-8 的字符就丢失了，变成 ??，最后输出的时候 character_set_results 默认是 latin1，也就输出为奇怪的东西了。
最神奇的还不是这个，如果 WordPress 中设置以 GB2312 格式阅读，那么 WP 发送给 MySQL 的 GB2312 编码的数据，被“当作 latin1”转换后，存进数据库的是一种奇怪的格式 (真的是奇怪的格式，mysqldump 出来就能发现，无论当作 utf-8 还是当作 gb2312 来读都是乱码)，但如果这种格式以 latin1 输出出来，居然又能变回 GB2312！

这会导致什么现象呢？WP 如果使用 MySQL 4.1 数据库，把编码改用 GB2312 就正常了，可惜，这种正常只是貌似正常。

如何解决问题如果你已经不耐烦了 (几乎是肯定的)，google 一下，会发现绝大部分的解答是，query 之前先执行一下：SET NAMES 'utf8'，没错，这是解决方案，但本文的目的是说明，这为什么是解决方案。

要保证结果正确，必须保证数据表采用的格式是正确的，也就是说，至少能够存放所有的汉字，那么我们只有两种选择，gbk 或者 utf-8，下面讨论 utf-8 的情况。

因为配置文件设置的 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。

如果是第二种情况，客户端以 utf-8 格式发送 (WP 的默认情况)，可以采用下述配置:

代码
SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'

这个配置就等价于 SET NAMES 'utf8'。

WP 应该作什么修改还是那句话，客户端要发给数据库什么编码的数据，数据库是不可能确切知道的，只能让客户端自己说明白，所以，WP 是必须发送正确的 SET... 给 MySQL 的。怎么发送最合适呢？台湾的 pLog 同仁给出了一些建议：

首先，测试服务器是否 >= 4.1，编译时是否加入了 UTF-8 支持；是则继续
然后测试数据库以什么格式存储 ($dbEncoding)；
SET NAMES $dbEncoding
对于第二点，WP 的情况是不同的，按照上面的典型配置，只要用 WP，肯定数据库是用 UTF-8 存储的，所以要根据用户设置的以 GB2312 还是 UTF-8 浏览来判断 (bloginfo('charset'))，但这个值是要连接数据库以后才能得到的，所以效率最高的方式是连接数据库之后，根据这个配置设置一次 SET NAMES，而不必每次查询之前都设置一遍。

我的修改方式是这样的，在 wp_includes/wp-db.php 中增加:

代码
function set_charset($charset)
{
// check mysql version first.
$serverVersion = mysql_get_server_info($this->dbh);
$version = explode('.', $serverVersion);
if ($version[0] < 4) return;

// check if utf8 support was compiled in
$result = mysql_query("SHOW CHARACTER SET like 'utf8'",
$this->dbh);
if (mysql_num_rows($result) < = 0) return;

if ($charset == 'utf-8' || $charset == 'UTF-8')
$charset = 'utf8';
@mysql_query("SET NAMES '$charset'", $this->dbh);
}

在 wp-settings.php 的 require (ABSPATH . WPINC . '/vars.php'); 后增加:

$wpdb->set_charset(get_bloginfo('charset'));

---------------------------------------------------------------------------

mysql4.1是比较烦人，支持多语言的细化设置，再加上phpmyadmin2.6也比较笨，默认就是改不动的utf8，怎么弄都乱码。
好了，废话少说，我们来一步步解决这个问题：
1.修改/etc/my.cnf文件，改成这样：

代码
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

注意：就是加入了一句default-character-set=utf8。

2./etc/init.d/mysqld restart 重新启动mysql；
3.打开phpmyadmin，选择lang为"Chines simplifies(zh-utf-8)",选择"MySQL 连接校对"为"utf8_general_ci "点“显示 MySQL 的运行信息”--“变量”，可以看到：

引用
character set client utf8 utf8
character set connection utf8 utf8
character set database utf8 utf8
character set results utf8 utf8
character set server utf8 utf8
character set system utf8 utf8
collation connection utf8_general_ci utf8_general_ci
collation database utf8_general_ci utf8_general_ci
collation server utf8_general_ci utf8_general_ci
从这里可以看到character全部变成utf8了。
有人要问，为什么都要改成utf8呢？改成GB2312不行吗？
解释如下：
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的时候只会用utf8，连其他页面的charset也都是utf8，改成gb2312一定会乱码，我们只能凑phpmyadmin了。
只有在mysql3.23的时候，phpmyadmin才会多一个gb2312的页面charset，这时候是正常的。
3.将以前的mysql3的库文件导入mysql4.1的库
有两种情况：
一是从phpmyadmin上导入，这时候你要注意的是在选择库文件的页面左下脚有个“文件的字符集：”，默认是utf8，要改成gb2312，否则导进去乱码；
二是在linux下导入，这时候你需要先在库文件的头部加一行:
SET NAMES 'gb2312'; 注意最后也是;号，别漏了。
然后执行mysql -u用户名 -p密码 xxx.sql > 库名
导入完成以后再用phpmyadmin打开看，里面的中文字就是正确的。
4.从mysql4.1里导出库文件
一.用phpmyadmin导出
导出倒是问题不大，如果phpmyadmin的浏览页面里显示的中文是正常的，那么导出肯定也是正常的
二.在linux上导出
如果用mysqldump导出出现了乱码也没有关系，可以运行iconv来转换一下
iconv -c -f UTF-8 -t GB2312 库文件名 > 新的gb2312的库文件名

综上所述，你要注意：
1。尽量在需要导入的库文件的开头加入SET NAMES 'gb2312';告诉mysql你要导入的是一个gb2312的文件；
2。可能你需要这个：
SET NAMES 'utf8';
在登陆到mysql后用，把character的一些默认参数改到utf8上，有时可以减少一些困扰，不过也不是必须的。
在mysql上使用:
SHOW VARIABLES LIKE 'character_set_%';
用来查看当前的状态。
3.如果出现乱码也不要怕，一是你要注意留存原有的备份，二是用iconv来进行转化。
在正常使用之前注意做导入导出的测试，确保万无一失。

最后加一句： www.quicklinux.org 原创文章，转载请注明出处。呵呵
邮件：support@quicklinux.org
=================================================
最近discuz发布了新的版本，免费了，用的人更多了，以前使用其它论坛程序和discuz2.5/3.0的纷纷转换或升级到discuz4.0，可见discuz作为中国人开发的php论坛程序，确实是非常优秀的，在大家欣喜若狂的时候，也遇到了一些问题

看到不少用户反映转换完以后是乱码的情况,出现这种现象的主要原因是这类用户使用的都是mysql4.1以上的版本.下面作一个说明,希望出现这个问题的朋友都能耐心的把这个文档看完!!!

MySQL 4.1开始，对多语言的支持有了很大变化 (这导致了问题的出现)。尽管大部分的地方 (包括个人使用和主机提供商)，MySQL 3、4.0 仍然占主导地位；但 MySQL 4.1 乃至5.0是 MySQL 官方推荐的数据库，已经有主机提供商开始提供并将会越来越多；因为 latin1 在许多地方 (下边会详细描述具体是哪些地方) 作为默认的字符集，成功的蒙蔽了许多 PHP 程序的开发者和用户，掩盖了在中文等语言环境下会出现的问题。

MySQL 4.1开始把多国语言字符集分的更加详细，所以导致数据库迁移，或则dz论坛升级到4.0后（dz4.0开始使用gbk或utf-8编码）出现乱码问题。

MySQL 4.1的字符集支持(Character Set Support)有两个方面：字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server)，数据库(database)，数据表(table)和连接(connection)。

查看系统的字符集和排序方式的设定可以通过下面的两条命令：

代码
mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'collation_%';
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.00 sec)

MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；
安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集，如果没指定，这个值继承自编译时指定的；
启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集，如果没指定，这个值继承自配置文件中的；
此时 character_set_server 被设定为这个默认的字符集；
当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server；
当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；
在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database，也就是这个数据库默认的字符集；
当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；
这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；
当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。
想要进行“正确”的存储和得到“正确”的结果，最方便的是在所有query开始之前执行一下：

代码
SET NAMES 'gbk';
其中gbk是数据库字符集。

它相当于下面的三句指令：

代码
SET character_set_client = gbk;
SET character_set_results = gbk;
SET character_set_connection = gbk;

4.1和5.0默认使用的是latin1字符集(木头:妈的,老外真霸道,妄想让全世界都是使用瑞典字符集吗)
如果我们只想使用gbk字符集存储和获取数据,
我们在编译mysql 4.1和 5.0的时候，需要注意在my.ini或者my.cnf中添加两处参数

代码

[mysqld]
default-character-set=utf8

代码

#settings for clients (connection, results, clients)
[mysql]
default-character-set=utf8

下面我们来说主题，如何转换数据库字符集
两种方法，

QUOTE:
第一种----更改存储字符集
主要的思想就是把数据库的字符集有latin1改为gbk，big5,或者utf8; 以下操作必须拥有主机权限。假设当前操作的数据库名为：database

导出
首先需要把数据导为mysql4.0的格式，具体的命令如下：
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse > d4.sql

--default-characte-set 以前数据库的字符集，这个一般情况下都是latin1的，
--set-charset 导出的数据的字符集，这个可以设置为gbk，utf8,或者big5
导入
首先使用下面语句新建一个GBK字符集的数据库（test）

CREATE DATABASE `d4` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;
然后把刚才导出的数据导入到当前的数据库中就ok了。

mysql -uroot -p --default-character-set=gbk -f d4<d4.sql
通过以上的导出和导入就把数据库的字符集改为正确的存储方式了。

其中d4为新建库的名称，d4.sql为导出文件的名字

但是这种方法，发现数据库数据存储量无端变大30%，真是郁闷

QUOTE:
另外一种其实原理相同，但是需要手动操作，一般用于第一种方法失败后的选择
不过这种方法如果数据库很大，估计很难做，因为光打开文件就能让你死机

首先还是用phpmyadmin或者用mysql本身的dump导出 .sql文件

然后用UltraEdit打开你备份的所有xxxx.sql文件，查找

代码

DEFAULT CHARSET=latin1

latin1这里也许是别的，反正是你不想要的，要转成gbk或者big5的字符集
把这个替换为“空”
在查找

代码

CREATE TABLE cdb_sessions (
sid char(6) character set latin1 collate latin1_bin NOT NULL default '',
ip1 tinyint(3) unsigned NOT NULL default '0',
ip2 tinyint(3) unsigned NOT NULL default '0',
ip3 tinyint(3) unsigned NOT NULL default '0',
ip4 tinyint(3) unsigned NOT NULL default '0',
uid mediumint(8) unsigned NOT NULL default '0',
username char(15) NOT NULL default '',
groupid smallint(6) unsigned NOT NULL default '0',
styleid smallint(6) unsigned NOT NULL default '0',
invisible tinyint(1) NOT NULL default '0',
`action` tinyint(1) unsigned NOT NULL default '0',
lastactivity int(10) unsigned NOT NULL default '0',
fid smallint(6) unsigned NOT NULL default '0',
tid mediumint(8) unsigned NOT NULL default '0',
nickname char(15) NOT NULL default '',
UNIQUE KEY sid (sid)
) ENGINE=HEAP MAX_ROWS=1000;
替换为

代码

CREATE TABLE `cdb_sessions` (
`sid` char(6) binary NOT NULL default '',
`ip1` tinyint(3) unsigned NOT NULL default '0',
`ip2` tinyint(3) unsigned NOT NULL default '0',
`ip3` tinyint(3) unsigned NOT NULL default '0',
`ip4` tinyint(3) unsigned NOT NULL default '0',
`uid` mediumint(8) unsigned NOT NULL default '0',
`username` char(15) NOT NULL default '',
`groupid` smallint(6) unsigned NOT NULL default '0',
`styleid` smallint(6) unsigned NOT NULL default '0',
`invisible` tinyint(1) NOT NULL default '0',
`action` tinyint(1) unsigned NOT NULL default '0',
`lastactivity` int(10) unsigned NOT NULL default '0',
`fid` smallint(6) unsigned NOT NULL default '0',
`tid` mediumint(8) unsigned NOT NULL default '0',
`nickname` char(15) NOT NULL default '',
UNIQUE KEY `sid` (`sid`)
) TYPE=HEAP MAX_ROWS=2000;

这一步更为简单的办法就是删除掉关于cdb_sessions表的这一段，将来全新装一个d4，将这个表导出
将其内容复制，粘贴到 sql文件的最后面

保存后，再把这个sql文件导入到你的库中

就OK了
用这两种方法就可以很方便的把4.1和5.0的mysql数据库降级到4.0
简单的过程就是
A导出4.1/5.0的库
B进行处理，转换成gbk字符集
C彻底卸载4.1或者5.0
D安装4.0.26
E然后导入处理完的库

降级的时候导出库可以用这个方法
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse --compatible=mysql40 > d4.sql
这样导出的就是4.0的库勒

至于mysql版本的升级，
如果数据文件中有中文信息，那么将MySQL 4.0的数据文件，直接拷贝到MySQL 4.1中就是不可以的，即便在my.ini中设置了default-character-set为正确的字符集。虽然貌似没有问题，但MySQL 4.1的字符集有一处非常恼人的地方，以gbk为例，原本MySQL 4.0数据中varchar,char等长度都会变为原来的一半，这样存储中文容量不变，而英文的存储容量就少了一半。这是直接拷贝数据文件带来的最大问题。

所以，升级的根本，如果想使用“正确”的字符集，还是先用mysqldump导出成文件，然后导入。

这里顺便提一个我的好友深海写的
用于MySQL4.1的论坛数据库字符集整理工具。

刚写的,处理部分代码可能写得有点龌龊,但是不影响使用,

主要用于处理整理MySQL4.1指定数据库、表、字段的字符集。

适用于将非允许的字符集范围内的数据结构（无数据！！）整理为适合Discuz!允许的字符集范围。

=====================================
PHP下中文编码各种格式间的转换类

Made In Zeal 转载请保留原始链接： http://www.zeali.net/blog/entry.php?id=55
关键字: GB,BIG5,UTF8,Unicode,编码,转换
目前该类库可以实现的编码转换有：简体中文 GB <-> 繁体中文 BIG5 编码互换，简/繁体中文 -> 拼音单向转换， 简/繁体中文 <-> UTF8 编码转换，简/繁体中文 -> Unicode单向转换。

类源代码原作者是Hessian(solarischan@21cn.com)，我合并了一下原来的Sample脚本，同时修改了一下类文件，为类构造函数增加了一个参数以便用户可以方便的在使用的时候设置配置文件路径，这样就可以把这个类包放置在任何可以被访问到的目录下，否则原来的版本下引用class.Chinese.php的文件必须和class在相同的目录下面才行。

/**
* 中文编码集合类库
*
* 目前该类库可以实现，简体中文 <-> 繁体中文编码互换，简体中文、繁体中文 -> 拼音单向转换，
* 简体中文、繁体中文 <-> UTF8 编码转换，简体中文、繁体中文 -> Unicode单向转换
*
* @作者 Hessian(solarischan@21cn.com)
* @版本 1.7
* @版权所有 Hessian / NETiS
* @使用授权 GPL（不能应用于任何商业用途，无须经过作者同意即可修改代码，但修改后的代码必须按照GPL协议发布）
* @特别鸣谢 unknow（繁简转换代码片断）
* @起始 2003-04-01
* @最后修改 2005-07-26
* @访问 公开
*
* 更新记录
*
* ver 1.7 2005-07-26
* 修改了while循环导致的bug。此bug当字符串最后一个字符为"0"的时候将处理错误。
* 受影响方法: CHStoUTF8() , CHStoUNICODE()
* (by Zeal Li ,http://www.zeali.net/)
*
* ver 1.6 2005-05-16
* 构造函数增加了一个参数以便用户可以方便的在使用的时候设置配置文件路径
* (by Zeal Li ,http://www.zeali.net/)
*
* ver 1.5 2003-06-06
* 增加 UTF8 转换到 GB2312、BIG5的功能。
*
* ver 1.4 2003-04-07
* 增加 当转换HTML时设定为true，即可改变charset的值。
*
* ver 1.3 2003-04-02
* 增加 繁体中文转换至拼音的功能。
*
* ver 1.2 2003-04-02
* 合并 简体、繁体中文转换至UTF8的函数。
* 修改 简体中文转换至拼音的函数，返回值更改为字符串，每一个汉字的拼音用空格分开
* 增加 简体中文转换为 UNICODE 的功能。
* 增加 繁体中文转换为 UNICODE 的功能。
*
* ver 1.1 2003-04-02
* 增加 OpenFile() 函数，支持打开本地文件和远程文件。
* 增加 简体中文转换为 UTF8 的功能。
* 增加 繁体中文转换为 UTF8 的功能。
*
* ver 1.0 2003-04-01
* 一个集合了中文简体，中文繁体对应各种编码互换的类库已经初步完成。
*/

例：将 UTF8 编码的文件转为 Latin1编码：

代码
iconv -f "utf-8" -t "latin1" -c your_file_name > new_file_name
或者：

代码
iconv -f "utf-8" -t "latin1" your_file_name > new_file_name

上面的 your_file_name 就是要转码的文件，比如 mydatabase.sql, new_file_name 是转码后生成的新文件的名字。