一场HTTP协议头信息引发的“血案”
本帖最后由 Crazy开发仔 于 2020-3-11 13:31 编辑测试网站：https://www.fontke.com/tool/code128/
所用工具:E语言，FD(Fiddler，抓包神器)，gzip.dll，notepad++(可选)
测试环境：win7 x64
测试人员:Crazy开发仔(以下简称：小C)
经过全国医务工作者的艰苦付出及全国人民的“贡献”—(除了吃就是睡)，新冠肺炎疫情控制稍有成效，可喜可贺。废(sao)话连篇，言归正传。值此之际，发一篇原创技术帖助助兴。
闲来无事，F5一下吾爱，看了一下论坛小伙伴的帖子—“Code128条形码批量生成器V2.0”，作者用的java语言开发，界面清爽，感谢“caiguangpeng”小伙伴的付出与无私奉献(因为小C也是一枚爪哇仔)。
java语言来实现条形码生成固然好，不过小C比较懒。抓个舌头(第三方接口)来帮我干活，不香吗?主意已定，打开某度搜索目标，于是“猎物”—fontke就出现了。
开启FD(关于FD，请大家自行百度，也可以看我之前的帖子：实战:某文档在线导出工具,E语言下载器简易实现)的抓包功能,先来玩一把“Code 128条形码生成器”，码值：www.52pojie.cn，然后点“立即生成”，发现右侧果然出现了条码。
切换到FD界面，关闭抓包。找一下本机浏览器与fontke服务器之间的数据传输项，FD抓包过程中，本机与外界的网络传输相对较少，因此很容易就能找到相关数据包。选中此包，看一下对应的HTTP请求头信息，很明显是一个简单的GET请求，所有的请求参数都在URL中，请求头信息不再赘述(不懂的小伙伴可自行学习一下)。
再来看一下对应的响应信息(Raw)，映入眼帘的就是响应头，没什么异常，咱来看一下响应体，WTF，这是什么鬼?出现了一些莫名的乱码(其实是字节集数据)，根据小C多年的开发经验(瞎猜)推测，肯定就是条码图片啦。
打开E，新建Win工程，拖个图片框，再拖个按钮上来，界面搞定(果然清爽宜人啊)。接下来就是写代码了，代码也很简单—就是获取条码图片，然后让图片框来显示就可以了。
一顿操作猛如虎，见证奇迹啦，点了“获取”按钮之后，图片没有显示出来。一定是网络原因，再来一次肯定没问题的(程序员的自我安慰大法)，还是TM不显示。哎哟，有点意思，遇到这种情况，不要慌，调试输出大法看看究竟是何方妖孽，调试输出之后返回的字节集非空，那就说明图片没有问题，但是为啥不显示呢?
冷静一下，回到“案发现场”找一下“蛛丝马迹”，看看响应头数据，果然有了“重大发现”—“Content-Encoding: gzip”返回的数据竟然用了gzip压缩，所以条码图片肯定不是服务器生成的原始图片，显示不了就是正常的。正所谓“兵来将挡水来土掩”，你压缩，我就解压缩。接下来有请gzip.dll，为了方便，这里小C使用了“精易模块3.45”，代码稍作改动，将获取到的图片数据解压缩一下，然后再显示到图片框。
再来测试，图片框正常显示图片了，一个简单的条码生成器Demo完成。HTTP协议很重要，在此也希望各位小伙伴认真的学习一下。坏了，我的可乐鸡翅还没有热，先去吃饭了，下次再见。 无阻 发表于 2020-3-11 14:08
那直接把gzip处理的协议头说明去掉不就不需要gzip.dll解压了
我刚才重新试了一下，请求协议头中删除了压缩
请求协议头：
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Referer: https://www.fontke.com/tool/code128/
Accept-Language: zh-CN,zh;q=0.9
但是返回的图片还是经过gzip压缩的 袁煜914 发表于 2020-3-11 13:38
沙发大佬我来了
你好，大佬 支持一波 emmm，一行字的文章{:1_924:}，可以不用这么大费周章吧:loveliness: 那直接把gzip处理的协议头说明去掉不就不需要gzip.dll解压了 Ercilan 发表于 2020-3-11 14:05
emmm，一行字的文章，可以不用这么大费周章吧
技术比较菜，所以写的比较啰嗦。