admin管理员组

文章数量:1594248

2024年5月11日发(作者：)

字符集转换解决方案

问题的提出：

关于字符串的字符集转换，目前应用系统中主要在对数据库操作的时候。

1. 向数据提交操作请求

会对每一个String类型的变量做一次GBKToUnicode的操作，实际上此操作最终会

触发unicodeToGBK操作，而在unicodeToGBK中会调用isGBKString方法用来判定此

字符串是否是GBK编码，采用的方式是循环比较字符串数组中的每一个char对象值。

2. 从数据库返回数据信息

会对每一个String类型做一次unicodeToGBK的操作，同样会调用isGBKString方

法。

由于上述操作导致应用服务器的性能产生很大的负载，因此需要及时改进。

已经解决的问题：

对于从数据库返回数据信息而做的unicodeToGBK操作，我们主要是在schema的

getString时调用，及exesql中的getdatavalue中调用。Schema中的调用我们通过一

个静态变量CHARSET来控制是否执行（目前默认情况下是不执行），

而exesql中的调用是强制执行的。

经过民生的近期测试，我们发现可以去掉exesql中的unicodeToGBK操作，而保证

数据在返回到前台的时候没有乱码。

尚未解决的问题：

对于向数据提交操作请求而做的GBKToUnicode的操作，实际上此操作也依赖于

CHARSET变量

 如果此变量为true

则执行new String(es("GBK"), "ISO8859_1");

 如果此变量为false

则执行new String(es("ISO8859_1"), "GBK");

现在系统中CHARSET默认设置为false，而不论此变量为何值，

系统都会执行isGBKString这个操作。

问题：如果我们去除这一操作，会导致提交到后台数据库中的中文全部变成??的形式，

在查询的时候，也无法使用中文作为查询条件。

以前的存储方式：

以前的应用是通过unicodeToGBK进行转换，提交给数据库的时候，字符集的编码采

用的是GBK。之所以当初要在后台统一字符集处理，是因为无法有效保证前台提交过来的

本文标签： 操作提交数据库字符集时候

版权声明：本文标题：中间件字符乱码问题 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/dongtai/1715362710a448366.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。