什么ContentType和ContentEncoding？

一、Content-Type，即内容类型，一般是指网页中存在的Content-Type，用于定义网络文件的类型和网页的编码，决定文件接收方将以什么形式、什么编码读取这个文件（例如：application/octet-stream;charset=GBK），指定服务器响应的HTTP内容类型，这就是经常看到一些Asp网页点击的结果却是下载到的一个文件或一张图片的原因。

ContentType属性指定响应的 HTTP内容类型。如果未指定 ContentType，默认为TEXT/HTML。也就是说可以理解为指定文件以什么样的格式传输，指定文件下载下来后的文件格式。

另外上传文件时，设置的charset=utf-8，是对文件名和带的参数设置编码格式，而MultipartFile本身就是流，所以不是对文件内容设置编码格式。

二、ContentEncoding，既是设置文件内容的编码格式，传输前什么格式，传输后接收到要以什么格式解析。比如文件内容乱码问题。这种情况是根据特定场合拥有该属性的才可以，一般网页传输用上边的就可以，同时设置文件内容类型和编码。

注意：对二进制文件流，字节数组等进行encoding，是不起作用的，因为文件内容的编码格式已经写入二进制字节中，无论怎么设置都没有作用，除非在进入二进制前，提前转码。

三、jsp中：pageEncoding与contentType属性

摘要：1图例分析 由图中可以看出,这个两个属性没有任何关系。把这两个设置成不同的编码格式对中文显示不会产生任何影响2.原因分析pageEncoding规定了以什么编码方式存储和读取,使两者保持一致性,这样就不会出现乱码情况。对jsp页面进行处理后生成的java文件中,我们可以看到是通过out.print()输出到网络上的,所以我们再规定以UTF-8的方式写到网络上去,而浏览器也以相同的方式来显示,这样就不会出现乱码了。 

2.原因分析

---

pageEncoding规定了以什么编码方式存储和读取,使两者保持一致性,这样就不会出现乱码情况。对jsp页面进行处理后生成的java文件中,我们可以看到是通过out.print()输出到网络上的,所以我们再规定以UTF-8的方式写到网络上去,而浏览器也以相同的方式来显示,这样就不会出现乱码了。

四、Content-Encoding与Content-Type的区别

1指定Web服务器必须如何使用Content-Encoding标头指示  编码转换。虽然从表面上看，Content-Encoding（例如，gzip，deflate，compress）和Content-Type（例如，x-application / x-gzip）听起来相似，  但实际上它们是两条截然不同的信息。服务器使用 Content-Type  指定实体主体的数据类型，这对于想要使用适当的应用程序打开内容的客户端应用程序非常有用，  Content-Encoding  仅用于指定服务器之前执行的任何其他编码内容已传输到客户端。虽然HTTP RFC非常清楚地概述了这些规则，但是一些网站使用“gzip”作为内容编码进行响应，即使服务器没有对内容进行解压缩。

我们的测试表明这个问题仅限于一些提供Unix / Linux风格“tarball”文件的站点。Tarball是gzip压缩档案文件。通过在tarball上将Content-Encoding标头设置为“gzip”，服务器指定它还附加了gzip压缩文件。当然，这不太可能，但不是不可能或不合规。

这就是问题所在。使用内容编码进行响应的服务器（例如“gzip”）指定了客户端为解压缩内容所需的必要机制。如果服务器实际上没有按指定编码内容，则客户端的解压缩将失败。

当一个实体主体包含在消息中时，它的数据类型 body通过标题字段Content-Type和Content-确定编码。这些定义了一个两层有序编码模型：
entity-body：=内容编码（内容类型（数据））
Content-Type指定基础数据的媒体类型。
内容编码可用于指示任何附加内容编码应用于数据，通常用于数据目的压缩，它是所请求资源的属性。有没有默认编码。

包含实体主体的任何HTTP / 1.1消息都应该包含一个Content-Type标头字段，用于定义该主体的媒体类型。如果并且只有当Content-Type字段没有给出媒体类型时，收件人可以尝试通过检查媒体类型来猜测媒体类型用于标识的URI的内容和/或名称扩展名资源。如果媒体类型仍然未知，则收件人应该将其视为“application / octet-stream”类型。