MYSQL导入数据乱码的解决办法,mysql中文乱码 解决方法集锦[转]

hyx 2018-08-14 17:02:55 55次 0

首先在新建数据库时一定要注意生成原数据库相同的编码形式,如果已经生成可以用phpmyadmin等工具再整理一次,防止数据库编码和表的编码不统一造成乱码。 

方法一: 通过增加参数 –default-character-set = utf8 解决乱码问题 
mysql -u root -p password < path_to_import_file –default-character-set = utf8 

方法二: 在命令行导入乱码解决 

1. use database_name; 
2. set names utf8; (或其他需要的编码) 
3. source example.sql (sql文件存放路径) 

方法三: 直接粘贴sql文件里的代码 
1. 打开SQLyog客户端软件; 
2. 定位到SQL编辑器,然后用记事本打开刚刚导出的SQL文件; 
3. 复制文件中所有SQL语句到SQL编辑器当中,执行这些SQL代码; 

方法四: 用记事本或其他文本工具改变SQL文件的编码格式(若方法三不行,那就尝试方法四) 

1. 用记事本(或UE)打开刚才的导出的SQL文件; 
2. 另存此文件——打开另存为对话框,选择对话框中的编码格式为UNICODE编码; 
3. 保存文件,然后CTRL+A,全选; 
4. 复制里面的SQL语句到SQLyog中的“SQL编码器”当中,再执行一次SQL语句; 
5. 执行完成后切记刷新一次,查看中文的数据表,乱码消除,大功告成;

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'));

从MySQL支持Unicode后,为了与时俱进,我们的web程序也开始考虑用UTF8了。其实UTF8也用了好几年了,程序基本能跑,没什么大问题,但是数据倒换的时候,总是遇到不爽的事情。

【问题现象】

网页xxx.php用EditPlus另存为UTF8格式,MySQL在my.ini里设置default-character-set=utf8,建表时加了CREATE TABLE `xxx ` (myname varchar(255)) ENGINE=MyISAM DEFAULT CHARSET=utf8,用xxx.php执行insert/update/select出来的都是中文,貌似没问题,但是用phpMyAdmin看select是乱码,用第三方工具软件(如SQLyog)看select也是乱码,mysqldump也是乱码,很不爽。当然,如果你建表的时候,选择了binary/varbinary/blob类型,不会发现乱码,因为指定的是二进制保存,MySQL保存数据时就没有编码的概念了。

【查找问题】

虽然在my.ini里设置default-character-set=utf8,但是执行以下命令时有新发现:

mysql> SHOW VARIABLES LIKE 'character%';

+----------------------------------------+-------------------------

| Variable_name | Value

+----------------------------------------+-------------------------

| character_set_client | latin1

| character_set_connection | latin1

| character_set_database | utf8

| character_set_filesystem | binary

| character_set_results | latin1

| character_set_server | utf8

| character_set_system | utf8

| character_sets_dir | D:\mysql\share\charsets\

+----------------------------------------+-------------------------

8 rows in set (0.00 sec)


mysql> SHOW VARIABLES LIKE 'collation_%';

+---------------------------------------+------------------

| Variable_name | Value

+---------------------------------------+------------------

| collation_connection | latin1_swedish_ci

| collation_database | utf8_general_ci

| collation_server | utf8_general_ci

+--------------------------------------+------------------

3 rows in set (0.00 sec)
 

发现Value列里面不全是utf8,仍然有部分是latin1,比如其中的client和connection。那网页xxx.php的工作过程就是这样的啦:从xxx.php页面上输入汉字,因为xxx.php是UTF8编码的,所以xxx.php以UTF8格式转换输入的汉字,然后以UTF8提交给mysql,但是mysql的client和connection都是latin1的,而表是UTF8的,所以mysql存储时,先将xxx.php提交的汉字,转成latin1的格式,再转成UTF8字符格式存在表中。如果此时我们用第三方软件或者phpMyAdmin去select查看此表,而表中存储的数据是被latin1过的UTF8字符,出来的时候是以UTF8格式取的,当然看起来时乱码了。解决方法就是让所有过程都是UTF8的就可以了。

