【注意】mysql_4.1/5乱码问题专用贴

数据导入导出的时候，也要加上编码
否则就会出现Data too long for column 'xx' at row
导出：mysqldump -uroot -p bokele > c:/mysql.sql --default-character-set=gbk
导入：mysql -uroot -p bokele < c:/mysql.sql --default-character-set=gbk

不论数据库里采用那种编码，只要存入和取出的时候设置的编码相同就不会出现乱码。mysql增加了转码，就是你存入utf-8编码,取出的时候只要告诉mysql你要得到那种编码它就返回正确的结果正解！！！

前提是你得能存入。
4.0及以前版本你存入gb2312要当utf-8取出是不可能的，增加了这些功能性能上应该有些许下降不过mysql5的存储过程，子查询，视图等都值得研究，别因为出现点乱码就抛弃新功能

呵，我用4.0.X导出sql文本。再导入5.0.16老是说我那个字段太长了
还有如果你的插入的字段比表结构字段长的话也无法插入
chinaworker(网络混混 ken.bokele.com)

关于导入导出我还没看
今天用到Mysql5发现乱码，就随便写了一下解决办法
其实知道原理才素最重要的

SET CHARACTER_SET xxx;在 select update insert 的时候用就可以了前提是你的mysql中表的字段要是XXX的

to: uuq(杜牧) 1.你把数据用 gbk 导进去就肯定可以，因为4.0虽然默认也是latin但是导出的却是gbk你想再导入进去，把5.0的表设置改成 gbk就可以，不会出现字段太长了
mysql -uroot -p bokele < c:/mysql.sql --default-character-set=gbk
2.直接复制目录了。你都知道，哈

存入取出的时候编码不同也不要紧，只要相应的character设置成对应的即可。set names xxx 就是把 character set results ，character set client，character set connection 3个同时设置为xxx输入数据为xxx，输出数据为yyy
只要设置results为yyy，client为xxx即可。具体地转换方向是： client=>connection=>database(或server或table或column）＝》connection＝》results所以实际上可以可以在mysql的table里对不同column使用不同的字符集，对于多语言的软件非常有用。同时，转换页面语言也非常方便。使用utf8主要是它（unicode）将来必然会代替gbk、big5等编码的这部分内容看手册的第十章即可。

汗，，，，，，，，，，，， ashchen(晨晖)
为什么都叫晨晖了......看这个名字漂亮啊。：（几年前偶就注册了 chenhui.net 叫晨晖网络：（

我按照楼上几位的方法好象还是不行，请帮忙。
我从服务器上导出数据库，服务器上版本是4.0.16-nt
mysqldump -u root -p > c:\mydb.sql --default-character-set=gb2312在我自己的机器上导入数据库，本地版本是5.0.15-nt
mysql -u root -p mydb < c:\mydb.sql --default-character-set=gb2312但是还是会报错：ERROR 1406（22001）at line 317:Data too long for column……请问该如何解决？？？谢谢

不好意思，在服务器上导出数据库时，少了个参数，应该是：
mysqldump -u root -p mydb > c:\mydb.sql --default-character-set=gb2312

4.1以下导出数据无需加 --default-character-set=gb2312也就是服务器导出的时候是
mysqldump -u root -p mydb > c:\mydb.sql最好本地不要用gb2312，建议用gbk了
gb2312 对很多简单的字符都不支持：（

我用4.1.X,编码是latin1,存入中文,在网页上显示就是正常,但是在mysql-front就是乱码,但是EMS manager就能正常显示,俺搞不明白了!

根据大家说得我修改了MySQL的设置现为GBK 如果后面导入数据时GB2312的数据库显示还是乱码难道DBK不包含GB2312

我使用disuz 在页面上读写数据都上正确的，但是察看数据库的时候显示的是乱码~`~请问这是什么问题~ 我的数据库版本是4.1.14 nt 的我装的是discuz 4.0 支持GBK的开始没有做修改的时候，就是页面上读写是正确，但是数据库中显示是乱码，然后我把数据库的default charset 设定成gbk 然后重新安装discuz 发现还是同样的错误。请高手们给个解释谢谢

可以先看看你Apach里默认输出网页编码是不是改了.adddefaultcharset

我现在的数据库中是错误的，页面读出来是正确的，然后用discuz自带的数据库备份出来的 .sql也是正确的，导入数据库后还是错误的，页面显示还是正确的，说这么多主要的意思就是数据库就乱了，页面就正确了，有没有达人帮忙解决下啊

呵呵晕楼上的。之所以这样无非就是你查看数据库的时候用的语言不对咯。有时间得研究下dz人家怎么读写数据库的编码的。我现在可郁闷了，很多用户第一次安装的时候都说数据库显示错误。换了latin1也是。gb2312也不行。都不知道什么好了。

关于编码的基础概念，推荐：
http://www.regexlab.com/zh/encoding.htm

MySQL5.0中的字符集控制做得比较细，可以分为数据库级，表级，字段级（这一点和ORACLE不同）。改了表的对字段没有影响，所以出现了改了字符集却一样无法插入中文的情况。
借助mysql的adminstartor工具可以设定上述两个方面.

1 可以修改my.ini的情况下，在[mysqld]添加或修改
init-connect='SET NAMES gb2312'
2 不能修改my.ini
可以在php connect mysql后执行mysql_query('SET NAMES gb2312;');
是不是更改my.ini的时候性能会好一些，但是无论PHP/JSP所有的conn都是gb2312了？所以灵活性丧失了一点如果在mysql_connect()后面增加set names的话是不是会增加一次与DBserver的operation？导致一些性能损耗？我这里目前需要通过java写入mysql-master，然后通过replication到多个slaves，最后php-web读取slave数据，乱码问题始终在某些servers上存在现在的办法是在DBFactory里面每次conn后set names 但是总觉得可以通过设置mysql来实现，项目的PHP使用的是GBK，但是java采用的utf-8 同时replication的master/slave必须保持一致的CHARSETso，SET names似乎是最好的选择但是它会不会带来很大的性能占用？这是我最关心的，mysql Manual 似乎没有提到

那就直接用utf-8网页编码~

转utf8码是客户否决掉的他们自己的企划号称看不明白网页源码GBK，是客户一个大娘教我们用的阿

问个问题先：
昨天我发现有无法LIKE的数据，以前数据库是Mysql 4.0.x的，现在转到4.1.x上面，有输入中文查询的时候无法取得结果，英文数字没有问题。
原来Mysql4.0没有设置编码，Mysql4.1也没有设置编码，好像默认是拉丁字符。另外：使用phpmyadmin看数据库内容都是乱码，执行 set charset 'gbk' 或set charset 'utf8'都没有用大家说该怎么办？是不是还要转回到Mysql4.0?

为方便大家领分，特别开辟一个新帖。有兴趣也可到下面连接回复上面的问题来领分：
http://community.csdn.net/Expert/topic/4644/4644429.xml?temp=4.728335E-02

借这个地方问一个问题：
我要通过WEB方式管理数据库资料，现在后台网页的编码是GB2312，管理的数据是日文，最终网页显示的是Shift_JIS编码，请问我应该如何增加资料到数据库中，又如何取出资料，使它能够正确地显示出日文呢？什么办法最简单？

调试易

【注意】mysql_4.1/5乱码问题专用贴

解决方案 »