mysql 的乱码解决方法

SETNAMES'gb2312';---ok

mysql的乱码解决方法

第一个方法：

MySQL4.1中文乱码的问题

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

1.MySQL4.1在文字上有很大改进，它有了CharacterSet与Collation的慨念。

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

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



解决PHP存取MySQL4.1乱码问题

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

MySQL4.1的字符集支持(CharacterSetSupport)有两个方面：字符集(Characterset)和排序方式(Collation)。对于字符集的支持细化到四个层次:服务器(server)，数据库(database)，数据表(table)和连接(connection)。

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

CODE:

mysql>SHOWVARIABLESLIKE'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/|
+--------------------------+----------------------------+
7rowsinset(0.00sec)

mysql>SHOWVARIABLESLIKE'collation_%';
+----------------------+-------------------+
|Variable_name|Value|
+----------------------+-------------------+
|collation_connection|latin1_swedish_ci|
|collation_database|latin1_swedish_ci|
|collation_server|latin1_swedish_ci|
+----------------------+-------------------+
3rowsinset(0.00sec)

上面列出的值就是系统的默认值。如果你奇怪系统怎么默认是latin1的瑞典语排序方式,原因是MySQL由瑞典的T.c.X.DataKonsultAB公司(目前公司名称为MySQLAB)开发，不用再多说了吧。
当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句：

SETNAMES'utf8';

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

CODE:

SETcharacter_set_client=utf8;
SETcharacter_set_results=utf8;
SETcharacter_set_connection=utf8;
再试试看，正常了吧？

就是连接之后加个查询

CODE:

$this->query(”SETNAMES‘utf8＇”);
看了手册第10章觉得主要还是CharacterSets的问题。
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处理，所以必然有标题等由数据库读出的字段是乱码而其他部门文字不乱码的现象。
以上这个例子是utf8字符集，用此方法，设置为gbk，即可解决

第三个方法：

mysql4.1乱码终极解决方案

请注意，本文只针对mysql4.1，其它版本的mysql请看别的文章。
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/mysqldrestart重新启动mysql；
3.打开phpmyadmin，选择lang为"Chinessimplifies(zh-utf-8)",选择"MySQL连接校对"为"utf8_general_ci"点“显示MySQL的运行信息”--“变量”，可以看到：
charactersetclientutf8utf8
charactersetconnectionutf8utf8
charactersetdatabaseutf8utf8
charactersetresultsutf8utf8
charactersetserverutf8utf8
charactersetsystemutf8utf8
collationconnectionutf8_general_ciutf8_general_ci
collationdatabaseutf8_general_ciutf8_general_ci
collationserverutf8_general_ciutf8_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下导入，这时候你需要先在库文件的头部加一行:
SETNAMES'gb2312';注意最后也是;号，别漏了。
然后执行mysql-u用户名-p密码xxx.sql>库名
导入完成以后再用phpmyadmin打开看，里面的中文字就是正确的。
4.从mysql4.1里导出库文件
一.用phpmyadmin导出
导出倒是问题不大，如果phpmyadmin的浏览页面里显示的中文是正常的，那么导出肯定也是正常的
二.在linux上导出
如果用mysqldump导出出现了乱码也没有关系，可以运行iconv来转换一下
iconv-c-fUTF-8-tGB2312库文件名>新的gb2312的库文件名

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

下面再说明一下,网上很多朋友说Mysql4.1的只能升,不能降.这是不正确的.同样使用mysqldump导出数据库时加一个--compatible的参数.也千万不能忘了--default-character-set=这个设定字符集的参数.
示范:mysqldump-uroot-pPassword--compatible=mysql40--default-character-set=gb2312discuz>d:discuz.sql
ok这样导出来的文件,就可以在Mysql4.0.X和Mysql.3.2.X版本中使用了.

Linux下Mysql5中文乱码的彻底解决及应用的一些注意事项

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

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

下载并解压源码包，打开INSTALL-SOURCE，这里介绍了linux下详细的安装方法，所以大家所要注意的只是下面的configure指令：
groupaddmysql
useradd-gmysqlmysql
./configure--with-charset=gbk--with-collation=gbk_chinese_ci--with-extra-charsets=gb2312,big5,utf8,binary,ascii--prefix=/usr/local/mysql
make
makeinstall
cpsupport-files/my-medium.cnf/etc/my.cnf
cd/usr/local/mysql
bin/mysql_install_db--user=mysql
chown-Rroot.
chown-Rmysqlvar
chgrp-Rmysql.
bin/mysqld_safe--user=mysql&
bin/mysql
mysql>showvariables;

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

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

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

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

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

setcharactersetgbk;

在php里应该是这么写:mysql_query("setcharactersetgbk");

指令大小写均可

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

找到include/db_mysql.php，修改functionconnect(){..}
在选择数据库mysql_select_db($dbname);后面加上一句mysql_query('setcharactersetgbk');存盘。

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

文件导入和导出执行

mysql-u用户名-p密码数据库名

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

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

