RFC1945(HTTP)中文版(14)

HTTP是应用级协议,它适应了分布式超媒体协作系统对灵活性及速度的要求。它是一个一般的、无状态的、基于对象的协议,通过对其请求方法(request methods)进行扩展,可以被用于多种用途,比如命名服务器(name server)及分布式对象管理系统。 HTTP 的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。 HTTP 自从 1990 年就在 WWW 上被广泛使用。该规范反映了“HTTP/1.0”的普通用

3.4 字符集（Character Sets）

HTTP所使用的字符集定义和描述MIME时用的相同：本文档用字符集（character set）来指明利用一个或多个表将顺序字节转换成顺序字符的方法。注意，不需要其它方向的无条件转换，因为不是所有的字符都可以用给定字符集来表示，同时，一个字符集也可能提供一种以上的字节顺序来表示一种特殊的字符。这种定义倾向于允许不同类型的字符编码通过简单的单表映射来实现，如，从表US-ASCII切换到复杂表如ISO2202。实际上，与MIME字符集名相关的定义必须完整指定从字节到字符的映射，特别是不允许通过利用外部配置信息来确定精确的映射。

注意：术语字符集（character set）归于字符编码（character encoding）。事实上，由于HTTP与MIME共同使用同样的注册，所以其术语也应一致。

HTTP字符集由大小写敏感的符号组成。全部的符号定义参见IANA字符集注册[15]。因为注册处不会为每个字符集单独定义一套符号，所以我们在这看到的字符集名大多是与HTTP实体使用相关的。这些在RFC 1521 [5] 中注册的字符集，即US-ASCII [17] 及ISO-8859 [18]字符集，还有一些其它字符集被强烈建议在MIME字符集参数内部使用。

charset = "US-ASCII"

| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"

| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"

| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"

| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"

| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" | token

虽然HTTP允许使用专用符号做为字符集值，但是任何在IANA字符集注册表[15]中有预定义值的符号都必须表明其所属的字符集。应用应当将其对字符集的使用限制在IANA注册表规定的范围之内。

实体主体的字符集如果属于US-ASCII 或ISO-8859-1字符集，则勿需标记，否则，应当用主体字符编码方式中的最基本命名来标记。

3.5 内容译码（Content Codings）

内容译码值用于指示对资源进行的编码转换。内容译码主要用于将经过压缩、加密等操作的文件进行还原，使其保持其原来的介质类型。典型情况下，经过编码保存的资源只能经过解码或类似的操作才能还原。

content-coding = "x-gzip" | "x-compress" | token

注意：出于对未来兼容性的考虑，HTTP/1.0应用应将"gzip" 和"compress" 分别与 "x-gzip"和"x-compress"对应起来。

所有的内容译码值都是大小写敏感的。HTTP/1.0在内容编码（10.3节）头域中使用内 容译码值。虽然该值描述的是内容译码，但更为重要的是，它指明了应当用什么机制来进行 解码。注意，单独的程序可能有能力实现对多种格式编码的解码。

在这段文字中，提到了两个值：

x-gzip 文件压缩程序"gzip" (GNU zip，由Jean-loup Gailly开发)的编码格式。该格式属于典型的带有32位CRC 校验的Lempel-Ziv译码 (LZ77)。