第一个方法：

MySQL 4.1 中文乱码的问题

最近要将 MySQL 4.0 升级到 MySQL 4.1 ，发现了中文乱码的问题，希望以下见解对大家有用。

1. MySQL 4.1 在文字上有很大改进，它有了 Character Set 与 Collation 的慨念。

2. 在 MySQL 4.0 ，一般的程式都会将文字以拉丁文 ( latin) 来储存，就算我们输入中文字，结果仍是放在以拉丁文设置的文字栏里头，这对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来说，并不会有问题。

3. 可是 MySQL 4.1 的系统编码是预设用 UTF-8 的，当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时，乱码就出现了。原因在于 MySQL 4.1 将 latin 码转换过来，而后转换是并不完全完美的，这导致了出现少量文字出现乱码现象。

解决PHP存取MySQL 4.1乱码问题

从MySQL 4.1开始引入的多语言支持确实很棒，而且一些特性已经超过了其他的数据库系统。不过我在测试过程中发现使用适用于MySQL 4.1之前的PHP语句操作MySQL数据库会造成乱码，即使是设置过了表字符集也是如此。我读了一下新的MySQL在线手册中第十章 "Character Set Support"后终于找到了解决方法并测试通过。

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

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

上面列出的值就是系统的默认值。如果你奇怪系统怎么默认是latin1的瑞典语排序方式,原因是MySQL由瑞典的T.c.X.DataKonsultAB公司(目前公司名称为MySQL AB)开发，不用再多说了吧。

当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句：

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

再试试看，正常了吧？

就是连接之后加个查询

看了手册第10章觉得主要还是Character Sets的问题。

character_set_client，character_set_results，character_set_connection三个运行变量是造成乱码的关键。mysql把客户端提交的查询由character_set_client转换为character_set_connection

，由于默认网页提交的查询是gb2312(表单页面meta里可以看到)，而mysql默认将其当作utf8（可以查到此时的 character_set_client＝utf8），所以必然乱码。同理，mysql返回的结果是已经转换成 character_set_results编码的（与表的编码无关），同样默认是utf8，而网页页面把它当gb2312处理，所以必然有标题等由数据库读出的字段是乱码而其他部门文字不乱码的现象。
一起jquery,17jquery

以上这个例子是utf8字符集，用此方法，设置为gbk，即可解决

第三个方法：

mysql 4.1乱码终极解决方案

请注意，本文只针对mysql 4.1，其它版本的mysql请看别的文章。

mysql4.1是比较烦人，支持多语言的细化设置，再加上phpmyadmin2.6也比较笨，默认就是改不动的utf8，怎么弄都乱码。

好了，废话少说，我们来一步步解决这个问题：

1.修改/etc/my.cnf文件，改成这样：

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

2./etc/init.d/mysqld restart 重新启动mysql；

3.打开phpmyadmin，选择lang为"Chines simplifies(zh-utf-8)",选择"MySQL 连接校对"为"utf8_general_ci "点“显示 MySQL 的运行信息”--“变量”，可以看到：

一起jquery,17jquery

从这里可以看到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的浏览页面里显示的中文是正常的，那么导出肯定也是正常的
内容来自17jquery

二.在linux上导出

如果用mysqldump导出出现了乱码也没有关系，可以运行iconv来转换一下

iconv -c -f UTF-8 -t GB2312 库文件名 > 新的gb2312的库文件名

综上所述，你要注意：

1。尽量在需要导入的库文件的开头加入SET NAMES 'gb2312';告诉mysql你要导入的是一个gb2312的文件；

2。可能你需要这个：

在登陆到mysql后用，把character的一些默认参数改到utf8上，有时可以减少一些困扰，不过也不是必须的。

在mysql上使用:

用来查看当前的状态。

3.如果出现乱码也不要怕，一是你要注意留存原有的备份，二是用iconv来进行转化。

在正常使用之前注意做导入导出的测试，确保万无一失。

下面再说明一下,网上很多朋友说Mysql4.1的只能升,不能降. 这是不正确的. 同样使用mysqldump 导出数据库时加一个 --compatible 的参数.也千万不能忘了--default-character-set=这个设定字符集的参数.

示范: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql

ok 这样导出来的文件,就可以在Mysql4.0.X和Mysql.3.2.X版本中使用了.

Linux下 Mysql 5 中文乱码的彻底解决及应用的一些注意事项
一起jquery,17jquery

一. 自从mysql4.1开始，mysql对中文的支持问题是比较烦人的，怎么弄都乱码，如今mysql5 据说是mysql的新纪元，但从官方下载安装的mysql5仍存在乱码现象，这里就是针对此现象做的讨论：

