记一次编码问题的扯皮解决

事情是这样的

测试在测一个agent.ini为UTF-8中文保存的时候出现了乱码问题。

经过我的定位发现直接写一个方法，将进入的类的所有字符串参数通过反射由GBK转UTF-8，即可解决此问题。

我直接将此代码提上去，结果审核没给我过。

问我为什么要由GBK转UTF-8？

我说这是测试提的问题单，我这方法就是解决这个问题的。

可是不是根本问题，那如果他本身就是GBK的中文，如果通过我这个方法就会乱码。

也就是说，实际上的问题我总结一下就是：

如果客户使用GBK或者ANSI的中文，可以全程正常没问题。
如果客户使用UTF-8的中文，会被系统的agent代码功能误认为是GBK，进入Java这边就是乱码了（以UTF-8的中文，被错误识别成GBK）。我们要程序里加上一段将GBK转换成UTF-8，就能解决这种问题。但我们这个解决方案，会影响使用GBK或者ANSI的中文客户，使得这部分客户乱码。
两种解决方案，一种是：
1.在agent的软件使用说明书备注agent.ini使用中文时需要GBK或者ANSI编码，无需更改代码。
2.在agent的软件使用说明书备注agent.ini使用中文时需要UTF-8编码，我们加上一段将误识别成GBK的编码转换为UTF-8的方法。
无法同时兼顾两类客户，以一个方法转成正确的，因为我们要知道原始编码才能进行转换，我们获取到的只是字符串，没法判断里面的中文是否是乱码。

说到底我们并不知道编码是什么格式的，如果给火星文给我们，我们是没办法识别的对吧。

因此实际上就是像配置文件这种东西，如果客户要动，就不能乱动，编码格式规定好。

而不是通过我们开发来根据编码格式进行适配。

并且还有一个问题，我以为所有开发要么是用txt或者nodepad++打开时，问了才发现

还有的用nodepad，有的用vscode打开

就会存在ANSI，GBK，UTF-8，甚至还可能有只用简体的GBK2开头的

规范还是很重要的，如果最开始规范好

就直接少半天的扯皮，也不至于加班为这种问题扯皮了。