之前由于使用的是默认字符集latin1，后来升级数据库后，并且安装了discuz论坛，其使用gbk字符集，因此导致从论坛去主页的时候，偶尔会出现主页乱码的情况，经过网上资料的查找，需要将latin1转换成为gbk字符集。于是就通过mysqldump -uroot -p --default-character-set=latin1 -set-charset=gbk --skip- opt databse > test.sql 这个命令将之前的字符集导入出来，并设置成为gbk 但是期间报错，Warning: mysqldump: ignoring option '--set-charset' due to invalid value 'gbk'然后重新建立test数据库，并设置其字符集为gbk CREATE DATABASE `test` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;随后，将之前导出的sql文件，往回导。mysql -uroot -p --default-character-set=gbk -f test < test.sql 这个时候报错
ERROR at line 29047: Unknown command '\''.
ERROR 2005 (HY000) at line 29047: Unknown MySQL server host 'Buzzard','Buteo' (1)
ERROR at line 29367: Can't connect to the server请问大家，错误在哪里？如何解决？
ERROR at line 29047: Unknown command '\''.
ERROR 2005 (HY000) at line 29047: Unknown MySQL server host 'Buzzard','Buteo' (1)
ERROR at line 29367: Can't connect to the server请问大家，错误在哪里？如何解决？
是在同一版本不同字符集间升级吗？
SHOW VARIABLES LIKE 'character_set_%';
看看你的MYSQL版本是否支持GBK，从提示上看，不支持
记录中的是否有乱码？
-----------------------------
你要到的库的字符集是什么？还有那些表的字符集和字段的字符集是否都采集继承了库的字符集？
还有你是在dos的cmd下进行上面语句处理的吗？
记录中的是否有乱码？恩，有乱码..........
还有你是在dos的cmd下进行上面语句处理的吗？ 原本的库是默认使用latin1字符集，但是用了discuz，其相关的数据库使用的是gbk字符集。现在我是希望能把字符集统一称为gbk。
那些语句我是用ssh登陆服务器执行的
恩恩，有的有的。我打开的是直接使用dump出来的文件，也确实让我选择编码，但是里面的编码没有一个能让那些乱码变成文字的
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ | 但是，我即便是用--set-charset=utf8 也是报ignoring option '--set-charset' due to invalid value 'utf8'
+----------+-----------------------------+---------------------+--------+
| Charset | Description | Default collation | Maxlen |
+----------+-----------------------------+---------------------+--------+
| big5 | Big5 Traditional Chinese | big5_chinese_ci | 2 |
| dec8 | DEC West European | dec8_swedish_ci | 1 |
| cp850 | DOS West European | cp850_general_ci | 1 |
| hp8 | HP West European | hp8_english_ci | 1 |
| koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1 |
| latin1 | cp1252 West European | latin1_swedish_ci | 1 |
| latin2 | ISO 8859-2 Central European | latin2_general_ci | 1 |
| swe7 | 7bit Swedish | swe7_swedish_ci | 1 |
| ascii | US ASCII | ascii_general_ci | 1 |
| ujis | EUC-JP Japanese | ujis_japanese_ci | 3 |
| sjis | Shift-JIS Japanese | sjis_japanese_ci | 2 |
| hebrew | ISO 8859-8 Hebrew | hebrew_general_ci | 1 |
| tis620 | TIS620 Thai | tis620_thai_ci | 1 |
| euckr | EUC-KR Korean | euckr_korean_ci | 2 |
| koi8u | KOI8-U Ukrainian | koi8u_general_ci | 1 |
| gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2 |
| greek | ISO 8859-7 Greek | greek_general_ci | 1 |
| cp1250 | Windows Central European | cp1250_general_ci | 1 |
| gbk | GBK Simplified Chinese | gbk_chinese_ci | 2 |
| latin5 | ISO 8859-9 Turkish | latin5_turkish_ci | 1 |
| armscii8 | ARMSCII-8 Armenian | armscii8_general_ci | 1 |
| utf8 | UTF-8 Unicode | utf8_general_ci | 3 |
| ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 |
| cp866 | DOS Russian | cp866_general_ci | 1 |
| keybcs2 | DOS Kamenicky Czech-Slovak | keybcs2_general_ci | 1 |
| macce | Mac Central European | macce_general_ci | 1 |
| macroman | Mac West European | macroman_general_ci | 1 |
| cp852 | DOS Central European | cp852_general_ci | 1 |
| latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1 |
| cp1251 | Windows Cyrillic | cp1251_general_ci | 1 |
| cp1256 | Windows Arabic | cp1256_general_ci | 1 |
| cp1257 | Windows Baltic | cp1257_general_ci | 1 |
| binary | Binary pseudo charset | binary | 1 |
| geostd8 | GEOSTD8 Georgian | geostd8_general_ci | 1 |
| cp932 | SJIS for Windows Japanese | cp932_japanese_ci | 2 |
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3 |
+----------+-----------------------------+---------------------+--------+
36 rows in set (0.00 sec)从上面看，我的数据库是支持gbk的啊
第一步dump出来后，我打开文件看到 ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;结构这样的结尾。并且内容都是乱码。所以我没有做最后一步的测试。
你的原表设计是用的latin1你直接做
mysqldump -uroot -p databse > test.sql;结果如何？
如果不在dump里面加上 --default-set-character=latin1 的话，出来的东西就是乱码。
我用了这个方法，并且在建立数据库的时候设置了字符集为gbk。导入到数据库后，在数据库直接查找内容的时候是乱码，但是将数据库导入的时候，查看导出文件又是正常。然后我用页面做测试，通过语句选择字段，在页面上出来的又是乱码。这到底是怎么回事啊？
这个是因为程序端字符集设置的问题。http://blog.csdn.net/ACMAIN_CHM/archive/2009/05/12/4174186.aspx
MySQL 中文显示乱码
恩，我看到了。如果在前面增加set names 的确能解决那个问题。可是。数据库里面直接的选择还是 ???如下，这个有办法解决么？select * from birdindex limit 20;
+-----------+----------+---------+---------------------------+-----------------------------+
| cspcode | birdname | booknum | liting | english |
+-----------+----------+---------+---------------------------+-----------------------------+
| 020490026 | ?? | 1 | Lerwa lerwa | Snow Partridge |
| 020490046 | ??? | 2 | Tetraogallus tibetanus | Tibetan Snowcock |
| 020490044 | ????? | 3 | Tetraogallus altaicus | Altai Snowcock |
| 020490045 | ???? | 4 | Tetraogallus himalayensis | Himalayan Snowcock |
数据库里面直接的选择还是 ?
这个说法是不准确的！ 只是你从mysql.exe 这个命令行工具中显示为乱码。
同样，进行mysql.exe 后，你也需要设置mysql> set name 'gbk';另外你还需要到你的这个DOS窗体的左上角的属性中设置，字体，宋体。
你说的没错。的确不准确。使用命令，就可以啦。现在目前看，是没啥问题了。不过真是太麻烦了。数据库中有的表格里面数据如果直接dump出来看似没有问题，但是导入的时候又报错。只好用--skip-opt 的方式。但是这样的方式又缺少ENGINE=MyISAM AUTO_INCREMENT=21526 DEFAULT CHARSET=gbk; 这些信息哎，不过好在现在看似没有问题了。过两天再看看情况吧多谢大家的帮助！