Fiddler的实践心得（三）: 重新认识Decode

重新认识Decode

在之前的认识中，知道有这样的Decode在工具栏中，也知道是解密的，在是在实践中并没有涉及到这块，今天就被我碰到了，而且自己还跳坑了，还好还好，最后明白了~~

---

Decode在平时默认是被选中的，我不知道什么时候就给取消了，就闹了个乌龙，不过自己也学到了新知识，就是这么美，这么美~~~

今天的情况是这个样子的：

客户端请求一个接口的数据是加密的，通过save -> response -> response body ,将返回结果保存下来，之后用这个本地文件替换服务器返回的数据。结果客户端接到数据之后，在后台报了一个错误，提示数据格式不对。正常来讲，客户端接到数据之后，需要进行解密，在解密的时候发现数据格式不对。

保存下来的response body ：

6failed0

服务端一阵排查问题，客户端一阵排查问题，没毛病啊！！！最后问我，你的本地文件内容是什么？把内容贴出去之后，都是很疑问 6 、0 是怎么回事？
服务端说不是我们返回的，客户端说不是我们添加的。
OH MY GOD ！
我也急了，怎么可能是我这里的问题，平时都是这样用本地文件替换服务器文件的，没毛病啊！

后来仔细瞅了瞅，发现了 Response body is encoded ，Click to decode . 点了一下，哦~~~顿时豁然开朗。

• 请求一个接口，返回来的数据如下图所示：第一行和最后一行是数字，当时不知道是怎么回事，现在有点明白了，这个就是所谓的返回的数据加密了，【虽然看起来是明文】，6 是加密串（failed）的字符长度

• 应该也看到Response body is encoded. Click to decode. understand ? 点击一下就可以解密了。

  

• 解密之后的数据

• 这个时候再save -> response -> response body ,将返回结果保存下来，AutoResponder替换服务器文件，客户端就可以正常的解密运行了。

问题虽然是解决了，但是得找到真正的原因啊？

提到解密，当然是第一时间想到了Decode，一看，居然没有被选中，突然间就明白了Decode的作用，如果返回的数据时加密的，就自动解密。
为了验证，又重新请求了一次，结果你猜怎么着，还真的是这个道理。

细节决定成败啊，任何一个小功能都不能被忽视啊！盆友们啊，都要慎重啊，慎重！