HTTP 协议中的Content-Encoding

最近在做拟态开发过程中，遇到lua脚本响应PHP返回接口的数据乱码问题，通过postman调试发现响应头部Content-Encoding算法为gzip，而其他接口如python则没有这个设置。

首先来了解下什么是Content-Encoding？

Accept-Encoding 和Content-Encoding是HTTP中用来对采用哪种编码格式传输正文进行协定的一对头部字段。

工作原理如下:

• 首先浏览器（也就是客户端）发送请求时，通过Accept-Encoding带上自己支持的内容编码格式列表；
• 服务端在接收到请求后，从中挑选出一种用来对响应信息进行编码，并通过Content-Encoding来说明服务端选定的编码信息

• 浏览器在拿到响应正文后，依据Content-Encoding进行解压。

  服务端也可以返回未压缩的正文，但这种情况不允许返回Content-Encoding

内容编码的目的是优化传输内容的大小，通俗的讲就是尽心压缩。一般经过gzip压缩过的文本响应，只有原始大小的1/4（这个数据我现在还不确定）。对于文本类响应是否开启了内容压缩，是我们做性能优化时首先要检查的重要项目；而对于JPG/PNG这类本身已经高度压缩过的二进制文件，不推介开启内容压缩，效果几乎微乎其微，还浪费cpu

内容的编码针对的只是传输正文。在HTTP/1中，头部始终是以ASCII文本传输，没有经过任何压缩。不过这个问题在HTTP/2中已经解决，详见HTTP/2 头部压缩技术介绍

内容编码使用特别广泛，理解起来也特别简单，但是要注意的是不要把它与HTPP中的另外一个概念：传输编码Transfer-Encoding搞混即可。

内容编码格式gzip 和deflate

开始之前，先来介绍三种数据压缩格式：

• DEFLATE，是一种使用 Lempel-Ziv 压缩算法（LZ77）和哈夫曼编码的数据压缩格式。定义于 RFC 1951 : DEFLATE Compressed Data Format Specification；
• ZLIB，是一种使用 DEFLATE 的数据压缩格式。定义于 RFC 1950 : ZLIB Compressed Data Format Specification；
• GZIP，是一种使用 DEFLATE 的文件格式。定义于 RFC 1952 : GZIP file format specification；
  这三个名词有太多的含义，很容易让人晕菜。所以本文有如下约定：
• DEFLATE、ZLIB、GZIP 这种大写字符，表示数据压缩格式；
• deflate、gzip 这种小写字符，表示 HTTP 中 Content-Encoding 的取值；
• Gzip 特指 GUN zip 文件压缩程序，Zlib 特指 Zlib 库；
  在 HTTP/1.1 的初始规范 RFC 2616 的「3.5 Content Codings」这一节中，这样定义了 Content-Encoding 中的 gzip 和 deflate：
• gzip，一种由文件压缩程序「Gzip，GUN zip」产生的编码格式，描述于 RFC 1952。这种编码格式是一种具有 32 位 CRC 的 Lempel-Ziv 编码（LZ77）；
• deflate，由定义于 RFC 1950 的「ZLIB」编码格式与 RFC 1951 中描述的「DEFLATE」压缩机制组合而成的产物；

nginx中如何设置gzip

在nginx.conf文件中 找到gzip 默认是on开启状态，改为off表示关闭
然后重启nginx服务

/usr/local/nginx/sbin/nginx -s stop
/usr/local/nginx/sbin/nginx

发现Content-Encoding没有返回，OK，这样不同接口之间就是原样输出，方便lua脚本输出内容！