灰狼的雕虫小技

灰狼和小红帽的现代版

Home Contact Syndicate this Site (RSS 2.0) Syndicate this Site (Atom) Login
  139 Posts :: 0 Stories :: 63 Comments :: 0 Trackbacks

文章 分类

存档

日记 分类

C/C++

Databases

Java

JavaScripts

Linux

友情连接


   在执行sql query的时候,碰到了如下问题:

 Illegal mix of collations (gb2312_chinese_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '=',

  下面列出解决 过程,首先想到可能是数据库的编码问题,在my.cnf 中加入 :default-character-coding=gb2312,没起作用。继续在网上找解决方案。

   二.发现了一篇不错的文章,现转过来(我转的很不专业,请见谅)

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

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

简单的说,MySQL 自身的变化和使用 MySQL 的 PHP 程序对此忽略,导致了问题的出现和复杂化,而由于大部分用户使用的是英文,使这种问题不被重视。这里提到的 PHP 程序,主要就 WordPress 而言。

MySQL 4.1 字符集支持的原理

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

  1. 编译 MySQL 时,指定了一个默认的字符集,这个字符集是 latin1;
  2. 安装 MySQL 时,可以在配置文件 (my.ini) 中指定一个默认的的字符集,如果没指定,这个值继承自编译时指定的;
  3. 启动 mysqld 时,可以在命令行参数中指定一个默认的的字符集,如果没指定,这个值继承自配置文件中的;
  4. 此时 character_set_server 被设定为这个默认的字符集;
  5. 当创建一个新的数据库时,除非明确指定,这个数据库的字符集被缺省设定为 character_set_server
  6. 当选定了一个数据库时,character_set_database 被设定为这个数据库默认的字符集;
  7. 在这个数据库里创建一张表时,表默认的字符集被设定为 character_set_database,也就是这个数据库默认的字符集;
  8. 当在表内设置一栏时,除非明确指定,否则此栏缺省的字符集就是表默认的字符集;
  9. 这个字符集就是数据库中实际存储数据采用的字符集,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_setutf8。于是问题出现了:

  1. WordPress 按照默认情况安装,所以所有的表都用 UTF-8 存储数据;
  2. WordPress 默认采用的浏览字符集是 UTF-8 (Options->Reading 中设置),因此所有 WP 页面的 meta 中会说明 charset 是 utf-8;
  3. 所以浏览器会以 utf-8 方式显示所有的 WP 页面;这样一来 Write 的所有 Post,和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache,再由 Apache 交给 PHP;
  4. 所以 WP 从所有的表单中得到的数据都是 utf-8 编码的;WP 不加转换的直接把这些数据发送给 MySQL;
  5. MySQL 默认设置的 character_set_clientcharacter_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 同仁给出了一些建议

  1. 首先,测试服务器是否 >= 4.1,编译时是否加入了 UTF-8 支持;是则继续
  2. 然后测试数据库以什么格式存储 ($dbEncoding);
  3. 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.phprequire (ABSPATH . WPINC . '/vars.php'); 后增加:

				$wpdb->set_charset(get_bloginfo('charset'));
		
				
						http://blog.jjgod.org/2005/07/31/a-mysql-41-story/#more-51
				
		
				   三.

根据下列关键部分,成功解决了数据库中中文的显示问题,但是上述问题仍未解决。

这只有两种可能,客户端以 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'

四.通过show VARIABLES;可以显示出Mysql所有的变量的值的情况,显示:

 show VARIABLES like 'collation%';
+----------------------+-------------------+
| Variable_name        | Value             |
+----------------------+-------------------+
| collation_connection | gb2312_chinese_ci |
| collation_database   | gb2312_chinese_ci |
| collation_server     | gb2312_chinese_ci |
+----------------------+-------------------+

show VARIABLES like 'character%';
+--------------------------+---------------------------------------------------------------------------+
| Variable_name            | Value                                                                     |
+--------------------------+---------------------------------------------------------------------------+
| character_set_client     | gb2312                                                                    |
| character_set_connection | gb2312                                                                    |
| character_set_database   | gb2312                                                                    |
| character_set_filesystem | binary                                                                    |
| character_set_results    | gb2312                                                                    |
| character_set_server     | gb2312                                                                    |
| character_set_system     | utf8                                                                      |
| character_sets_dir       | /usr/local/mysql-standard-5.0.22-linux-i686-glibc23/share/mysql/charsets/ |
+--------------------------+---------------------------------------------------------------------------+

但还是不行,郁闷了。发现的另外一个问题就是:数据库重起后,就恢复到默认值了,需要在数据库的配置文件

support-files/my-huge.cnf(/etc/my.cnf)下增加:default-character-set = utf8

到client和mysqld

[client]

……
default-character-set = utf8
[mysqld]

……
default-character-set = utf8

 

 

另:在创建表的时候,加上:CREATE TABLE IF NOT EXISTS table_name (key, key, key)
    VALUES (value, value, value)
    DEFAULT CHARACTER='gb2312' 这样就可以了。

 

如何使 character-set-database='gb2312'成为默认值呢(尚未解决)?

 

五.参考资料

1.上述二中的资料

2.http://www.cublog.cn/u/29011/showart.php?id=254188

设置 MySQL 的 my.cnf 文件,在 [client]/[mysqld]部分都设置默认的字符集:

[client]
default-character-set = utf8
[mysqld]
default-character-set = utf8

该设置需要重新启动 MySQL 服务器。启动之后在 mysql 命令行下可以用 'status' 命令查看:

mysql> status
--------------
mysql  Ver 14.12 Distrib 5.0.26, for -netbsdelf (i386) using  EditLine wrapper

Connection id:          16
Current database:      
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.0.26-log
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8
UNIX socket:            /tmp/mysql.sock
Uptime:                 1 hour 7 min 49 sec

* 在创建表的时候,加上 default character='utf8' 这样的语句:

CREATE TABLE IF NOT EXISTS table_name (key, key, key)
    VALUES (value, value, value)
    DEFAULT CHARACTER='utf8'

* 在执行 MYSQL 语句时先执行 'SET NAMES 'utf8'' 语句:

SET NAMES 'utf8'

这样基本就能搞定中文问题了。

 

 

 

posted on Tuesday, April 03, 2007 7:11 PM #数据库相关操作

Feedback

No comments posted yet.

Post Feedback

Title:
Name:
Url:
Comments: 
Protected by Clearscreen.SharpHIPEnter the code you see: