你可以看到全局的字符集参数全是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密码 数据库名
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不需要以下的设置。
可以通过一下两种方法解决数据库用户密码不符问题：
其一:
其二:
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=这个设定字符集的参数。
示范:
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 存储。