建议最好是下载mysql的源码进行编译，这是由于官方编译的mysql的默认支持编码是latin字符集，所以中文字符在数据库里查看的时候看到的是乱码。编译MySQL时使用withcharset=编码，可以方便地把mysql编译成该编码形式，这样MySQL就会直接支持中文查找和排序，-- with-extra-charsets参数指定其它可用的字符集。

下载并解压源码包，打开INSTALL-SOURCE，这里介绍了linux下详细的安装方法，所以大家所要注意的只是下面的configure指令：

内容来自17jquery

你可以看到全局的字符集参数全是gbk，gb2312字集应该包含在gbk里，所以不讨论。

进行和平常mysql4.0一样的php操作，你会发现仍然出现中文乱码现象。

这里要说明的是：从mysql 4.1开始，必需在mysql数据库连接后对应用的字符集做出说明，否则非英文字母的文字存取都无法解释变成?号。

解决方法就是要适应新版mysql的要求：

在连接mysql数据库后执行set character set 字符集，该指令在最新版的mysql 5如果默认字集和存储相符可以免设：

在php里应该是这么写:mysql_query("set character set gbk");

指令大小写均可

phpwind和discuz是广泛应用的国产php论坛，大量的朋友在应用它，了解了以上步骤，你也可以对论坛源码进行很小的修改，安全地把数据库升级到mysql5：

找到include/db_mysql.php，修改function connect(...){.....}

在选择数据库mysql_select_db($dbname);后面加上一句mysql_query('set character set gbk');存盘。

二. 文件的导入导出：如果存入非gbk字符，这时候你需要先在导入文件的头部加一行: SET NAMES '字符集'; 并注意最后也是;号，别漏了。

文件导入和导出执行

mysql -u用户名 -p密码 数据库名
一起jquery,17jquery

mysqldump -u用户名 -p密码 数据库名>data.sql

如果用mysqldump导出数据出现了乱码也没有关系，可以运行iconv来转换一下：

iconv -c -f utf8 -t gbk 库文件名>新的gbk的库文件名

综上所述，你要注意：

1。尽量在需要导入的库文件的开头加入set names 'gbk';告诉mysql你要导入的是一个gbk的文件；

2。在mysql上使用 show variables;或show variables like 'character_set_%'; 用来查看当前的字集状态。

3。如果出现乱码也不要怕，其一是你要注意留存原有的备份，其二是用iconv来进行转化。

#PHP连接问题：

由于MySQL 4.1版本开始密码的hash算法改变，所以连接数据库时可能会出现Client does not support authentication protocol问题

此问题在mysql 5中不存在，mysql 5不需要以下的设置。

可以通过一下两种方法解决数据库用户密码不符问题：

其一: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');

其二: mysql> Update mysql.user SET Password = OLD_PASSWORD('newpwd') Where Host = 'some_host' AND User = 'some_user'

PHP输出的其它乱码问题：

如果将mysql编译为默认编码gbk的话，又会造成非gbk数据直接导入显示为乱码，比如部份utf8存储的字符，如果你大部份数据是utf8字集，当然得把mysql编译为默认编码utf8才合适。

Mysql 4.1.x出来以后，引入了collation (校勘)的概念，终于有办法让mysql同时支持多种编码的数据库了，所以PHP要用以下SQL语句来创建utf-8编码的数据库：

但是仅仅是将数据库的校勘改为utf-8是不够的，还必须在连接了mysql数据库之后用这个语句来设置：set names 'utf8';才能在php程序里得到正确编码的字符，并将其显示在web页面里。

下面再说明一下,网上很多朋友说Mysql4.1的只能升,不能降. 这是不正确的. 同样使用mysqldump 导出数据库时加一个 --compatible 的参数.也千万不能忘了--default-character-set=这个设定字符集的参数。

示范: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql

ok 这样导出来的文件,就可以在Mysql4.0.X和Mysql.3.2.X版本中使用了.

下面要写的是一篇非常无聊的东西，充斥了大量各式各样的编码、转换、客户端、服务器端、连接……呃，我自己都不愿意去看它，但想一想，写下来还是有点意义的，原因有四：

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！
内容来自17jquery

这会导致什么现象呢？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_connection='utf8' 或者

都是可以的，都能够保证数据在编码转换中不出现丢失，也就是保证存储入数据库的是正确的内容。

怎么保证取出的是正确的内容呢？考虑到绝大部分客户端 (包括 WP)，发送数据的编码也就是它所希望收到数据的编码，所以:

可以保证取出给浏览器显示的格式就是 gb2312。

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

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

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

首先，测试服务器是否 >= 4.1，编译时是否加入了 UTF-8 支持；是则继续