iconv-c-futf8-tgbk库文件名>新的gbk的库文件名

综上所述，你要注意：

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

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

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

#PHP连接问题：

由于MySQL4.1版本开始密码的hash算法改变，所以连接数据库时可能会出现Clientdoesnotsupportauthenticationprotocol问题

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

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

其一:mysql>SETPASSWORDFOR'some_user'@'some_host'=OLD_PASSWORD('newpwd');

其二:mysql>Updatemysql.userSETPassword=OLD_PASSWORD('newpwd')WhereHost='some_host'ANDUser='some_user'

PHP输出的其它乱码问题：

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

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

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

mysql_query("setnames'utf8'",$connection);

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

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

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

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

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

MySQL4.1字符集支持的原理MySQL4.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无从得知(它最多只能猜测)，所以MySQL4.1要求客户端必须指定这个字符集，也就是character_set_client，MySQL的怪异之处在于，得到的这个字符集并不立即转换为存储在数据库中的那个字符集，而是先转换为character_set_connection变量指定的一个字符集；这个connection层究竟有什么用我不大明白，但转换为character_set_connection的这个字符集之后，还要转换为数据库默认的字符集，也就是说要经过两次转换；当这个数据被输出时，又要由数据库默认的字符集转换为character_set_results指定的字符集。

一个典型的环境典型的环境以我自己的电脑上安装的MySQL4.1为例，我自己的电脑上安装着Apache2，PHP5和WordPress1.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如果使用MySQL4.1数据库，把编码改用GB2312就正常了，可惜，这种正常只是貌似正常。

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

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

因为配置文件设置的default_character_set是utf8，数据表默认采用的就是utf-8建立的。这也应该是所有采用MySQL4.1的主机提供商应该采用的配置。所以我们要保证的只是客户端与MySQL交互之间指定编码的正确。

这只有两种可能，客户端以gb2312格式发送数据，或者以utf-8格式发送数据。

如果以gb2312格式发送:

SETcharacter_set_client='gb2312'
SETcharacter_set_connection='utf8'或者
SETcharacter_set_connection='gb2312'

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

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

SETcharacter_set_results='gb2312'

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

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

SETcharacter_set_client='utf8'
SETcharacter_set_connection='utf8'
SETcharacter_set_results='utf8'

这个配置就等价于SETNAMES'utf8'。

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

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

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

