一、本文旨在寻求一种快速对应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平台，也非一劳永逸的方法。