【解决问题】

1、从my.ini下手

[client]

default-character-set=utf8

[mysql]

default-character-set=utf8

[mysqld]

default-character-set=utf8
 

以上3个section都要加default-character-set=utf8,平时我们可能只加了mysqld一项。

然后重启mysql,执行

mysql> SHOW VARIABLES LIKE 'character%';

mysql> SHOW VARIABLES LIKE 'collation_%';

确保所有的Value项都是utf8即可。

2、建表时加utf8,表字段的Collation可加可不加,不加时默认是utf8_general_ci了。

CREATE TABLE `tablename4` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`varchar1` varchar(255) DEFAULT NULL,

`varbinary1` varbinary(255) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8 
 


3、网页xxx.php保存时选择utf8编码,页头最好加上

header('conten-type:text/html;charset=utf-8');

在执行CRUD操作前先执行一下

mysql_query("set names utf8");

测试代码xxx.php如下:

<?php

header('conten-type:text/html;charset=utf-8');

mysql_connect("localhost", "root", "password") or die("Could not connect: " . mysql_error());

mysql_select_db("test");

mysql_query("set names utf8");

$str = "CHN 软件开发有限公司,JPN ソフトウェア開発株式会社,KOR 소프트웨어 개발 유한 공사,RUS Суд программного обеспечения".time();

$sql = "insert into tablename4 (varchar1, varbinary1 ) values ('".$str."','".$str."')";

echo $sql."<hr>";

mysql_query($sql);


$result = mysql_query("SELECT id, varchar1 ,varbinary1 FROM tablename4");

while ($row = mysql_fetch_array($result, MYSQL_BOTH)) {

printf ("ID: %s , varchar1: %s, varbinary1: %s<br>", $row[0], $row["varchar1"], $row["varbinary1"]);

}


mysql_free_result($result);

?>
 

如此设置之后,无论是在php页面插入任何utf8字符,在php页面里取出来的,在phpMyAdmin里取出来的,在mysql的第三方客户端软件里取出来的,都是一样的汉字了,不会再发现乱码,mysqldump出来的也是汉字。OK,问题解决。

【另】在中文windows系统下,在cmd.exe里运行mysql.exe字符终端,不能使用上面的规则,因为默认情况下,中文windows系统cmd.exe里的代码页是cp936即GBK,不能显示全部UTF8字符,所以在字符终端里看到乱码是正常现象,不要奇怪,这个问题在类Unix系统的shell终端里可以解决的。

mysql query browser中文乱码的解决方法
我用的是appserv服务包,相信很大一部分同学都在使用这个或是在使用wamp包,很简单,在安装mysql目录下,找到my.ini配置文件:


重启MYSQL服务和apache服务就可以了。
实战mysql导出中文乱码及phpmyadmin导入中文乱码的解决方法
直不用这个phpmyadmin,在本机也是用navicat,总感觉phpmyadmin速度较慢。这回不行了,没有独立主机,只好用人家给的phpmyadmin了。

第一步:本地数据导出sql文件。心想这对于navicat小事一桩。直接在数据库上右键“转储sql”(如图1),哗哗,十几秒的时间导出成功。


(图1:navicat下对整个数据库转sql)

用记事本打开一看,傻眼了。中文全是乱码。咋回事呢?搜索了一下,改变什么连接属性啥的。不管用。试着在单张表上,转储sql,嘿,中文正常。但是82个表,我一个个转储我不累死。不行。看来只能弃用我心爱的navicat了。想起有个mysqldump,好试试它。运行-C:\Documents and Settings\Administrator>mysqldump -uroot -p123 ttg>ttgbk2.sql。打开一看,还是乱码。还不行。唉。。搜索,改成下面的加上指定字符集

