[14] [DFN[[CODE(MIME)[[[Content-Type:]]]]]] [[ヘッダー]]は、 対応するデータの型 ([[MIME型]]) を指定するものです。 [878] 現在用いられている [CODE(MIME)@en[[[Content-Type:]]]] の仕組みは、はじめ [[MIME]] で[[電子メール]]のために導入され、その後 [[HTTP]] など色々な[[プロトコル]]でも採用されたものです。 * 仕様書 [REFS[ - [47] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) - [877] '''[CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) ''' - [891] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) - [892] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) - [40] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [36] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) -- [31] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [42] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) - [44] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) - [58] [CITE@en-US-x-hixie[HTML Standard]] ([TIME[2017-05-05 18:17:33 +09:00]]) - [80] [CITE@en[Fetch Standard]] ([TIME[2019-05-03 21:58:07 +09:00]]) ]REFS] * 意味 [879] [[HTTP]] では、関連付けられた[[表現]]の[[MIME型]]を表します。 同じ[[メッセージ]]に [[payload body]] が含まれていれば、その [[MIME型]]です。 [CODE(HTTP)@en[[[HEAD]]]] [[メソッド]]に対する[[応答]]の時は、 [CODE(HTTP)@en[[[GET]]]] [[メソッド]]だったとしたら[[応答]]に含まれるであろう[[表現]]の [[MIME型]]です。 [SRC[>>877]] [888] 実際に[[表現]]が[[メッセージ]]に含まれる場合にはその[[MIME型]]を表しますが、 [[HTTP]] [CODE(HTTP)@en[[[HEAD]]]] [[メソッド]]に対する[[応答]]では、 [CODE(HTTP)@en[[[GET]]]] だったなら返される[[表現]]の [[MIME型]]を表します。 * 文脈 [219] [[HTTP]] [CODE(HTTP)@en[[[OPTIONS]]]] [[要求]]に [[payload body]] を含める場合、 [CODE(HTTP)@en[[[Content-Type:]]]] [[ヘッダー]]を[[生成]]しなければ[['''なりません''']] [SRC[>>218]]。 [41] [[WebDAV]] [[クライアント]]からの [CODE(HTTP)@en[[[PUT]]]] [[要求]]にあっては、新しい[[資源]]の [CODE(HTTP)@en[[[Content-Type:]]]] がわかっているなら、これを指定する[['''べきです''']] [SRC[>>40]]。 [43] [[FCAST]] でも [CODE(HTTP)@en[[[Content-Type:]]]] [[HTTPヘッダー]]を使うことができます [SRC[>>42]]。 * 構文 [22] [CODE(MIME)@en[[[Content-Type:]]]] [[ヘッダー]]の値は、 [[MIME型]]です。[[引数]]を含めることもできます。 [SRC[>>877]] [881] 構文の子細は規格によって異なりますが、 おおむね次のように表せます。 - [CODE(ABNF)[[DFN[Content-Type 欄]] := "Content-Type" ":" Content-Type 欄本体]] - [CODE(ABNF)[[DFN[Content-Type 欄本体]] := 媒体型]] - [CODE(ABNF)[[DFN[媒体型]] := 型 "/" 亜型 *(";" 引数指定)]] - [CODE(ABNF)[[DFN[引数指定]] := 引数名 "=" 引数値)]] [23] 例えば [[MIME]] では、 >>881 の構文字句間に [CODE(ABNF)[[ABBR[[[LWS]]] [linear white space]]]] を挿入できます。 [CODE(ABNF)[型]]・[CODE(ABNF)[亜型]]・[CODE(ABNF)[引数名]]の大文字・ 小文字や[CODE(ABNF)[引数指定]]の順序は意味を持ちません。 [[HTTP]] は MIME とほぼ同じですが、 [CODE(ABNF)[型]]や[CODE(ABNF)[引数値]]の定義 [WEAK[(>>881 では省略しています。)]] に使われている [CODE(ABNF)[[[token]]]] の定義が少々異なります。 [34] [CODE(URI)@en[[[DAV:getcontentype]]]] [[特性]]では、 [CODE(HTTP)@en[[[Content-Type:]]]] [[ヘッダー]]の [[OWS]] や [[BWS]] を含める[['''べきではありません''']] [SRC[>>36]]。 [24] また、 MIME は [[RFC 2231]] で改訂され、 実際に[[実体]]の頭部に出現する構文で >>22 よりも複雑な指定方法が使えるようになっています。 [WEAK[(長い引数値を[[電子メイル]]で使う場合の対策や[[言語指定]]を含める手段が用意されています。)]] しかし、 [[HTTP]] など MIME から派生したプロトコルにまでこの改訂が及ぶのかどうかは曖昧になっています。 [WEAK[(HTTP のように仕様書で構文を再定義している仕様は影響しないという説が有力です。)]] @@ MIME/HTTP/CGI/RTSP/SIP/son-of-1036/Usefor の構文の差異の詳細 * 省略 @@ MIME の既定値: [CODE(MIME)@en[[[text/plain]]; [[charset]]=[[US-ASCII]]]] [48] [[本体部分]]で [CODE(MIME)@en[[[Content-Type:]]]] が指定されない場合、 [CODE(MIME)@en[[[text/plain]]; [[charset]]=[[US-ASCII]]]] を表しています [SRC[>>47]]。 [49] ただし [CODE(MIME)@en[[[multipart/digest]]]] では [CODE(MIME)@en[[[message/rfc822]]]] を表しています [SRC[>>47]]。 [882] [[HTTP]] においては、 [[payload body]] を含む[[メッセージ]]を[[生成]]する[[送信者]]は、 含まれる[[表現]]の [[MIME型]]が分からない場合を除き、 [CODE(HTTP)@en[[[Content-Type:]]]] [[ヘッダー]]を[[生成]]する[['''べきです''']] [SRC[>>877]]。 [883] [[HTTP]] においては、 [CODE(HTTP)@en[[[Content-Type:]]]] [[ヘッダー]]がなければ、[[受信者]]は [[MIME型]]が [CODE(MIME)@en[[[application/octet-stream]]]] であるとみなしても構いませんし、 [[sniffing]] しても構いません。 [SRC[>>877]] [27] [[BEEP]] における [[MIME]] [[実体]]で [CODE(MIME)@en[[[Content-Type]]:]] [[頭欄]]が省略された場合の[[既定値]]は [CODE(MIME)@en[[[application/octet-stream]]]] です。 [SRC@en[[[RFC 3080]] 2.2]] * 解釈の変え方 @@ 既定値の章と統合する [21] [[電子メイル]] ([[822]]) の [CODE(822)[Content-Type:]] 欄の規定は [[RFC 1049]] と [[MIME]] の2種類があります。両者の構文は全然違います。 同じメッセージに [CODE(822)[[[MIME-Version]]:]] 欄があれば MIME によって解釈し、なければ RFC 1049 で解釈するのが正しいそうです。 [WEAK[(という話は仕様書には載っていなくて、[[ietf-822]] かどこかでそう聞きました。)]] (もっとも、構文が全然違うのでどちらの構文も扱えるようにするのは難しくありませんし、 古いメッセージを扱わないのであれば RFC 1049 の構文は無視しても良いかもしれません。) ** 引数 [8] [CODE(MIME)[Content-Type:]] 欄には狭義の[[媒体型]]に加えて、 任意の個数の[DFN[[RUBYB[引数] [parameter]]]]を指定できます。 引数は、名前と値の組からなります。値の解釈は名前に依存します。 そして引数の解釈は、[WEAK[(狭義の)]] 媒体型に依存します。 (引数は媒体型の[[属性]]であり、 [CODE(MIME)[Content-Type:]] 欄の属性ではありません。) [11] 引数名は、大文字・小文字の区別なしで定義されています。 [[MIME]] など多くの規格では、頭欄に大文字・ 小文字どちらで書いても同じ意味です。引数名として使用できる文字は、 規格によって異なります。 MIME と [[HTTP]] では共に [CODE(ABNF)[[[token]]]] ですが、その [CODE(ABNF)[token]] の定義が両規格で異なります。現実に使われている文字は [CODE(ABNF)[token]] で使える文字の共通集合の更に小さな部分集合です。 [18] 引数値では、大文字・小文字を区別するかどうかは 引数名 [WEAK[(正確には、媒体型と引数名)]] に依存します。 例えば、 [SAMP(MIME)[[[text/plain]]]] の [SAMP(MIME)[[[charset]]]] 引数では区別しませんが、 [SAMP(MIME)[[[application/octet-stream]]]] の [SAMP(MIME)[[[name]]]] では区別します。 MIME では、引数値は [CODE(ABNF)[[[value]]]] であり、 [CODE(ABNF)[token]] または [CODE(ABNF)[[[quoted-string]]]] として定義されていますから、 前者では引数名同様の文字種しか使えませんが、後者により [[RFC 822]] で使えるすべての [ABBR[[[ASCII]]] [American Standard Code for Information Interchange]] 文字が使えます。 それでも使える文字はわずかに限られますが、 [[RFC 2231]] の方法で事実上あらゆる文字の指定が可能です。 HTTP でも [CODE(ABNF)[token]] と [CODE(ABNF)[quoted-string]] が使えますが、前述のように [CODE(ABNF)[token]] の定義は MIME と異なりますし、 [CODE(ABNF)[quoted-string]] の定義も異なります。 RFC 2231 の方法は使用できないと一般には考えられています。 MIME・HTTP 以外の規格も [CODE(ABNF)[token]] と [CODE(ABNF)[quoted-string]] が使えることが多いですが、 詳細はばらばらです。 [19] 引数は媒体型の定義と共に登録することになっています。 そのためか、電子メイルや MIME の多くの他の[Q[字句]]のような名前付けに関する規定がありません。 [WEAK[([SAMP[x-]] で始まる引数名を[[私用]]してもよいという規定もありません。)]] *** 比較的共通なパラメーター [16] >>8 の通り、引数は媒体型各々固有のものであるのが原則ですが、 必然的に、または間違いにより、 媒体型にかかわらず比較的共通に使われている引数が何種類か存在します。 ,引数名 ,説明 ,備考 ,[CODE(MIME)[[[charset]]]] ,Charset ,[CODE(MIME)[[[x-mac-creator]]]] ,作成プログラム識別子 ([[Macintosh]]) ,[CODE(MIME)[[[x-mac-type]]]] ,型 (Macintosh) ,[CODE(MIME)[[[name]]]] ,[[ファイル名]] ,[CODE(MIME)[[[Content-Disposition]]]] の [CODE(MIME)[[[filename]]]] 引数を使用する'''べき''' ,[CODE(MIME)[[[x-unix-mode]]]] ,[[アクセス権]] ([[Un|x]]) [9] [CODE(MIME)[[[charset]]]] 引数は、 MIME 本体規格でも特別に定義されている引数です。 MIME では [CODE(MIME)[[[text/[VAR[*]]]]]] で使うことを規定していますが、 他の媒体型でも同じ、または似た意味でよく使われます。 [18] [CODE(MIME)[[[name]]]] 引数は、古い MIME の規格で [CODE(MIME)[[[application/octet-stream]]]] などごく一部の媒体型に定義されていましたが、 任意の媒体型で[[ファイル名]]を指定するためのものとして間違って実装されました。 現在の MIME には [CODE(MIME)[[[Content-Disposition]]:]] 欄に [CODE(MIME)[[[filename]]]] 引数があり、最近のほとんどの [ABBR[[[UA]]] [利用者エージェント]]はそちらに移行しています。 [10] [CODE(MIME)[[[x-unix-mode]]]] は [SAMP(MIME)[0777]] のように [[Un|x]] におけるファイルの [[permission]] を指定するようです。 [[AppleMail]] などが使用していることがわかっています。 [CODE(MIME)[[[x-mac-creator]]]] と [CODE(MIME)[[[x-mac-type]]]] は、 Macintosh の[[ファイル・システム]]の属性を記述するようです。 [CODE(MIME)[[[application/applefile]>>1]]] をご覧下さい。 これら3つの引数は、本来は [CODE(MIME)[[[Content-Disposition]]:]] 欄に入れたほうが良い情報かもしれません。 [33] [[HTTP]] でも [CODE(MIME)@en[[[name]]]] [[引数]]が指定されることがあります。 ;; どうやら、 [[Bugzilla]] が[[添付ファイル]]に [CODE(MIME)@en[[[name]]]] [[引数]]で[[ファイル名]]を指定しているようです。 * 処理 [28] [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]の [CODE(MIME)@en[[[handling]]]] [[引数]]は、 [[SIP]] において未対応の[[内容型]]が指定された時の処理を指定します。 ;; [CODE(MIME)@en[[[handling]]]] を参照。 [45] [[FCAST]] の実装は、 [CODE(HTTP)@en[[[Content-Type:]]]] [[HTTP]] [[ヘッダー]]に対応しなければ[['''なりません''']] [SRC[>>44]]。 ** 指定値の決定 [57] [CODE(HTTP)@en[Content-Type:]] [[ヘッダー]]で指定された値は ([[computed MIME type]] に対して) [DFN[supplied MIME type]] と呼ばれ、 [DFN[check-for-apache-bug flag]] と共に[VAR[応答]]から [DFN[supplied MIME type detection algorithm]] で次のように決定されます [SRC[>>58]]。 [FIG(steps)[ = [62] [VAR[check-for-apache-bug flag]] を、[[偽]]に設定します。 = [60] [VAR[型]]を、[VAR[応答]]の[F[ヘッダーリスト]]の'''最後'''の [CODE(HTTP)@en[Content-Type]] [[ヘッダー]]の値に設定します。 = [59] [VAR[応答]]が[[HTTP応答]]の場合、 == [61] [VAR[型]]が次のいずれかであれば、 [VAR[check-for-apache-bug flag]] を、[[真]]に設定します。 ,* [[バイト列]] ,* [[ASCII]] として解釈した[[文字列]] ,[CODE[74 65 78 74 2F 70 6C 61 69 6E]] ,[CODE[text/plain]] ,[CODE[74 65 78 74 2F 70 6C 61 69 6E 3B 20 63 68 61 72 73 65 74 3D 49 53 4F 2D 38 38 35 39 2D 31]] ,[CODE[text/plain; charset=ISO-8859-1]] ,[CODE[74 65 78 74 2F 70 6C 61 69 6E 3B 20 63 68 61 72 73 65 74 3D 69 73 6F 2D 38 38 35 39 2D 31]] ,[CODE[text/plain; charset=iso-8859-1]] ,[CODE[74 65 78 74 2F 70 6C 61 69 6E 3B 20 63 68 61 72 73 65 74 3D 55 54 46 2D 38]] ,[CODE[text/plain; charset=UTF-8]] = [63] [VAR[型]]が非[[構文解析可能MIME型]]の場合、 == [64] [VAR[型]]と [VAR[check-for-apache-bug flag]] を返します。 = [65] それ以外の場合、 == [66] [CODE[null]] と [VAR[check-for-apache-bug flag]] を返します。 ]FIG] [67] [[ファイル]]の場合は[[ファイルシステム]]と[[プラットフォーム]]の設定から決定される [[MIME型]]になり、 [VAR[check-for-apache-bug flag]] は設定されません。 [CODE(URI)@en[data:]] の場合 [VAR[check-for-apache-bug flag]] は設定されません。 [[FTP]] の場合、[[仕様書]]には [[MIME型]]の指定があれば使う [SRC[>>58]] とありますが、実際には指定されることはないと思われます。ただし [[FTP over HTTP]] の場合は [[HTTP]] の場合同様に扱うべきと思われます。 [68] 複数の [CODE(HTTP)@en[Content-Type:]] [[ヘッダー]]が指定された場合、 常に最後のものが使われます。最初のものが非[[構文解析可能MIME型]]で最後のものが非[[構文解析可能MIME型]]であっても、最後のものが採用され、 指定なしと扱われます。 [69] [[supplied MIME type]] と [[check-for-apache-bug flag]] は、[F[算出MIME型]]の決定時に参照されます。 [92] [CITE[null]], [TIME[2025-11-14T11:24:46.000Z]] [93] >>92 [CODE[text/plain]] になってる [[HTML]] のトップページ ** 要求メッセージの処理 [893] [[要求メッセージ]]の [[MIME型]]を[[鯖]]が処理できないときは、 [CODE(HTTP)[[[415]]]] [[応答]]を返すことができます。 ** [CODE(HTMLe)@en[meta]] 要素から符号化を取り出す算法 [855] [[HTML]] では [DFN[[RUBYB[[CODE(HTMLe)@en[[[meta]]]] 要素から符号化を取り出す算法]@en[algorithm for extracting an encoding from a [CODE(HTMLe)@en[[[meta]]]] element]]]]が定義されており、 [CODE(HTMLe)@en[[[meta]]]] [[要素]]の [CODE(HTMLa)@en[[[http-equiv]]]] [[属性]]が [CODE(HTTP)@en[[[Content-Type]]]] の時に[[文字符号化]] ([[charset]]) の値を取り出す時に使われます。 [REFS[ - [856] [CITE@en-US-x-hixie[HTML Standard]] ([TIME[2012-02-22 20:11:59 +09:00]] 版) ]REFS] [857] 元々の [[HTTP]] の [CODE(HTTP)@en[[[Content-Type:]]]] 欄の構文と [[HTML]] の [CODE(HTMLe)@en[[[meta]]]] [[要素]]の構文には細かな違いがあり、この[[算法]]は [[HTML]] の構文に特化しています。 ** 実装 [[#comment]] *** パラメーター不認識問題 [1] 主に古い時代の [[HTTP]] [[UA]] において、パラメーターの存在を知らないためにうまく扱えないことがあります。 単に無視するだけならまだ良いのですが、中にはパラメーターも含めて一つの[[媒体型]]とみなし、例えば [CODE[text/html;charset=iso-2022-jp]] という媒体型と認識し、保存しますか? と聞いてきたりします。 [2] [[Mosaic]] variant にこういうのがいるみたいです。 古い Mosaic は対応していなかったんでしょうか? 同じ 1996年の Mosaic でも、 MosaicView ([[NEC]]) はちゃんと扱えるのに Infomosaic ([[富士通]]) は扱えなかったりします。 [3] ちなみに、古い [[NN]] (2以前) は [[charsetパラメーター]]の扱いにまた別の問題があります。 - [12] 古い [[UA]] には、 [SAMP[text/html;charset=iso-2022-jp]] ではなく [SAMP[text/html; charset=iso-2022-jp]] になっていないと認識しない困ったちゃんがいるらしいです。 - [13] [[application/x-www-form-urlencoded]>>1] にも同様の問題が存在します。おそらく潜在的に少なからぬ数の [[UA]] (おそらく大多数は特定目的の tool か古代の [[WWW]] ブラウザ。) が、パラメータの存在により誤動作又は動作しなくなる虞があります。 [[#comment]] ** 歴史 [15] 初め [[RFC 1049]] が定義していましたが、これと互換性のない [ABBR[[[MIME]]] [Multipurpose Internet Mail Extensions]] が再定義した形式が普及し、 [ABBR[[[HTTP]]] [Hypertext Transfer Protocol]] など他のプロトコルでも採用されています。 RFC 1049 の CT: は MIME の CT: とは互換性がありません。 また、 1049 の型の全てに対応する Internet (MIME) 媒体型が 定義されたわけでもありません。 幾ら RFC 1049 が実際にはあまり使われなかったとはいえ、 ひどい処遇です。 son-of-RFC1036 は RFC 1341 を参照していて、別途 CT: 領域を定義していません。 usefor-article もそうです。 HTTP の定義は RFC 2045 と同じ物ですが、 RFC 2231 の拡張に 追随していません。 CGI の定義は HTTP と同じです。 [[MIME//parameter値拡張]] RFC 2184, RFC 2231 により Content-Type: 領域の parameter の定義などが 修訂されました。実際にはあまり実装されていません。 [[#comment]] ** 関連 [25] [[XML]] で[[要素]]の[[内容]]として [[Base16]] または [[Base64]] で含められたものの[[媒体型]]を記述するための [CODE(XMLa)[[QN[xmlmime:[[contentType]]] [http://www.w3.org/2005/05/xmlmime]]]] [[属性]]があります。取り得る値は [[RFC 2045]] ([[MIME]]) の [CODE(MIME)[[[Content-Type]]:]] 欄本体と同じです。 (特に注記がないから [CODE(ABNF)[[[LFWS]]]] も認められるのか!?) [CITE[Describing Media Content of Binary Data in XML]] @@ [CODE(SGML)@en[%[[ContentType]];]] [[#comment]] ** メモ - [1] [WEAK[2002-11-15 (金) 17:27]] ''[[名無しさん]]'': RFC 1049 は (MIME が出たかなり後まで) Internet Standard でしたが、いつのまにか histrical に降格していました。 - [2] [[MIME]] では Content-Type: 欄の[[本体]]の値が[[媒体型]]です。 - [3] >>2 より媒体型のことを Content-Type あるいは内容型と呼ぶことがあります。まあ間違いではありません。好んでそう呼ぶ人も中にはいます。 - [17] [WEAK[2003-10-10 00:54:11 +00:00]] ''[[名無しさん]]'': で41位、日本語2位。最近この WikiPage 読む人が多いのはそのせいか。 [20] [CITE[Microsoft Windows XP Service Pack 2 での機能の変更点 : ブラウズのセキュリティ強化]] [ABBR[[[WinIE]]] [[[Internet Explorer]] ([[Windows]] 版)]] の型判別の仕様が変更されたそうです。相変わらず [CODE(HTTP)[Content-Type]] 以外の情報を使うようですが、以前より幾分ましにはなっている模様。 [26] [CITE[Re: Approved TAG finding: Authoritative Metadata from Ian Hickson on 2006-08-09 (www-tag@w3.org from August 2006)]] [29] [CITE[html5/cts/]] ([CODE[2007-09-22 11:17:46 +09:00]] 版) ([[名無しさん]]) [30] [CITE[プロフネット]] ([CODE[2007-11-18 14:32:36 +09:00]] 版) > [PRE(HTTP illegal example code)[ Content-Type: text/html; charset=Shift_JIS lang=ja ]PRE] ([[名無しさん]]) [32] [CITE[Bug 385166 – Gecko applies style sheets with Content-Type:"null" in standards mode]] ([CODE[2008-01-07 19:33:34 +09:00]] 版) [823] @@ Content-Encoding, Content-Transfer-Encoding との関連 @@ 拡張子、 [[HFS]] type との関係 * メタ変数 [CODE(CGI)@en[CONTENT_TYPE]] (CGI) [824] [[CGI]] の[[メタ変数]] [DFN[[CODE(CGI)@en[[[CONTENT_TYPE]]]]]] は、 [RUBYB[[[メッセージ本体]]]@en[message-body]]の[[MIME型]]を表します [SRC[>>835]]。 [[HTTP]] などの [CODE(HTTP)@en[[[Content-Type:]]]] [[欄]]に相当します。 ** 仕様書 [REFS[ - [853] [CITE@en[RFC 3875 - The Common Gateway Interface (CGI) Version 1.1]] -- [835] '''''' -- [852] ]REFS] ** 値 *** 構文 [832] [[メタ変数]] [CODE(CGI)@en[[[CONTENT_TYPE]]]] に値が設定される場合の構文は [[HTTP]] の [CODE(HTTP)@en[[[Content-Type:]]]] [[頭欄]]の構文と同じです。 [FIG[ [836] [PRE(ABNF code)[ CONTENT_TYPE = "" | media-type media-type = type "/" subtype *( ";" parameter ) type = token subtype = token parameter = attribute "=" value attribute = token value = token | quoted-string ]PRE] [FIGCAPTION[ [SRC[>>835]] ]FIGCAPTION] ]FIG] [837] [[RFC]] では構文は >>836 のように定義されています。これは [[RFC 2616]] の [[HTTP]] の定義と一致しているのですが、 [[HTTP]] の [[RFC]] とは違って [[LWS]] の挿入箇所は明記されてません。 ;; [838] 現実には挿入される可能性があるので、仕様書の誤りだと思います。 [839] 値の意味は [[RFC 2616]] に依るとされています [SRC[>>835]]。 *** 既定値 [840] [CODE(CGI)@en[[[CONTENT_TYPE]]]] の[[既定値]]はありません。[[CGIスクリプト]]は値が設定されていない場合、 その場合に限って[[MIME型]]を受信したデータから推測して[['''構いません''']]。それでも不明な場合にあっては [CODE(MIME)@en[[[application/octet-stream]]]] として扱っても構いませんし、[[誤り]]としても構いません。 [SRC[>>835]] [841] 指定されている場合であっても、 [CODE(MIME)@en[[[charset]]]] [[引数]]については[[既定値]]が定義されています。 *** 値の設定 [842] [[鯖]]は、 [[HTTP]] [[要求]]に [CODE(HTTP)@en[[[Content-Type:]]]] [[欄]]が含まれている場合、 それを設定しなければ[['''なりません''']]。 [[クライアント]]が指定しなかった場合は[[鯖]]が推定しても[['''構いません''']]。 そうでない場合は設定しないべきです。 [SRC[>>835]] ** 処理モデル [851] [[スクリプト]]は [CODE(CGI)@en[[[CONTENT_TYPE]]]] が値を持たないときは [CODE(HTTP)[[[415]]]] [[応答]]により拒絶することができます。 [SRC[>>852]] ** 実装 [825] [[CGIスクリプト]]は [CODE(CGI)@en[[[CONTENT_TYPE]]]] を [[HTTP]] 仕様にのっとり正しく処理していないことがよくあります。具体的には、 - [826] そもそも [CODE(CGI)@en[[[CONTENT_TYPE]]]] をチェックせずに常に [CODE(MIME)@en[[[application/x-www-form-urlencoded]]]] [WEAK[(など特定の[[MIME型]])]] であると仮定する - [827] [[引数]]の存在を考慮せず、[[完全一致]]で特定の[[MIME型]]か検査する - [828] [[大文字・小文字を区別しない]]部分を考慮せず、[[小文字]]のみ受け付ける - [829] [[引数]]のまわりなど [CODE(ABNF)@en[[[LWS]]]] が認められている場所で、 [CODE(charname)@en[[[SP]]]] 1個だけなど特定のパターンのみ受け付ける ... というような実装があります。 [830] [[Perl]] でよく使われる [[CGI.pm]] は[[MIME型]]が[[小文字]]で指定されていると仮定しています。 [843] [CODE(MIME)@en[[[application/x-www-form-urlencoded]]; [[charset]]=[[utf-8]]]] のように[[引数]]が指定されていると正しく扱えない [[CGIスクリプト]]も昔はよくありましたが、最近は一部の[[Webブラウザー]]が[[引数]]をつけるようになったため、 正しく扱えるものが多くなっています。 ** 関連 [831] [[HTTP]] [[要求]]に含まれている[[頭欄]]は原則的に[[メタ変数]] [CODE(CGI)@en[[[HTTP_*]]]] として [[CGIスクリプト]]に渡されますが、 [CODE(HTTP)@en[[[Content-Type]]]] → [CODE(CGI)@en[[[CONTENT_TYPE]]]] は例外となっています。これは [CODE(CGI)@en[[[HTTP_*]]]] が存在しなかった [[CGI/1.0]] 時代の仕様に由来します。 ** メモ [10] [[HTTP]] では [[Content-Type:欄]]の既定値は [CODE[text/plain; charset=iso-8859-1]] なんだが、 [[CGI]] ではこの既定値は採用しないってことか。 * [CODE(HTTP)@en[Content-Type:]] 欄 (CGI) [844] [[CGI]] の [DFN[[CODE(HTTP)@en[[[Content-Type:]]]] [[欄]]]]は、[[応答本体]]の[[MIME型]]を表します。 ** 仕様書 [REFS[ - [845] [CITE@en[RFC 3875 - The Common Gateway Interface (CGI) Version 1.1]] ([TIME[2011-11-20 06:09:05 +09:00]] 版) ]REFS] ** 構文 [846] この欄の構文は次のように定義されています [SRC[>>845]]。 [PRE(ABNF code)[ Content-Type = "Content-Type:" media-type NL ]PRE] [847] [CODE(ABNF)@en[[[media-type]]]] の前には[[空白]]を挿入できます。 [CODE(ABNF)@en[[[media-type]]]] は >>832 で定義されています。 [848] [[CGI応答]]が[[応答本体]]を含む場合、 [CODE(HTTP)@en[[[Content-Type:]]]] 欄は[['''必須''']]です。それが含まれていない場合、[[鯖]]は[[MIME型]]を勝手に推定する[['''べきではありません''']]。 指定されている場合であっても、 [CODE(MIME)@en[[[charset]]]] [[引数]]を除き、 変更せずに[[クライアント]]に送信する[['''べきです''']]。 [SRC[>>845]] ;; [850] [CODE(MIME)@en[[[charset]]]] の項も参照。 [849] [[局所リダイレクト応答]]では [CODE(HTTP)@en[[[Content-Type:]]]] 欄を指定できません。 * MIME Sniffing [876] [[MIME型]]が [CODE(MIME)@en[[[Content-Type:]]]] [[ヘッダー]]によって指定されていない場合や、 指定されていても特定の条件をみたす場合には、本体データのバイト列を検査して、 それによって [[MIME型]]を決定することがあります。これを [[MIME Sniffing]] といいます。 ;; 詳細は [[MIME Sniffing]] の項を参照してください。 * Content-Type メタデータ ** Content-Type メタデータが無視される場面 - @@ [[HTML5]] で[[探知型]]が使われる場面 - [[XSLT]] [CODE(XPathf)@en[[[document()]]]] [[関数]] (常に [[XML]] として解釈される) - @@ [[XInclude]] * [CODE(URI)@en[DAV:getcontenttype]] 特性 (WebDAV) [35] [DFN[[CODE(URI)@en[[[DAV:getcontenttype]]]]]] [[特性]]は、 [[accept header]] なしで [CODE(HTTP)@en[[[GET]]]] した時に返されるである [CODE(HTTP)@en[[[Content-Type:]]]] [[ヘッダー]]の値を表します [SRC[>>31]]。 [37] [[鯖]]が自身で[[MIME型]]を割り当てるのであれば、[[保護特性]]となります [SRC[>>31]]。 [38] [CODE(HTTP)@en[[[COPY]]]] や [CODE(HTTP)@en[[[MOVE]]]] でも[[特性]]の値を保持する[['''べきです''']] [SRC[>>31]]。 [39] [CODE(HTTP)@en[[[GET]]]] に対する[[応答]]で [CODE(HTTP)@en[[[Content-Type:]]]] [[ヘッダー]]を返す [[WebDAV]] に従う[[資源]]は、この[[特性]]を定義しなければ[['''なりません''']] [SRC[>>31]]。 * 関連 [880] [CODE(HTTP)@en[[[Content-Type:]]]] によって記述された[[MIME型]]は、 [CODE(HTTP)@en[[[Content-Encoding:]]]] によって指定された[[内容符号化]]が適用されている場合は、 それを[[復号]]した後のデータに関するものです [SRC[>>877]]。 [CODE(HTTP)@en[[[Transfer-Encoding:]]]] によって指定された[[転送符号化]]が適用されている場合は、 それも[[復号]]した後に[[内容符号化]]を[[復号]]したデータに関するものです。 [885] [CODE(DOMi)@en[[[Document]]]] [[オブジェクト]]においては、 [CODE(DOMa)@en[[[contentType]]]] [[属性]]が [CODE(MIME)@en[[[Content-Type:]]]] [[ヘッダー]]に相当します。 [886] [[内容折衝]]においては、 [CODE(HTTP)@en[[[Accept:]]]] [[ヘッダー]]が期待する[[表現]]の [[MIME型]]、すなわち [CODE(MIME)@en[[[Content-Type:]]]] [[ヘッダー]]を指定します。 [887] [[HTML]] などの[[リンク]]系の[[属性]]にある [CODE(HTMLa)@en[[[type]]]] [[属性]]は、リンク先の [CODE(MIME)@en[[[Content-Type]]]] に相当するものですが、 [[ヒント]]であって、実際の[[資源]]の[[MIME型]]としては使われません。 * 歴史 ** RFC 1049 [FIG(quote)[ *3. The Content-type Header Field Whatever structuring technique is specified by the Content-type field, it must be known precisely to both the sender and the recipient of the message in order for the message to be properly interpreted. In general, this means that the allowed parameter values for the Content-type: field must identify a well-defined, standardized, document structuring technique. We do not preclude, however, the use of a Content-type: parameter value to specify a private structuring technique known only to the sender and the recipient. More precisely, we propose that the Content-type: header field consist of up to four parameter values. The first, or type parameter names the structuring technique; the second, optional, parameter is a version number, ver-num, which indicates a particular version or revision of the standardized structuring technique. The third parameter is a resource reference, resource-ref, which may indicate a standard database of information to be used in interpreting the structured document. The last parameter is a comment. In the Extended Backus Naur Form of RFC-822, we have: Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment] **3.1. Type Values Initially, the type parameter would be limited to the following set of values: type:= "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/ "DVI"/"X-"atom These values are not case sensitive. POSTSCRIPT, Postscript, and POStscriPT are all equivalent. POSTSCRIPT Indicates the enclosed document consists of information encoded using the Postscript Page Definition Language developed by Adobe Systems, Inc. [1] SCRIBE Indicates the document contains embedded formatting information according to the syntax used by the Scribe document formatting language distributed by the Unilogic Corporation. [6] SGML Indicates the document contains structuring information to according the rules specified for the Standard Generalized Markup Language, IS 8879, as published by the International Organization for Standardization. [3] Documents structured according to the ISO DIS 8613--Office Docment Architecture and Interchange Format--may also be encoded using SGML syntax. TEX Indicates the document contains embedded formatting information according to the syntax of the TEX document production language. [4] TROFF Indicates the document contains embedded formatting information according to the syntax specified for the TROFF formatting package developed by AT&T Bell Laboratories. [5] DVI Indicates the document contains information according to the device independent file format produced by TROFF or TEX. "X-"atom Any type value beginning with the characters "X-" is a private value. **3.2. Version Number Since standard structuring techniques in fact evolve over time, we leave room for specifying a version number for the content type. Valid values will depend upon the type parameter. ver-num:= local-part In particular, we have the following valid values: For type=POSTSCRIPT ver-num:= "1.0"/"2.0"/"null" For type=SCRIBE ver-num:= "3"/"4"/"5"/"null" For type=SGML ver-num:="IS.8879.1986"/"null" **3.3. Resource Reference resource-ref:= local-part As Apple has demonstrated with their implementation of the Laserwriter, a very general document structuring technique can be made more efficient by defining a set of macros or other similar resources to be used in interpreting any transmitted stream. The Macintosh transmits a LaserPrep file to the Laserwriter containing font and macro definitions which can be called upon by subsequent documents. The result is that documents as sent to the Laserwriter are considerably more compact than if they had to include the LaserPrep file each time. The Resource Reference parameter allows specification of a well known resource, such as a LaserPrep file, which should be used by the receiving system when processing the message. Resource references could also include macro packages for use with TEX or references to preprocessors such as eqn and tbl for use with troff. Allowed values will vary according to the type parameter. In particular, we propose the following values: For type = POSTSCRIPT resource-ref:= "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/ "laserprep4.0"/local-part For type = TROFF resource-ref:= "eqn"/"tbl"/"me"/local-part **3.4. Comment The comment field can be any additional comment text the user desires. Comments are enclosed in parentheses as specified in RFC-822. ]FIG] ***拡張型 RFC 1049 に定義されていない型は IANA に登録申請できることになっていますが、 現在 IANA 登録簿でそれらしいものはありません。 ***非標準型 「text」型が使われていたようです(CT:省略時の既定値)。 = text/plain IETF のメイル・サーバー は、 未だに Content-Type: text のメッセージを返してきます。 古い [[ML]] の archive とかには、大量の text 型のがあったりします。 (そういうメッセージは [[Content-Length:欄]]を持ってたりもします。 RFC 1049 ではないかもしれません。) 「x-uuencode-apple-single」型。中身は uuencoded Macintosh binary (未対応読者への注釈つき)っぽい。 「x-be2」。古い版の Andrew System で使われていたと、 RFC 2046 だったかに 書いてありました。 Google で探してみると、古い archive から幾つか 実例が見つかります。 Andrew Mail System の古い版とやらもどっか 探したら出て来ますかね? この他にも、幾つかの型が使われていたっぽい形跡はありますが、 まとまった文書は見当りません。 ***現行(MIME) Internet 媒体型の対応 [[RFC1049とInternet媒体型の対応]] ちなみに RFC 2049 によりますと、 MIME の CT: 定義的に不正な 値は MIME 適合 UA は [[application/octet-stream媒体型]]として 取り扱います。 ** RFC 2045 [866] [[電子メイル]]で使われる [[Content-Type:欄]]の最新の定義は、 [[MIME]] [[RFC]]s の1つ目、 [[RFC2045]] にあります。 [FIG(quote)[ * RFC 2045 5. Content-Type Header Field > The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type. Content-Type (内容型) 欄の目的は、受信した[[利用者エージェント]]が適切なエージェントやデータを利用者に提示する方法を選ぶか、その他適切な方法でデータを処理するのに十に分なだけ[[本体]]のデータを説明することにあります。この欄の値は[[媒体型]]と呼びます。 > HISTORICAL NOTE: The Content-Type header field was first defined in RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one that is largely compatible with the mechanism given here. 歴史について: CT 頭欄は最初 RFC 1049 で定義されました。 RFC 1049 はより簡単であまり強力ではない構文でしたが、これはここに示す仕組みとかなり互換性があります。 [INS[ [868] 訳注: ほんとか? と思ったら、 [[RFC1049のContent-Type:領域の定義]]を参照。 ]INS] > The Content-Type header field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation. The ordering of parameters is not significant. [PRE[ In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of text, but not for unrecognized subtypes of image or audio. For this reason, registered subtypes of text, image, audio, and video should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types. ]PRE] [PRE[ Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining content type or subtype or they may be optional. MIME implementations must ignore any parameters whose names they do not recognize. ]PRE] [PRE[ For example, the "charset" parameter is applicable to any subtype of "text", while the "boundary" parameter is required for any subtype of the "multipart" media type. ]PRE] [PRE[ There are NO globally-meaningful parameters that apply to all media types. Truly global mechanisms are best addressed, in the MIME model, by the definition of additional Content-* header fields. ]PRE] [PRE[ An initial set of seven top-level media types is defined in RFC 2046. Five of these are discrete types whose content is essentially opaque as far as MIME processing is concerned. The remaining two are composite types whose contents require additional handling by MIME processors. ]PRE] [PRE[ This set of top-level media types is intended to be substantially complete. It is expected that additions to the larger set of supported types can generally be accomplished by the creation of new subtypes of these initial types. In the future, more top-level types may be defined only by a standards-track extension to this standard. If another top-level type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid a potential conflict with a future official name. ]PRE] ** 5.1. Syntax of the Content-Type Header Field ** 5.1. Content-Type 頭領域の構文 In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows: RFC 822 の拡張 BNF 記法により、 Content-Type 頭領域値は 次のように定義します。 [PRE[ content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. ]PRE] ; 媒体型及び亜型の照合は''常に''大文字・小文字を区別しません。 [PRE[ type := discrete-type / composite-type ]PRE] [PRE[ discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token ]PRE] [PRE[ composite-type := "message" / "multipart" / extension-token ]PRE] [PRE[ extension-token := ietf-token / x-token ]PRE] [PRE[ ietf-token := ]PRE] ; <標準化過程 RFC で定義され、 IANA に登録された拡張 token> [PRE[ x-token := ]PRE] ; <2文字「X-」または「x-」に、空白間隔を挟まずに続く token> [PRE[ subtype := extension-token / iana-token ]PRE] [PRE[ iana-token := ]PRE] ; <公式に定義された拡張 token。この形式の token は RFC 2048 で規定された 通りに IANA に登録されなければならない。> [PRE[ parameter := attribute "=" value ]PRE] [PRE[ attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. ]PRE] ; 属性の照合は''常に''大文字・小文字を区別しない。 [PRE[ value := token / quoted-string ]PRE] [PRE[ token := 1* ]PRE] [PRE[ tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values ]PRE] ; parameter value 内で使うには常に quoted-string 内でなければならない Note that the definition of "tspecials" is the same as the RFC 822 definition of "specials" with the addition of the three characters "/", "?", and "=", and the removal of ".". なお、「tspecials」の定義は RFC 822 の「specials」定義から 3文字 "/", "?", "=" を加えて「.」を除いたものです。 Note also that a subtype specification is MANDATORY -- it may not be omitted from a Content-Type header field. As such, there are no default subtypes. また、 subtype 指定は''絶対必要''です。 Content-Type 頭領域から 省略してはいけません。ですから、規定の亜型はありません。 The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent top-level media types. Parameter values are normally case sensitive, but sometimes are interpreted in a case-insensitive fashion, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the "access-type" parameter for message/External-body is not case-sensitive.) type, subtype, parameter 名は大文字・小文字を区別しません。 例えば、 TEXT, Text, TeXt は全て同じ上位媒体型です。 parameter 値は一般に大文字・小文字を区別しますが、 その用途により区別せずに解釈されることもあります。 (例えば、 multipart 区切りは大文字・小文字を区別しますが、 message/External-body の「access-type」 parameter は 区別しません。) Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. Thus the following two forms なお、引用符で囲まれた文字列の parameter の値は引用符を含みません。 これは、 quoted-string の引用符は parameter の value の一部ではなく、 単に parameter value の区切りとして使われているということです。 更に、 RFC 822 の構造化頭領域の規則に則り注釈を入れることが出来ます。 従って次の2例は完全に同等です。 [PRE[ Content-type: text/plain; charset=us-ascii (Plain text) ]PRE] [PRE[ Content-type: text/plain; charset="us-ascii" ]PRE] are completely equivalent. Beyond this syntax, the only syntactic constraint on the definition of subtype names is the desire that their uses must not conflict. That is, it would be undesirable to have two different communities using "Content-Type: application/foobar" to mean two different things. The process of defining new media subtypes, then, is not intended to be a mechanism for imposing restrictions, but simply a mechanism for publicizing their definition and usage. There are, therefore, two acceptable mechanisms for defining new media subtypes: [PRE[ (1) Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized. ]PRE] [PRE[ (2) New standard values should be registered with IANA as described in RFC 2048. ]PRE] [PRE[ The second document in this set, RFC 2046, defines the initial set of media types for MIME. ]PRE] ** 5.2. Content-Type Defaults Content-Type 既定値 > Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as: MIME CT 頭がない既定の RFC 822 メッセージはこのプロトコルでは US-ASCII [[文字集合]]の[[平文]]とみなされ、陽に示すと次のようになります。 >> Content-type: text/plain; charset=us-ascii > This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. In the presence of a MIME-Version header field and the absence of any Content-Type header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. Plain US-ASCII text may still be assumed in the absence of a MIME-Version or the presence of an syntactically invalid Content-Type header field, but the sender's intent might have been otherwise. この既定値は CT 頭欄が指定されていない時に仮定されます。構文的に不正な CT 頭欄が現れた時にもこの既定値を仮定することを推奨します。 MIME-Version 頭欄があって CT 頭欄がない時は、受信した[[利用者エージェント]]は US-ASCII の平文が送信者の意図であるとも仮定出来ます。 MIME-Version 頭欄がないか構文的に不正な CT 頭欄があるときにも US-ASCII の平文を依然仮定して構いませんが、送信者の意図は違ったかもしれません。 [INS[ [867] 訳注: Draft でない現在の [[MIME]] にとって RFC 1049 の CT: 欄というのは[CODE[構文的に不正]]なんだけど、それを [[US-ASCII]] 平文と解釈するんじゃあ、 >>868 と言ってることが矛盾していませんか。 ]INS] ]FIG] [869] この定義は [[RFC 1521]] の改訂版です。 (でもほとんど同じです。) [[RFC2231]] で更に改訂されています。 ** usefor [FIG(quote)[ [FIGCAPTION[ [872] draft 05 6.21.2. Content-Type ]FIGCAPTION] The Content-Type: "text/plain" is the default type for any news article, but the recommendations and limits on line lengths set out in section 4.5 Ought to be observed The acceptability of other subtypes of Content-Type: "text" (such as "text/html") is a matter of policy (see 1.1), and posters Ought Not to use them unless established policy or custom in the particular hierarchies or groups involved so allows. Moreover, even in those cases, for the benefit of readers who see it only in its transmitted form, the material SHOULD be "pretty-printed" (for example by restricting its line length as above and by keeping sequences which control its layout or style separate from the meaningful text). Content-Tyoe: 「text」のほかの亜型 (「text/html」など) を認めるか は方針の問題 (1.1 参照) で、投稿者は関係する特定の階層や集団で 確立されている方針あるいは慣習の認めるところでなければ 使用する''べ''きでは''あ''りません。・・・ [PRE[ In the same way, Content-Types requiring special processing for their display, such as "application", "image", "audio", "video" and "multipart/related" are discouraged except in groups specifically intended (by policy or custom) to include them. Exceptionally, those application types defined in [RFC 1847] and [RFC 2015] and/or [RFC 2015bis] for use within "multipart/signed" articles, and the type "application/pgp-keys" (or other similar types containing digital certificates) may be used freely. ]PRE] [PRE[ Reading agents SHOULD NOT, unless explicitly configured otherwise, act automatically on Application types which could change the state of that agent (e.g. by writing or modifying files), except in the case of those prescribed for use in control messages (7.2.1.2 and 7.2.4.1). ]PRE] ]FIG] [873] 電子メイルの MIME より厳格で、どこでも適当に comment とか WSP を 入れてはいけませぬ。 ** HTTP [FIG(quote)[ [FIGCAPTION[ [874] RFC 1945 (HTTP/1.0) 10.5; RFC 2068 (HTTP/1.1) 14.18; RFC 2616 (HTTP/1.1) 14.17 Content-Type ]FIGCAPTION] >The Content-Type entity-header field indicates the media type of the [DEL[[INS[{1945}]] Entity-Body]] [INS[[INS[{2068,2616}]] entity-body]] sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. [5] Content-Type 実体頭欄は受信者に送られた, 又は [[HEAD]] 方式の場合では [[GET]] 要求の場合に送られる[[実体本体]]の[[媒体型]]を示します。 -[6] Content-Type = "Content-Type" ":" media-type >Media types are defined in section [DEL[[INS[{1945}]] 3.6]] [INS[[INS[{2068,2616}]] 3.7]]. An example of the field is -[7] Content-Type: text/html[INS[; charset=ISO-8859-4 [INS[{2068,2616}]]]] >Further discussion of methods for identifying the media type of an entity is provided in section 7.2.1. ]FIG] [FIG(quote)[ [FIGCAPTION[ [875] RFC 2326 (RTSP) 12.16 Content-Type ]FIGCAPTION] >See [H14.18]. Note that the content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types. [4] [H14.18] 参照。 [[RTSP]] に適切な内容型は実際には[[表現記述]]と引数値の型に制限されてしまうであろうことに注意してください。 ]FIG] ** CGI/1.1 Internet Draft (03) [FIG(quote)[ [89] 6.1.3. CONTENT_TYPE (CGI/1.1 draft 03) > If the request includes a message-body, CONTENT_TYPE is set to the Internet Media Type [9] of the attached entity if the type was provided via a "Content-type" field in the request header, or if the server can determine it in the absence of a supplied "Content-type" field. The syntax is the same as for the HTTP "Content-Type" header field. [[要求]]が [CODE(ABNF)@en[[[message-body]]]] を含んでいる場合、 [CODE(CGI)@en[[[CONTENT_TYPE]]]] は、 [[要求頭部]]の [CODE(HTTP)@en[[[Content-Type]]]] [[欄]]によって[[インターネット媒体型]]が指定されていればそれに設定されます。 [CODE(HTTP)@en[[[Content-Type]]]] [[欄]]が明示されていない時で[[鯖]]が[[インターネット媒体型]]を決定できるときは、 それに設定されます。[[構文]]は [[HTTP]] の [CODE(HTTP)@en[[[Content-Type]]]] [[頭欄]]のものと同じです。 > [PRE(ABNF code)[ CONTENT_TYPE = "" | media-type media-type = type "/" subtype *( ";" parameter) type = token subtype = token parameter = attribute "=" value attribute = token value = token | quoted-string ]PRE] > The type, subtype, and parameter attribute names are not case-sensitive. Parameter values MAY be case sensitive. Media types and their use in HTTP are described in section 3.7 of the HTTP/1.1 specification [8]. [[型]]、[[部分型]]、[[引数属性名]]は[[大文字・小文字を区別しません]]。 [[引数値]]は[[大文字・小文字を区別する]]'''かもしれません'''。 [[HTTP]] における[[媒体型]]とその用法は [[HTTP/1.1]] 仕様書の3.7節で説明されています。 > Example: [PRE(example code)[ application/x-www-form-urlencoded ]PRE] > There is no default value for this variable. If and only if it is unset, then the script MAY attempt to determine the media type from the data received. If the type remains unknown, then the script MAY choose to either assume a content-type of application/octet-stream or reject the request with a 415 ("Unsupported Media Type") error. See section 7.2.1.3 for more information about returning error status values. この[[変数]]の[[既定値]]はありません。この値が設定されていなければ、 また設定されていない場合に限り、[[スクリプト]]は受信データから [[媒体型]]を決定しようとしても'''[[構いません]]'''。 それでも[[型]]が未知である時は、[[スクリプト]]は[[内容型]]を [CODE(MIME)@en[[[application/octet-stream]]]] と仮定するか、 [CODE(HTTP)[[[415]]]] (「未対応の媒体型」) [[誤り]]によって[[要求]]を却下するのどちらかを選んで'''[[構いません]]'''。 [[誤り]]状態値の返却についての詳細は7.2.1.3節をご覧ください。 > Servers MUST provide this metavariable to scripts if a "Content-Type" field was present in the original request header. If the server receives a request with an attached entity but no "Content-Type" header field, it MAY attempt to determine the correct datatype, or it MAY omit this metavariable when communicating the request information to the script. [[鯖]]は、元々の[[要求頭部]]に [CODE(HTTP)@en[[[Content-Type]]]] [[頭欄]]が存在する場合、 この[[メタ変数]]を提供し[['''なければなりません''']]。 [[鯖]]は、[[添付実体]]があって [CODE(HTTP)@en[[[Content-Type]]]] [[頭欄]]がない[[要求]]を受信した場合、 正しいデータ型を決定しようと試みて[['''構いません''']]し、 [[スクリプト]]に[[要求]]情報を伝える際にこの[[メタ変数]]を省いても[['''構いません''']]。 ]FIG] [FIG(quote)[ [90] [[draft-coar-cgi-v11-03]] 7.2.1.1. Content-Type The Internet Media Type [9] of the entity body, which is to be sent unmodified to the client. 本体実体の Internet 媒体型で、そのまま編集されずにクライアントに送られます。 Content-Type = "Content-Type" ":" media-type NL This is actually an HTTP-Field rather than a CGI-Field, but it is listed here because of its importance in the CGI dialogue as a member of the "one of these is required" set of header fields. これは実際には CGI 領域というより HTTP 領域ですが、 頭領域中の「これらの一つは必須」の一つとして CGI 対話では 重要であるので、ここに列します。 ]FIG] [FIG(quote)[ [91] 関連 BNF media-type = type "/" subtype *( ";" parameter) type = token subtype = token parameter = attribute "=" value attribute = token value = token | quoted-string ]FIG] * メモ [884] [[Content-Type:]] 欄やその値のことを、 [DFN[[[CT]]]] と呼ぶこともあります。 但し [[MIME]] の文脈以外では普通通じませんし、 MIME な文脈でも最初に [SAMP[Content-Type (以下 CT)]] のように断っておかないと通じないかもしれません。 [833] [CITE@en[Working Group Decision on ISSUE-125 charset-vs-quotes]] ( ([[Sam Ruby]] 著, [TIME[2011-03-16 00:13:22 +09:00]] 版)) [834] [CITE[Apache HTTP Server Project]] ( ([TIME[2011-05-28 00:58:55 +09:00]] 版)) [854] [CITE@en-us[SOAP over Java Message Service 1.0]] ( ([TIME[2012-02-15 02:00:44 +09:00]] 版)) [862] [CITE@en[RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks]] ( ([TIME[2011-12-04 10:31:11 +09:00]] 版)) [863] [CITE@en[RFC 4975 - The Message Session Relay Protocol (MSRP)]] ( ([TIME[2012-02-26 13:20:50 +09:00]] 版)) [864] [CITE@en[RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2)]] ( ([TIME[2012-11-13 15:18:40 +09:00]] 版)) [865] [CITE@en[RFC 2660 - The Secure HyperText Transfer Protocol]] ( ([TIME[2013-07-20 22:21:48 +09:00]] 版)) [870] [SAMP(MIME)[Content-Type: text/html;]] みたいなのがたまにありますが、厳密には間違いですね。 ([[名無しさん]] [WEAK[2004-07-11 01:22:18 +00:00]]) [871] >>870 [[spam]] に多い。 ([[名無しさん]] [WEAK[2004-07-11 01:25:03 +00:00]]) [889] [CITE[Fix request and response's body story · 578768a · whatwg/fetch]] ( ([TIME[2014-06-27 02:05:41 +09:00]] 版)) [890] [CITE@en[RFC 7252 - The Constrained Application Protocol (CoAP)]] ( ([TIME[2014-06-27 00:59:37 +09:00]] 版)) [894] [CITE@en[RFC 2660 - The Secure HyperText Transfer Protocol]] ( ([TIME[2014-11-09 14:12:37 +09:00]] 版)) [46] [CITE@en[Bug 28391 – Investigate missing content-type for fetching stylesheets]] ([TIME[2015-04-02 15:11:17 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [50] [CITE[採用とか退職とか評価に関するよもやま話 | Ryuzee.com]] ([TIME[2016-03-19 07:32:15 +09:00]] 版) ]FIGCAPTION] > Content-Type: text/html > Content-Length: 60946 > Last-Modified: Fri, 18 Mar 2016 22:32:15 GMT > Connection: keep-alive > ETag: "56ec81ef-ee12" > Content-Type: text/html > ;; [CODE(HTTP)@en[Content-Type]] が2回 ]FIG] [FIG(quote)[ [FIGCAPTION[ [51] [CITE@ja[orefolder.net | androidのホーム画面カスタマイズとウィジェットの情報サイト]] ([TIME[2016-03-21 14:00:28 +09:00]] 版) ]FIGCAPTION] > Content-Type: text/html; charset="UTF-8" ]FIG] [FIG(quote)[ [FIGCAPTION[ [52] [CITE@en[RFC 7030 - Enrollment over Secure Transport]] ([TIME[2016-06-19 16:27:56 +09:00]]) ]FIGCAPTION] > A successful response MUST be a certs-only CMC Simple PKI Response, > as defined in '''['''RFC5272''']''', containing only the certificate that was > issued. The HTTP content-type of "application/pkcs7-mime" with an > smime-type parameter "certs-only" is used, as specified in '''['''RFC5273''']'''. ]FIG] [53] [CITE@en[Clarify package data algorithm for FormData]] ([[eehakkin]]著, [TIME[2016-12-17 01:36:13 +09:00]]) [54] [CITE@en[Editorial: name mimeType variable consistently]] ([[annevk]]著, [TIME[2017-03-09 23:56:57 +09:00]]) [55] [CITE@en[Define MIME type extraction better]] ([[annevk]]著, [TIME[2017-03-09 23:45:32 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [56] [CITE[S2-045 - Apache Struts 2 Documentation - Apache Software Foundation]] ([TIME[2017-03-22 01:24:59 +09:00]]) ]FIGCAPTION] > It is possible to perform a RCE attack with a malicious Content-Type value. If the Content-Type value isn't valid an exception is thrown which is then used to display an error message to a user. ]FIG] [FIG(quote)[ [FIGCAPTION[ [70] [CITE@ja[個性派賃貸物件:自由に塗っちゃってください!!(room:1336) :: rooms renovation]] ([[rooms]]著, [TIME[2017-08-10 16:13:21 +09:00]]) ]FIGCAPTION] > Content-Type: text/html; charset:shift_jis ]FIG] [71] [CITE@en[Define Content-Type manipulation in terms of MIME Sniffing]] ([[annevk]]著, [TIME[2018-04-16 18:51:34 +09:00]]) [72] [CITE@en[Define Content-Type manipulation in terms of MIME Sniffing by annevk · Pull Request #176 · whatwg/xhr]] ([TIME[2018-04-17 23:09:23 +09:00]]) [73] [CITE@en[Fix overrideMimeType() again]] ([[annevk]]著, [TIME[2018-04-17 17:54:28 +09:00]]) [74] [CITE@en[Editorial: rewrite send()'s body/content-type processing]] ([[domenic]]著, [TIME[2018-04-24 00:09:11 +09:00]]) [75] [CITE@en[Editorial: less-confusing content-type manipulation algorithm for send() · Issue #197 · whatwg/xhr]] ([TIME[2018-04-24 16:16:21 +09:00]]) [76] [CITE@en[Editorial: rewrite send()'s body/content-type processing by domenic · Pull Request #205 · whatwg/xhr]] ([TIME[2018-04-24 16:16:35 +09:00]]) [77] [CITE@en[Strengthen requirements on CORS-safelisted request-headers]] ([[annevk]]著, [TIME[2018-05-25 18:19:35 +09:00]]) [78] [CITE@en[Be strict on request's Content-Type]] ([[annevk]]著, [TIME[2018-11-09 17:36:06 +09:00]]) [79] [CITE@en[Be strict on request's Content-Type by annevk · Pull Request #829 · whatwg/fetch]] ([TIME[2019-06-19 13:55:56 +09:00]]) [81] [CITE@en[Define the Content-Type header parser]] ([[annevk]]著, [TIME[2018-11-27 18:47:01 +09:00]]) [82] [CITE@en[Define the Content-Type header parser]] ([[annevk]]著, [TIME[2018-11-27 18:47:01 +09:00]]) [83] [CITE@en[Redesign "extract header values" and "extract header list values" · Issue #814 · whatwg/fetch]] ([TIME[2019-06-19 15:02:45 +09:00]]) [84] [CITE@en["Extract a MIME type" algorithm should pick the first entry? · Issue #529 · whatwg/fetch]] ([TIME[2019-06-19 15:02:55 +09:00]]) [85] [CITE@en[Content-Type parsing (MIME type parsing) · Issue #30 · whatwg/mimesniff]] ([TIME[2019-06-19 15:03:39 +09:00]]) [86] [CITE@en[Define the Content-Type header parser by annevk · Pull Request #831 · whatwg/fetch]] ([TIME[2019-06-19 15:08:40 +09:00]]) [87] [CITE@ja[チケット #47296: メールの文字コード指定 - スラド - OSDN]], [[shibuyak]], 登録: 2023-02-03 13:00, 最終更新: 2023-02-03 13:00, [TIME[2024-01-25T04:24:55.000Z]] > スラドの記事のメール受信を利用しています。時々文字化けが起こることがあり、調べてみた所、スラドから送られてくるメールの文字コード指定方法が間違っているため、メールアプリが正しくデコードできないことがあるということがわかりました。 > Content-type: text/plain; charset="iso-2022-jp" > というヘッダが送られてきていますが、文字コード指定はクオートせず、 > Content-type: text/plain; charset=iso-2022-jp > というのが正しいMIMEの記述です。 このため、メールアプリはこの文字コード指定を正しく解釈できず、本文を独自に文字コード判断することとなり、文面によってはたまにコードの判断を誤ることがあるようです。 [88] これは仕様書が曖昧でちょっと解釈論的には厄介なのだが、 '''どちらも正しい'''と解釈されるべきもので、これが原因で[[文字化け]]するとしたらその [[MUA]] が壊れている。