因为要把本机的gbk编码的mysql数据库导入到虚拟主机去，服务商只提供了phpmyadmin供你导入导出。一直不用这个phpmyadmin,在本机也是用navicat,总感觉phpmyadmin速度较慢。这回不行了，没有独立主机，只好用人家给的phpmyadmin了。 第一步：本地数据导出sql文件。心想这对于navicat小事一桩。直接在数据库上右键“转储sql”(如图1),哗哗,十几秒的时间导出成功。 实战mysql导出中文乱码及phpmyadmin导入中文乱码 （图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.)(如图三).再试。。。。 实战mysql导出中文乱码及phpmyadmin导入中文乱码 （图二：修改连接校对及language） 实战mysql导出中文乱码及phpmyadmin导入中文乱码 (图三：修改文件的字符集为gbk) 终于所有表导入成功。打开一个含有中文的表，字段显示正常。 2点体会： 1、数据库编码归数据库编码。保证连接校对与数据库编码一致即可。 2、sql文件编码归文件编码。保证导入时选择的文件编码与数据库所用编码一致最好。 这是2个编码问题。 服了你了mysql.从知道你有这个编码问题到到现在，你还是这个样子。这个问题还是让很多人困惑。啥时候像sqlserver那样国际化就好了。