奇葩的中文乱码问题

回到首页☞

1、问题描述

也许系统展示业务日志的时候，只要一个工程，也只在生产环境是乱码的。通过utf-8转码无效。
系统是jalor5工程，采用传统的tomcat 实例部署在linux 虚拟机上。
日志是通过执行引擎接口在MongoDB中获取，AES加密后通过jar解密，获取日志的工程有多处，只有一个工程有问题。

2、问题排查

• 本地运行怎么都重现不了，代码完全一致。
• 检查Tomcat配置，都是utf-8，tomcat服务器也没问题。
• 检查linux环境变量，发现其中 一个工程的单边OS编码不是utf-8.
• 检查jar包源码，最后解密后有个new String动作，深入jdk源码发现java 底层获取的jvm启动编码。
• 写一个test类，设置jvm环境变量-Dfile.encoding=ISO-8859-1进行测试

package com.wht.service.impl;

/**
 * @author JDIT
 */
public class Test {
  public static void main(String[] args) {
    System.out.println(System.getProperty("file.encoding"));
    String str = "中华人民共和国";
    System.out.println(str);
  }
}

运行结果：

ISO-8859-1
???????

Process finished with exit code 0

果然乱码了。

3、处理方案分析

1、直接修改os编码
影响太大，系统有几T的历史附件，编码已经不是utf-8，下载使用会出问题。
2、深入分析jar源码

• 获取AES加密后的日志，没问题，加密数据串正常，反向解析没问题。
• 通过jar包获取数据有问题，因为通过代码点创建string返回的时候出错。
  3、替换jar
  jar中的desAes方法没有参数设置编码格式，jdk中的file.encoding可以获取却不能设置，Default charset不能通过代码修改。
  最小影响的处理方法，解密方法不再用公司的，自己封装一个class，指定编码集解码。

4、小结

很多时候我们可能按照自己的固有认知莫名其妙的解决了问题，但是不是真的懂得，只有能反演出来，并且处理，才是真的懂得，并且真的把问题处理了。

回到首页☞