#?SuikaWiki/0.9 page-icon="HTTP" [4] [[HTTP]] で[[実体]]に対してどんな[[内容符号化]]が施されているのかを示すのが、 [DFN[[CODE(HTTP)[Content-Encoding:]] 欄]]です。 この欄は名前こそ [CODE[Content-]] がつきますが、 [[MIME]] では規定されておらず、 HTTP 独自のものです。 [2] 内容符号化は MIME の[[内容転送符号化]]や HTTP の[[転送符号化]]よりも上 (データ側) の層に当たります。 MIME への[[関門]]では[[媒体型]]の指定に変換することが良いとされています。 (例: HTTP: [SAMP(HTTP)[Content-Encoding: gzip]] → MIME: [SAMP(HTTP)[Content-Type: [[application/x-gzip]]]]) - [9] [CODE(HTTP)[Content-Encoding: gzip]] かつ [CODE(HTTP)[[[Content-Type:]] application/x-gzip]] で送ってくるサーバーがありますが、ほとんど間違いなく間違いなので(謎)、止めた方がいいですね。 --[10] >>9 の問題の原因は実は [[Apache]] を [[distro]] 配布の [[RPM]] で入れたりした場合に、システム共用の [CODE(file)[[[/etc]]/[[mime.types]]]] が使われて、そのファイルに [CODE[application/x-gzip .gz]] って書いてある、って話だったりします。ちょっと困ったもんです。 [[#comment]] *値 →[[内容転送符号化]>>1]参照。 *RFC 2616 の3.5 Content Codings Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient. -content-coding = token All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding (section 14.11) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding. The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens: gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. ファイル圧縮プログラム「gzip」(GNU zip) で生成される符号化形式で、 RFC 1952 で説明されているもの。この形式は Lempel-Ziv 符号化 (LZ77) と 32ビット [[CRC]] を使っています。 compress The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch coding (LZW). 共通 UNIX ファイル圧縮プログラム「compress」で生成される符号化形式。 この形式は Lempel-Ziv-Welch 符号化 (LZW) の一応用です。 Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. 符号化形式にプログラム名を使うのは望ましいことではなく、 将来の符号化方式には推奨されません。ここで使っているのは 歴史的習慣表現であって、良い設計とはいえません。 HTTP の古い実装との互換性のため、応用は "x-gzip" と "x-compress" をそれぞれ "gzip" および "compress" と同様に解釈するのが '''望ましい'''です。 deflate The "zlib" format defined in RFC 1950 [31] in combination with the "deflate" compression mechanism described in RFC 1951 [29]. RFC 1950 で定義された「zlib」形式と RFC 1951 で説明されている 「deflate」 (収縮) 形式を組み合わせたものです。 identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header. 規定 (同等) 符号化方式。無変形に使います。この内容符号化は Accept-Encoding (承認符号化方式) 頭にのみ使われ、 Content-Encoding (内容符号化方式) 頭に使う'''べきではありません'''。 New content-coding value tokens SHOULD be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new value SHOULD be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section. *HTTP/1.0 (RFC 1945) から抜粋 content-coding = "x-gzip" | "x-compress" | token Note: For future compatibility, HTTP/1.0 applications should consider "gzip" and "compress" to be equivalent to "x-gzip" and "x-compress", respectively. * RFC の部分の License [[RFCのライセンス]] *メモ