C:\Documents and Settings\Administrator>mysqldump -uroot -p123 --default-character-set=gbk ttg>ttgbk2.sql。打开看看。嘿可以了。


第二步:打开虚拟主机提供的phpmyadmin.导入选择文件ttgbk2.sql.点执行。那个速度,唉。。。一会儿报错了。在执行lock tables tablename write 时出现access denied错误,原来我是虚拟主机用户没有 lock tables的权限.打开sql一看还真有lock tables 选项。没权限那就不用这个。到网上一搜说加上--skip-lock-tables,心想不错,应该是这个“跳过锁表”嘛

在mysqldump时加上-skip-lock-tables选项,那么命令行就变成
C:\Documents and Settings\Administrator>mysqldump -uroot -p123 --default-character-set=gbk --skip-lock-tables ttg>ttgbk3.sql.
结果令人失望,还是有lock tables.
后来看了一下mysqldump --help
才明白--skip-lock-tables是用在备份时候不让读写。但是如果你不想让导出的带lock-tables(因为你导入的时候没有权限嘛,呵呵)应该是使用add-locks=false,这是2个概念。正确的如下
C:\Documents and Settings\Administrator>mysqldump -uroot -p123 --default-character-set=gbk ttg --add-locks=false>ttgttg3.sql.

我的版本导出的在记事本中打开是asni格式的。

再次到phpmyadmin处导入。结果是导入了3个表后报错。mysql语句报错。一看中文还乱码。。。。。接近崩溃。

再找原因。把“MySQL 连接校对”改成gbk-chinese-ci,把language改成中文-chinese simplified(如图2)。再把导入时“文件编码”改成“gbk”(默认的是utf-8,当然对应的sql文件的编码用记事本打开就是ansi.)(如图三).再试。。。。



(图二:修改连接校对及language)



(图三:修改文件的字符集为gbk)


终于所有表导入成功。打开一个含有中文的表,字段显示正常。

2点体会:

1、数据库编码归数据库编码。保证连接校对与数据库编码一致即可。

2、sql文件编码归文件编码。保证导入时选择的文件编码与数据库所用编码一致最好。

这是2个编码问题。

服了你了mysql.从知道你有这个编码问题到到现在,你还是这个样子。这个问题还是让很多人困惑。啥时候像sqlserver那样国际化就好了。


