mysql处理Latin 中文繁体字乱码解决方案
来源:互联网 发布:拓尔思 知乎 编辑:程序博客网 时间:2024/04/29 19:08
问题描述:
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)方法,该方法源代码如下:
这里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中不处理,将上面代码修改为:
再一测试,问题解决!
- mysql处理Latin 中文繁体字乱码解决方案
- mysql处理Latin 中文繁体字乱码解决方案
- MYSQL中文乱码解决方案
- mysql中文乱码解决方案
- MYSQL中文乱码解决方案
- MySQL中文乱码解决方案
- MySql 中文乱码解决方案
- MySQL中文乱码解决方案
- mysql中文乱码解决方案
- mysql中文乱码解决方案
- MySql中文乱码解决方案
- Mysql中文乱码解决方案
- mysql 中文乱码解决方案
- Mysql 中文乱码解决方案
- MySQL 中文乱码解决方案
- mysql中文乱码解决方案
- MySQL中文乱码解决方案
- Mysql中文乱码解决方案
- 自引用结构兼谈Malloc和Free函数
- Java生成指定长度的随机密码
- 如何提高意志力&如何坚持每天学习档
- Android Build: Tips and Tricks
- 10.4. Exim4邮件服务器
- mysql处理Latin 中文繁体字乱码解决方案
- 静态链接库的生成
- web service 基础知识
- Java实践
- 常用的vs编码技巧2
- 配置文件
- 防止进程重复运行
- C#异或运算
- 使用自定制的dll