一个小小BUG的解决

一、本文旨在寻求一种快速对应BUG的应急方法，为系统维护人员提供一种可能性，不建议在别的场合下使用。

二、BUG描述

现象：日志下载后查看时，中文部分全部是乱码。

业务逻辑：日志是存储在MongoDB中，需要下载时，从数据库取出，供用户下载查看。

三、面对的困难

1.系统复杂：代码量大、日志转存环节多而杂。

2.技术新：Springboot为基础的系统技术紧靠前沿，架构复杂。

3.迷雾重重：在开发环境下，此BUG并不出现？

4.没有源代码：给分析定位BUG造成一定困难。

5.系统部署时，需要license，而这个license是IP敏感的，给BUG跟踪和修改后的验证工作带来一定的不必要的麻烦。

四、BUG快速定位

1.日志下载功能实现方法简单分析：借助工具，查找日志下载功能模块。

2.定位日志下载功能接口实现代码：

                                                         

3.分析代码：进一步定位代码位置：

                           

4.进一步分析代码：此方法的逻辑为：A.拿到需要下载的内容，B.改向到下载文件流。

5.关键分析：需要下载的内容为String类型，是带有中文编码的，而在转换成下载流时，并未具体指定。

五、快速修改

1.修改依据：

2.根据上面的“关键分析”，问题关键是使用了平台默认的字符集，当这个平台的默认字符集与String的编码一致时，便不会出现这个BUG，就是说这个的BUG的出现与否，完全依赖于系统的部署平台。

3.修改后的代码：

                        

4.修改方法：（略），重点在问题的分析。建议在源代码中进行修改。

六、快速验证：（略），建议按源码修改--》编译--》制作发布包--》发行License--》日志下载功能验证的正常流程进行。

七、一点启示

1.在没有源代码、或进行现场系统维护时，可以快速应急对应，不失为一种方法。

2.对java的安全性提出了一种挑战的可能性，需要特别注意。

3.为系统故障分析提供了一种方法。

4.【八】中给出一种非代码级的方法，但只适用于linux，因为Windows不提供此功能。

八、开阔眼界、拓展思路

1.测试String编码的方法

                                         

此方法可以枚举测出字符串（参数一：String str）是不是指定的编码（参数二：String encode）。

2.取得平台缺省编码的方法

                                

一般地，win xp 中文版的缺省编码为GBK；win server中文版为GB18030；linux就需要看本地语言环境的配置了。

3.编码问题其实无处不在，java就分为JVM内编码和JVM外编码；还有java文件编码，java class编码；还有内存编码等等，在java开发过程中，都需要留意。

4.修改linux的缺省编码设置                                                      

这是解决问题最简便的方式方法。但只适用于linux平台，也非一劳永逸的方法。