第一个方法: 
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乱码问题 
QUOTE: 
从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)。 
查看系统的字符集和排序方式的设定可以通过下面的两条命令: 
CODE: 
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) 
上面列出的值就是系统的默认值。如果你奇怪系统怎么默认是latin1的瑞典语排序方式,原因是MySQL由瑞典的T.c.X.DataKonsultAB公司(目前公司名称为MySQL AB)开发,不用再多说了吧。 
当我们按照原来的方式通过PHP存取MySQL数据库时,就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询,你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句: 
SET NAMES 'utf8'; 
它相当于下面的三句指令: 
CODE: 
SET character_set_client = utf8; 
SET character_set_results = utf8; 
SET character_set_connection = utf8; 
再试试看,正常了吧? 
就是连接之后加个查询 
CODE: 
$this->query(”SET NAMES ‘utf8'”); 
看了手册第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处理,所以必然有标题等由数据库读出的字段是乱码而其他部门文字不乱码的现象。 
以上这个例子是utf8字符集,用此方法,设置为gbk,即可解决 
第三个方法: 
mysql 4.1乱码终极解决方案 
请注意,本文只针对mysql 4.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/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来进行转化。 
在正常使用之前注意做导入导出的测试,确保万无一失。 
下面再说明一下,网上很多朋友说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 中文乱码的彻底解决及应用的一些注意事项 
一. 自从mysql4.1开始,mysql对中文的支持问题是比较烦人的,怎么弄都乱码,如今mysql5 据说是mysql的新纪元,但从官方下载安装的mysql5仍存在乱码现象,这里就是针对此现象做的讨论: 
建议最好是下载mysql的源码进行编译,这是由于官方编译的mysql的默认支持编码是latin字符集,所以中文字符在数据库里查看的时候看到的是乱码。编译MySQL时使用withcharset=编码,可以方便地把mysql编译成该编码形式,这样MySQL就会直接支持中文查找和排序,-- with-extra-charsets参数指定其它可用的字符集。 
下载并解压源码包,打开INSTALL-SOURCE,这里介绍了linux下详细的安装方法,所以大家所要注意的只是下面的configure指令: 
groupadd mysql 
useradd -g mysql mysql 
./configure --with-charset=gbk --with-collation=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql 
make 
make install 
cp support-files/my-medium.cnf /etc/my.cnf 
cd /usr/local/mysql 
bin/mysql_install_db --user=mysql 
chown -R root . 
chown -R mysql var 
chgrp -R mysql . 
bin/mysqld_safe --user=mysql & 
bin/mysql 
mysql> show variables; 
你可以看到全局的字符集参数全是gbk,gb2312字集应该包含在gbk里,所以不讨论。 
进行和平常mysql4.0一样的php操作,你会发现仍然出现中文乱码现象。 
这里要说明的是:从mysql 4.1开始,必需在mysql数据库连接后对应用的字符集做出说明,否则非英文字母的文字存取都无法解释变成?号。 
解决方法就是要适应新版mysql的要求: 
在连接mysql数据库后执行set character set 字符集,该指令在最新版的mysql 5如果默认字集和存储相符可以免设: 
set character set gbk; 
在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密码 数据库名 
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编码的数据库: 
Create DATABASE `mytest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 
但是仅仅是将数据库的校勘改为utf-8是不够的,还必须在连接了mysql数据库之后用这个语句来设置:set names 'utf8';才能在php程序里得到正确编码的字符,并将其显示在web页面里。 
mysql_query("set names 'utf8'",$connection); 
下面再说明一下,网上很多朋友说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! 
这会导致什么现象呢?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'));

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 码转换过来,而后转换是并不完全完美的,这导致了出现少量文字出现乱码现象。 
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文件,改成这样: 
[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来进行转化。 
在正常使用之前注意做导入导出的测试,确保万无一失。


我升级了MYSQL到4.1.2,phpmyadmin用的是2.6.2。数据表里面有中文的字段中文都变成了乱码,导出数据也是乱码。我用以前的2.5.7没有问题,想问一下,应该在phpmyadmin的那个文件里改哪个设置一下才能显示出来的是正常的中文字? 
和字符相关的变量中这几个和sql很有关系: 
character_set_client 
character_set_connection 
character_set_results 
此外就是数据库中对相应字段设置的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。 
而在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)。 
查看系统的字符集和排序方式的设定可以通过下面的两条命令:

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)

上面列出的值就是系统的默认值。(很奇怪系统怎么默认是latin1的瑞典语排序方式)... 
当我们按照原来的方式通过PHP存取MySQL数据库时,就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询,你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句: 
SET NAMES 'utf8'; 
它相当于下面的三句指令: 
SET character_set_client = utf8; 
SET character_set_results = utf8; 
SET character_set_connection = utf8; 
再试试看,正常了吧?^_^ Enjoy! 
具体讲 
在你的查询前加一行: 
mysql_query("SET NAMES 'gb2312';",$this->con); 
真应该把手册仔细看一遍. 
和字符相关的变量中这几个和sql很有关系: 
character_set_client 
character_set_connection 
character_set_results 
此外就是数据库中对相应字段设置的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。 
而在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语句错误,并且所有数据变成乱码。使用下面的参数就可以解决 
mysqldump -uxunai -p --compatible=mysql40 --default-character-set=latin1 xunai>xunai.sql 
mysql -uroot -p fmx < fmx3.sql -f --default-character-set=latin1

发表评论

注:*为必填

回复 的评论
*
选择
*
*