然后测试数据库以什么格式存储 ($dbEncoding)；

对于第二点，WP 的情况是不同的，按照上面的典型配置，只要用 WP，肯定数据库是用 UTF-8 存储的，所以要根据用户设置的以 GB2312 还是 UTF-8 浏览来判断 (bloginfo('charset'))，但这个值是要连接数据库以后才能得到的，所以效率最高的方式是连接数据库之后，根据这个配置设置一次 SET NAMES，而不必每次查询之前都设置一遍。

我的修改方式是这样的，在 wp_includes/wp-db.php 中增加:
内容来自17jquery

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

1. MySQL 4.1 在文字上有很大改进，它有了 Character Set 与 Collation 的慨念。

2. 在 MySQL 4.0 ，一般的程式都会将文字以拉丁文 ( latin) 来储存，就算我们输入中文字，结果仍是放在以拉丁文设置的文字栏里头，这对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来说，并不会有问题。

3. 可是 MySQL 4.1 的系统编码是预设用 UTF-8 的，当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时，乱码就出现了。原因在于 MySQL 4.1 将 latin 码转换过来，而后转换是并不完全完美的，这导致了出现少量文字出现乱码现象。
一起jquery,17jquery

4. 要解决这乱码问题并不难。首先，在 MySQL 4.0 备份时，先将所有文字栏变成 binary 类型，然后进行正常备份。第二步，可在 MySQL 4.1 里将刚才的备份 restore。最后，将较早前所变更到 binay 类型的文字栏，再次复原到文字类型。这样中文编码的问题就应该可以完全解决。

5. 将文字栏变更到 binay 类型时，必需设定 binary 栏的长度大过或等于 (>=) 文字栏的长度，否则资料会失去。

6. 另外，经这样升级的 MySQL 数据库，在 MySQL 4.1 里将会正常工作，就算是怎样 backup 与 restore 都不会再有乱码问题。

作者: MySQL 发布日期: 2005-12-14

mysql4.1是比较烦人，支持多语言的细化设置，再加上phpmyadmin2.6也比较笨，默认就是改不动的utf8，怎么弄都乱码。

好了，废话少说，我们来一步步解决这个问题：

1.修改/etc/my.cnf文件，改成这样：

注意：就是加入了一句default-character-set=utf8。
内容来自17jquery

2./etc/init.d/mysqld restart 重新启动mysql；

3.打开phpmyadmin，选择lang为"Chines simplifies(zh-utf-8)",选择"MySQL 连接校对"为"utf8_general_ci "点“显示 MySQL 的运行信息”--“变量”，可以看到：

从这里可以看到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，否则导进去乱码；
内容来自17jquery

二是在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。可能你需要这个：

在登陆到mysql后用，把character的一些默认参数改到utf8上，有时可以减少一些困扰，不过也不是必须的。

在mysql上使用:

用来查看当前的状态。

3.如果出现乱码也不要怕，一是你要注意留存原有的备份，二是用iconv来进行转化。

在正常使用之前注意做导入导出的测试，确保万无一失。

我升级了MYSQL到4.1.2，phpmyadmin用的是2.6.2。数据表里面有中文的字段中文都变成了乱码，导出数据也是乱码。我用以前的2.5.7没有问题，想问一下，应该在phpmyadmin的那个文件里改哪个设置一下才能显示出来的是正常的中文字？

和字符相关的变量中这几个和sql很有关系：

此外就是数据库中对相应字段设置的charact set，如果没有对字段设置，缺省是table的charact set，table也没有指定则缺省使用database的。

上面3个变量的作用是这样的，client表示客户端发送过来的字符集，results表示发送到客户端的字符集（这两个分开是因为发送过来和发送过去的不一定是同一个客户端），connection则在客户端和数据库起一个连接作用。

具体是这样：比如我在mysql命令行设置client为gbk，connection为utf8，results为gbk，数据库为big5，

当我发送一个insert语句的时候，这个语句作为gbk代码，先转为utf8代码（connection），再转为big5（database）插入数据库。

而运行一个select语句的时候，从数据库得到的结果则相反的过程，由big5转为utf8，再转为gbk，你得到gbk的结果。

因此最主要的是让client和results和你使用的客户端一致。比如你的网页是utf8编码，你就要设置这两个为utf8。
一起jquery,17jquery

而在mysql命令行的时候，我用的是2000，需要设置为gbk

而我们用的set names XXX，实际上就是同时设置这3个变量为XXX。

在这样的情况下，我们可以把一个数据库中的不同表或不同字段设为不同的字符集，只要上面3个设置正确，就可以在数据库中同时使用不同的字符集。

