mysql处理Latin 中文繁体字乱码解决方案

本文解决MySQL数据库中中文繁体字符显示乱码的问题,通过调整字符集转换方式,确保繁体字如“燈、龍”正常显示。
部署运行你感兴趣的模型镜像

 

问题描述:

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); } 

再一测试,问题解决!

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型,相比 3.0 版本,它提升了图像质量、运行速度和硬件效率

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值