又遇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。