问题描述：
1. 对于一些中文繁体字符select出来出现乱码，出问题的繁体字如：灯、龙等
环境描述：
数据库编码：
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| auto_increment_offset | 1 |
| 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 | D:/Program Files/mysql/share/charsets/ |
+--------------------------+----------------------------------------+
数据库表编码：也同意使用latin1编码方式
由于数据库由DBA负责，并且库结构为了保持一致（我们使用备份库），从而不能修改数据库编码
问题排查：
1.mysql 的jdbc驱动源代码拷贝下来DEBUG，最终发现了问题根源在驱动中CharSetMapping.class该类中的getJavaEncodingForMysqlEncoding(String mysqlEncoding,Connection conn)方法，该方法源代码如下：
public final static String getJavaEncodingForMysqlEncoding(String mysqlEncoding, Connection conn) throws SQLException { if (conn != null && conn.versionMeetsMinimum(4, 1, 0) && "latin1".equalsIgnoreCase(mysqlEncoding)) { return "Cp1252"; } return (String) MYSQL_TO_JAVA_CHARSET_MAP.get(mysqlEncoding); }
这里Latin1编码就是iso-8859-1编码。问题就出在这里，mysql驱动对Latin1编码做了特殊处理，转为cp1252，但cp1252依然属于Latin1系编码，故显示中文依然会存在乱码，故需要在GBKstring中转化cp1252.
这么做了以后，发现我看到的中文都不再乱码OK，包括一些繁体字和火星文，大功告成了。
过了一天，我们测试给我反馈结果，说一些繁体字依然存在乱码，比如“灯、龙”等，在页面上显示“？”，究竟哪儿出了问题？继续DEBUG，
发现普通汉字从Latin1转码为cp1252后的byte array中的数据中，用两个字节表示一个汉字时，能够在GBK编码映射表中找到byte array对应的2字节数据，而“灯、龙”两个繁体字转cp1252后，其对应的byte array中的2字节数据无法再GBK编码中找到（既GBK中无法找到该2字节数据对应的汉子），从而出现“？”。
故问题应该就出现在这里，既从latin1->cp1252->gbk这样一个过程会出现以下编码数据丢失。从而解决方案也是很明显的：
既：去掉中间转cp1252的步骤，直接将Latin1 转gbk，同时gbkString中不处理，将上面代码修改为：
public final static String getJavaEncodingForMysqlEncoding(String mysqlEncoding, Connection conn) throws SQLException { if (conn != null && conn.versionMeetsMinimum(4, 1, 0) && "latin1".equalsIgnoreCase(mysqlEncoding)) { return "gbk"; } return (String) MYSQL_TO_JAVA_CHARSET_MAP.get(mysqlEncoding); }
再一测试，问题解决！