抓到的 HTTP Response 是一串字符串，看到的 content-encoding：gzip，反解码不成功是啥原因?

[satanwoo]

昨天抓包，看到reponse是一串字符串，然后查了下header 里面包含了gzip encoding，但是用了一些gzip decompress tool怎么解析失败，是啥原因。

失败的原因不是说解析出来看不懂，而是直接报了invalid，请问各位大大这是啥原因。

[dbfox]

目测是分段传输数据了
http://blog.csdn.net/whatday/article/details/7571451

[satanwoo]

@dbfox Charles这个抓包软件输出的reponse应该是最后完整收到的。所以应该还是得到把所有块当成字符串流全部拼在一起后的效果吧?这样的话好像不应有影响呀~

[cj1324]

也有可能收到数据太多了。 需要截断。

[satanwoo]

@cj1324 单独一个API查询返回的repsonse也需要截断吗？

[julyclyde]

@satanwoo 服务器那边想怎么输出都可以，只要符合标准。至于你说的“单独一个API”那是更上层的事情了，和协议无关

[satanwoo]

@julyclyde 我的意思，我抓的数据显示相当于一次完整传输的最终结果~就类似于服务器断断续续传，我在这边最终收集好了显示出来，这就是服务器通过这是传输发给我的所有东西吧，对不？那我现在想反解码这个完整的数据为啥不行呀~

[iannil]

应该是使用了gzip压缩，返回的response需要解压一下。

[satanwoo]

@iannil 我就是用了gzip工具包反解压不成功嘛~

[iannil]

@satanwoo 什么语言？什么方法解压的？

[satanwoo]

@iannil 在线工具包之类的呀~

[msg7086]

@satanwoo 我猜测你用的在线工具可能只吃gzip文件而不吃gzip流。

[satanwoo]

@msg7086 他支持direct input哎~

[iannil]

@satanwoo 别用在线工具包，最好用标准化的工具来进行解压

[julyclyde]

@satanwoo 你先看一下HTTP响应里是不是写了Transfer-encoding:trunked这样的

[satanwoo]

@julyclyde 是的~

[julyclyde]

@satanwoo trunked每段开头有一行16进制数字，表示后面的内容的字节数。然后从下一行开始是内容。每段分别解压缩应该可以

[satanwoo]

@julyclyde 恩，你的回复我了解哈~但是我不是直接侦听网络数据块，我是用的charles，这个软件可以直接按照正确的方式~拼接收到的这种trunk的数据，所以我也不太理解。

[julyclyde]

@satanwoo 如果真的正确拼接了自然是能解压缩的