functionset_charset($charset)
{
//checkmysqlversionfirst.
$serverVersion=mysql_get_server_info($this->dbh);
$version=explode('.',$serverVersion);
if($version[0]<4)return;

//checkifutf8supportwascompiledin
$result=mysql_query("SHOWCHARACTERSETlike'utf8'",
$this->dbh);
if(mysql_num_rows($result)<=0)return;

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

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

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

1.MySQL4.1在文字上有很大改进，它有了CharacterSet与Collation的慨念。

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

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

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

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

6.另外，经这样升级的MySQL数据库，在MySQL4.1里将会正常工作，就算是怎样backup与restore都不会再有乱码问题。
作者:MySQL发布日期:2005-12-14
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/mysqldrestart重新启动mysql；
3.打开phpmyadmin，选择lang为"Chinessimplifies(zh-utf-8)",选择"MySQL连接校对"为"utf8_general_ci"点“显示MySQL的运行信息”--“变量”，可以看到：
charactersetclientutf8utf8
charactersetconnectionutf8utf8
charactersetdatabaseutf8utf8
charactersetresultsutf8utf8
charactersetserverutf8utf8
charactersetsystemutf8utf8
collationconnectionutf8_general_ciutf8_general_ci
collationdatabaseutf8_general_ciutf8_general_ci
collationserverutf8_general_ciutf8_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下导入，这时候你需要先在库文件的头部加一行:
SETNAMES'gb2312';注意最后也是;号，别漏了。
然后执行mysql-u用户名-p密码xxx.sql>库名
导入完成以后再用phpmyadmin打开看，里面的中文字就是正确的。
4.从mysql4.1里导出库文件
一.用phpmyadmin导出
导出倒是问题不大，如果phpmyadmin的浏览页面里显示的中文是正常的，那么导出肯定也是正常的
二.在linux上导出
如果用mysqldump导出出现了乱码也没有关系，可以运行iconv来转换一下
iconv-c-fUTF-8-tGB2312库文件名>新的gb2312的库文件名

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

最后加一句：www.quicklinux.org原创文章，转载请注明出处。呵呵
邮件：[email protected]
作者:MySQL发布日期:2005-12-14
我升级了MYSQL到4.1.2，phpmyadmin用的是2.6.2。数据表里面有中文的字段中文都变成了乱码，导出数据也是乱码。我用以前的2.5.7没有问题，想问一下，应该在phpmyadmin的那个文件里改哪个设置一下才能显示出来的是正常的中文字？

和字符相关的变量中这几个和sql很有关系：
character_set_client
character_set_connection
character_set_results
此外就是数据库中对相应字段设置的charactset，如果没有对字段设置，缺省是table的charactset，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。
而在mysql命令行的时候，我用的是2000，需要设置为gbk
而我们用的setnamesXXX，实际上就是同时设置这3个变量为XXX。
在这样的情况下，我们可以把一个数据库中的不同表或不同字段设为不同的字符集，只要上面3个设置正确，就可以在数据库中同时使用不同的字符集。
注意要保证你的数据库中的字符已经使用了正确的字符集，比如如果一开始你设置错误，插入数据后，本身数据的编码就是不正确的，然后即使设置改回来，也不可能得到正确的显示了。
还有一个是编码互相之间的兼容性，如果一个字符在gbk中有，在utf8中没有，那么在gbk－》utf8－》gbk的过程中，它就变成了“？”
再说一下具体解决的办法。
首先要指定你的升级后的database及table及field的characterset，一般来说我们用gb2312或者utf8的，如果不同时使用多种编码，只要指定database就可以，可以在建库的sql语句加上相应的characterset，在phpMyAdmin里也可以修改。
然后是导入旧数据。首先要确定自己的数据文件的编码。如果用phpMyAdmin导入，在界面上有文件编码的选项，一定要和数据文件的编码一致。
如果从mysql的命令行导入，就要自己设置上面说到的3个变量，setnamesxxx。
使用其它的客户端程序一样要注意。
这样就可以让旧数据转入新数据库后的编码才是正确的，如果这一步错了，后面不可能得到正确的显示。
然后是自己的程序，在连接后就可以执行一次setnamesxxx，根据你的网页编码而定。
这样基本就可以保证编码正确了。
你很有可能是导入的数据编码已经不对了。


MYSQL数据库默认语言为瑞典语,现有一GB2312字符的数据库.
结构OK.为什么内容是乱码?不重装数据库有办法解决码?

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

MySQL4.1的字符集支持(CharacterSetSupport)有两个方面：字符集(Characterset)和排序方式(Collation)。对于字符集的支持细化到四个层次:服务器(server)，数据库(database)，数据表(table)和连接(connection)。

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


mysql>SHOWVARIABLESLIKE'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/|
+--------------------------+----------------------------+
7rowsinset(0.00sec)

mysql>SHOWVARIABLESLIKE'collation_%';
+----------------------+-------------------+
|Variable_name|Value|
+----------------------+-------------------+
|collation_connection|latin1_swedish_ci|
|collation_database|latin1_swedish_ci|
|collation_server|latin1_swedish_ci|
+----------------------+-------------------+
3rowsinset(0.00sec)


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

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

SETNAMES'utf8';

它相当于下面的三句指令：
SETcharacter_set_client=utf8;
SETcharacter_set_results=utf8;
SETcharacter_set_connection=utf8;

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

具体讲
在你的查询前加一行：
mysql_query("SETNAMES'gb2312';",$this->con);

真应该把手册仔细看一遍.
和字符相关的变量中这几个和sql很有关系：
character_set_client
character_set_connection
character_set_results
此外就是数据库中对相应字段设置的charactset，如果没有对字段设置，缺省是table的charactset，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。
而在mysql命令行的时候，我用的是2000，需要设置为gbk
而我们用的setnamesXXX，实际上就是同时设置这3个变量为XXX。
在这样的情况下，我们可以把一个数据库中的不同表或不同字段设为不同的字符集，只要上面3个设置正确，就可以在数据库中同时使用不同的字符集。
注意要保证你的数据库中的字符已经使用了正确的字符集，比如如果一开始你设置错误，插入数据后，本身数据的编码就是不正确的，然后即使设置改回来，也不可能得到正确的显示了。
还有一个是编码互相之间的兼容性，如果一个字符在gbk中有，在utf8中没有，那么在gbk－》utf8－》gbk的过程中，它就变成了“？”
再说一下具体解决的办法。
首先要指定你的升级后的database及table及field的characterset，一般来说我们用gb2312或者utf8的，如果不同时使用多种编码，只要指定database就可以，可以在建库的sql语句加上相应的characterset，在phpMyAdmin里也可以修改。
然后是导入旧数据。首先要确定自己的数据文件的编码。如果用phpMyAdmin导入，在界面上有文件编码的选项，一定要和数据文件的编码一致。
如果从mysql的命令行导入，就要自己设置上面说到的3个变量，setnamesxxx。
使用其它的客户端程序一样要注意。
这样就可以让旧数据转入新数据库后的编码才是正确的，如果这一步错了，后面不可能得到正确的显示。
然后是自己的程序，在连接后就可以执行一次setnamesxxx，根据你的网页编码而定。

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

mysql导入乱码问题--

mysql从4.1使用mysqldump导出数据并在4.0导入的时候会出现sql语句错误，并且所有数据变成乱码。使用下面的参数就可以解决
mysqldump-uxunai-p--compatible=mysql40--default-character-set=latin1xunai>xunai.sql
mysql-uroot-pfmx<fmx3.sql-f--default-character-set=latin1