记一次字符乱码bug解决过程

前言

最近被分配了一个bug：解决上报数据中文乱码问题。d⊂(ο･㉨･ο)⊃又是字符乱码问题。

大概背景是：该数据是在produce.dll中通过assemble.dll组装，调用upload.dll上传的

如何在多个模块中定位是哪个环节出的问题，这是比较恶心和比较棘手的问题~

解决过程

一、首先解决如何在多个模块中定位哪个环节出的问题

1）通过日志定位问题。本来是想通过看日志定位问题的，但是日志显示的没有乱码，然而抓的包以utf-8显示时，发现就乱码了，所以通过日志定位不可行。

2）通过调试定位问题。不能看日志，那就只能上手调啦~由于复现环境不是本机，是远程机器，那只能远程调试，我会的远程调试只有俩：visual studio远程调试和windbg远程调试。由于远程机器环境是windows server，所以visual studio似乎attach不上去，我就放弃它，选择windbg远程调试了。

windbg远程调试不是很麻烦，只要把对应模块的pbd和代码拷贝到远程机器，然后就attach对应进程，下断点（可通过bp命令或打开代码下断点），触发产生中文乱码现象，这时就会走到断点，然后逐步调试即可。

 通过调试，发现是assemble.dll组装时乱码了，导致上传乱码了，坑啊！assemble.dll模块该部分逻辑已经用很久了，一开始就没想过会是这里问题...还是别太相信前人...d(•́へ•́╬)

二、定位到模块后，如何发现是哪个组装逻辑出错导致乱码

菜鸟如我，解决乱码这个问题还是有点头疼+不自信，定位到大概范围后，我就虚心请教大佬了~大佬说：

CString和string互转就是容易出中文乱码问题，瞅瞅是不是互转导致的，把这部分的来回转换的结果以CString格式输出，这样就可以定位哪个组装逻辑出错！CString是宽字节存储的，它显示的字符串没乱码，则可以说明没乱码~

于是我就虚心接受大佬意见，把那范围内的转换前后的字符串以 CString格式输出，调试发现就是使用代码公共库导致的乱码！！！坑啊！！！！

bug产生原因大概是：

前面组装的数据是UTF-8格式保存的CString类型的东西，然后调用代码公共库，出来的就是乱码了，因为代码公共库里对这个CString东西强转，代码类似酱紫：

LPCTSTR lpValue = utf8保存的CString东西；

jvRoot[CStringA(lpKey)] = (LPCSTR)CStringA(lpValue);

总结

从日志定位不到问题了，就不要死磕日志，如往模块里加更多日志，然后重试。直接上手调试吧，虽然搭建调试环境有点麻烦，但是弄好后定位问题就快很多了~

另外，即使是前人写的模块，用了很久没发现问题，定位问题时也可以大胆质疑~个人觉得定位bug，应该怀着谁也不要信的态度去定位，这样可能不会被坑得那么惨。。。。

以上