中间件字符乱码问题.docVIP

字符集转换解决方案 问题的提出： 关于字符串的字符集转换，目前应用系统中主要在对数据库操作的时候。 向数据提交操作请求 会对每一个String类型的变量做一次GBKToUnicode的操作，实际上此操作最终会触发unicodeToGBK操作，而在unicodeToGBK中会调用isGBKString方法用来判定此字符串是否是GBK编码，采用的方式是循环比较字符串数组中的每一个char对象值。 从数据库返回数据信息 会对每一个String类型做一次unicodeToGBK的操作，同样会调用isGBKString方法。 由于上述操作导致应用服务器的性能产生很大的负载，因此需要及时改进。 已经解决的问题： 对于从数据库返回数据信息而做的unicodeToGBK操作，我们主要是在schema的getString时调用，及exesql中的getdatavalue中调用。Schema中的调用我们通过一个静态变量SysConst.CHANGECHARSET来控制是否执行（目前默认情况下是不执行），而exesql中的调用是强制执行的。 经过民生的近期测试，我们发现可以去掉exesql中的unicodeToGBK操作，而保证数据在返回到前台的时候没有乱码。 尚未解决的问题： 对于向数据提交操作请求而做的GBKToUnicode的操作，实际上此操作也依赖于SysConst.CHANGECHARSET变量 如果此变量为true 则执行new String(strOriginal.getBytes(GBK), ISO8859_1); 如果此变量为false 则执行new String(strOriginal.getBytes(ISO8859_1), GBK); 现在系统中SysConst.CHANGECHARSET默认设置为false，而不论此变量为何值，系统都会执行isGBKString这个操作。 问题：如果我们去除这一操作，会导致提交到后台数据库中的中文全部变成??的形式，在查询的时候，也无法使用中文作为查询条件。 以前的存储方式： 以前的应用是通过unicodeToGBK进行转换，提交给数据库的时候，字符集的编码采用的是GBK。之所以当初要在后台统一字符集处理，是因为无法有效保证前台提交过来的信息编码格式。 问题分析： 产生上述情况的原因是Jsp/Servlet 不能接收form提交的汉字，也不能解析通过get方式传递的汉字。 运行于Java 应用服务器的 JSP/Servlet 为 Browser 提供 HTML 内容，其过程如下图所示： 其中有字符编码转换的地方有: JSP 编译。Java 应用服务器将根据 JVM 的 file.encoding 值读取 JSP 源文件，编译生成 JAVA 源文件，再根据 file.encoding 值写回文件系统。如果当前系统语言支持 GBK，那么这时候不会出现 encoding 问题。如果是英文的系统，如 LANG 是 en_US 的 Linux, AIX 或 Solaris，则要将 JVM 的 file.encoding 值置成 GBK 。系统语言如果是 GB2312，则根据需要，确定要不要设置 file.encoding，将 file.encoding 设为 GBK 可以解决潜在的 GBK 字符乱码问题 Java 需要被编译为 .class 才能在 JVM 中执行，这个过程存在与a.同样的 file.encoding 问题。从这里开始 servlet 和 jsp 的运行就类似了，只不过 Servlet 的编译不是自动进行的。对于JSP程序, 对产生的JAVA 中间文件的编译是自动进行的(在程序中直接调用sun.tools.javac.Main类). 因此如果在这一步出现问题的话, 也要检查encoding和OS的语言环境，或者将内嵌在JSP JAVA Code 中的静态汉字转为 Unicode, 要么静态文本输出不要放在 JAVA code 中。对于Servlet, javac 编译时手工指定-encoding 参数就可以了。 Servlet 需要将 HTML 页面内容转换为 browser 可接受的 encoding 内容发送出去。依赖于各 JAVA App Server 的实现方式，有的将查询 Browser 的 accept-charset 和 accept-language 参数或以其它猜的方式确定 encoding 值，有的则不管。因此采用固定encoding 也许是最好的解决方法。对于中文网页，可在 JSP 或 Servlet 中设置 contentType=text/html; charset=GB2312；如果页面中有GBK字符，则设置为contentType=text