注意要保证你的数据库中的字符已经使用了正确的字符集，比如如果一开始你设置错误，插入数据后，本身数据的编码就是不正确的，然后即使设置改回来，也不可能得到正确的显示了。

还有一个是编码互相之间的兼容性，如果一个字符在gbk中有，在utf8中没有，那么在gbk－》utf8－》gbk的过程中，它就变成了“？”

再说一下具体解决的办法。

首先要指定你的升级后的database及table及field的character set，一般来说我们用gb2312或者utf8的，如果不同时使用多种编码，只要指定database就可以，可以在建库的sql语句加上相应的 character set，在phpMyAdmin里也可以修改。

然后是导入旧数据。首先要确定自己的数据文件的编码。如果用phpMyAdmin导入，在界面上有文件编码的选项，一定要和数据文件的编码一致。

如果从mysql的命令行导入，就要自己设置上面说到的3个变量，set names xxx。

使用其它的客户端程序一样要注意。

这样就可以让旧数据转入新数据库后的编码才是正确的，如果这一步错了，后面不可能得到正确的显示。

然后是自己的程序，在连接后就可以执行一次set names xxx，根据你的网页编码而定。

这样基本就可以保证编码正确了。

你很有可能是导入的数据编码已经不对了。

MYSQL数据库默认语言为瑞典语, 现有一GB2312字符的数据库.

结构OK. 为什么内容是乱码? 不重装数据库有办法解决码?

从MySQL 4.1开始引入的多语言支持确实很棒，而且一些特性已经超过了其他的数据库系统。不过我在测试过程中发现使用适用于MySQL 4.1之前的PHP语句操作MySQL数据库会造成乱码，即使是设置过了表字符集也是如此。我读了一下新的MySQL在线手册中第十章 "Character Set Support"后终于找到了解决方法并测试通过。

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

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

上面列出的值就是系统的默认值。(很奇怪系统怎么默认是latin1的瑞典语排序方式)...

当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句：
内容来自17jquery

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

再试试看，正常了吧？^_^ Enjoy!

具体讲

在你的查询前加一行：

真应该把手册仔细看一遍.

和字符相关的变量中这几个和sql很有关系：

此外就是数据库中对相应字段设置的charact set，如果没有对字段设置，缺省是table的charact set，table也没有指定则缺省使用database的。

上面3个变量的作用是这样的，client表示客户端发送过来的字符集，results表示发送到客户端的字符集（这两个分开是因为发送过来和发送过去的不一定是同一个客户端），connection则在客户端和数据库起一个连接作用。

具体是这样：比如我在mysql命令行设置client为gbk，connection为utf8，results为gbk，数据库为big5，

当我发送一个insert语句的时候，这个语句作为gbk代码，先转为utf8代码（connection），再转为big5（database）插入数据库。

而运行一个select语句的时候，从数据库得到的结果则相反的过程，由big5转为utf8，再转为gbk，你得到gbk的结果。
内容来自17jquery

因此最主要的是让client和results和你使用的客户端一致。比如你的网页是utf8编码，你就要设置这两个为utf8。

而在mysql命令行的时候，我用的是2000，需要设置为gbk

而我们用的set names XXX，实际上就是同时设置这3个变量为XXX。

在这样的情况下，我们可以把一个数据库中的不同表或不同字段设为不同的字符集，只要上面3个设置正确，就可以在数据库中同时使用不同的字符集。

注意要保证你的数据库中的字符已经使用了正确的字符集，比如如果一开始你设置错误，插入数据后，本身数据的编码就是不正确的，然后即使设置改回来，也不可能得到正确的显示了。

还有一个是编码互相之间的兼容性，如果一个字符在gbk中有，在utf8中没有，那么在gbk－》utf8－》gbk的过程中，它就变成了“？”

再说一下具体解决的办法。

首先要指定你的升级后的database及table及field的character set，一般来说我们用gb2312或者utf8的，如果不同时使用多种编码，只要指定database就可以，可以在建库的sql语句加上相应的 character set，在phpMyAdmin里也可以修改。

然后是导入旧数据。首先要确定自己的数据文件的编码。如果用phpMyAdmin导入，在界面上有文件编码的选项，一定要和数据文件的编码一致。

如果从mysql的命令行导入，就要自己设置上面说到的3个变量，set names xxx。

使用其它的客户端程序一样要注意。

这样就可以让旧数据转入新数据库后的编码才是正确的，如果这一步错了，后面不可能得到正确的显示。

然后是自己的程序，在连接后就可以执行一次set names xxx，根据你的网页编码而定。

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

mysql 导入乱码问题- -

mysql从4.1使用mysqldump导出数据并在4.0导入的时候会出现sql语句错误，并且所有数据变成乱码。使用下面的参数就可以解决

--转自