又遇mysql乱码问题

编码最大的几个问题在于

    a 数据库服务器存储编码(假设服务器、数据库、表、字段所有的都一样)
    b 数据库连接编码,这是非常关键的,mysql 5.0启动后,一般命令行连接上后用的是服务器my.ini里client的配置,连接上后可以通过
     "set names 'utf8'"进行设置。可以通过"show variables like 'character%'"进行查看
    c 导入文件的编码,比如你的导入脚本是user.sql,这个也有个编码。

(1)实验1

 文件采用GB2312编码,通过client的source命令导入,默认为UTF8,而mysql服务器采用UTF8存储
 使用client进行查询时,直接看到的是正确的显示。导入时把GB2312的二进制文件看成UTF8,查询出来时如用UTF8连接,则返回的
 二进制其实是GB2312的二进制,这个过程没进行任何转换。
 
 (2) 实验2
 
  文件采用UTF8编码,通过client的source命令导入,默认为UTF8,而mysql服务器采用UTF8存储
 使用client进行查询时,直接看到的是错误的显示。导入时把UTF8的二进制文件看成UTF8,查询出来时如用UTF8连接,则返回的
 二进制其实是UTF8的二进制,这个过程没进行任何转换。而操作系统client的默认显示用的是GB2312的代码页,所以乱码。
 但是用jdbc连接,返回的是正确的显示,我认为jdbc默认也用server中client的设置进行连接,即UTF8,特别是mysql 5.0以上的好像设置useUnicode=true&characterEncoding不起作用,还是用的UTF8。最后返回的二进制跟client
 一样是UTF8的二进制,而mysql的驱动可能能够识别这是UTF8的,字符串在显示时能够转成操作系统的本地编码(gb2312),这是jdbc
 驱动的功劳。
 
 (3)实验3
 
  同样client和server都设置成UTF8,然后把脚本贴到EMS中使用show sql editor导入,然后发现EMS中显示表的内容正常,
  而客户端select出来的是乱码,同样jdbc程序也是乱码。奇怪。
  后来把jdbc出来的字符串进行了一个转码,从latin1到gb2312的转换,正常。
  new String(rs.getString(2).getBytes("latin1")
  原来ems导入时采用的default-charset竟然是编码latin1。
 
  (4)实验4
  文件采用UTF8编码,client设置成gb2312,source不能导入,报Data too long.
  应该是UTF8的二进制有些在gb2312里不存在,所以错误。
 
  归根结底,最好采用编码都是UTF8,这样就不太容易产生乱码
 
  另外,如果文本t采用编码A,二进制为xx,导入时连接采用编码B,数据库采用编码C。
  则入库时采用B——>C的代码转换,即把xx当作B映射到C,如成yy。
 
  则为了不发生乱码,取数据时应该设置连接为编码B,发生的则是C-->B的转换,从yy转成xx
  从数据库返回的二进制为xx的数据。再用编码为A的代码页来显示它,操作系统才能正常显示文本t。

你可能感兴趣的:(mysql,数据库,jdbc,服务器,数据库服务器,variables)