Content-Type 欄 := "Content-Type" ":" Content-Type 欄本体Content-Type 欄本体 := 媒体型媒体型 := 型 "/" 亜型 *(";" 引数指定)引数指定 := 引数名 "=" 引数値)型・亜型・引数名の大文字・
小文字や引数指定の順序は意味を持ちません。
型や引数値の定義
text/plain ; charset =US-ASCII
Content-Type: 欄の規定は
同じメッセージに
(もっとも、構文が全然違うのでどちらの構文も扱えるようにするのは難しくありませんし、 古いメッセージを扱わないのであれば RFC 1049 の構文は無視しても良いかもしれません。)
Content-Type: 欄には狭義のContent-Type:
欄の属性ではありません。)
token
の定義が両規格で異なります。現実に使われている文字は
token で使える文字の共通集合の更に小さな部分集合です。
MIME では、引数値は token または
HTTP でも token と quoted-string
が使えますが、前述のように token の定義は
MIME と異なりますし、 quoted-string
の定義も異なります。 RFC 2231
の方法は使用できないと一般には考えられています。
MIME・HTTP 以外の規格も token と
quoted-string が使えることが多いですが、
詳細はばらばらです。
字句
のような名前付けに関する規定がありません。
| 引数名 | 説明 | 備考 |
| Charset | |
| 作成プログラム識別子 ( | |
| 型 (Macintosh) | |
| | |
|
これら3つの引数は、本来は
name handling Content-Type:
Content-Type | | |
|---|---|
74 65 78 74 2F 70 6C 61 69 6E | text/plain |
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 | text/plain; charset=ISO-8859-1 |
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 | text/plain; charset=iso-8859-1 |
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 | text/plain; charset=UTF-8 |
null と check-for-apache-bug flag を返します。data: の場合 check-for-apache-bug flag は設定されません。
Content-Type:
text/plain になってる
meta 要素から符号化を取り出す算法
単に無視するだけならまだ良いのですが、中にはパラメーターも含めて一つのtext/html;charset=iso-2022-jp という媒体型と認識し、保存しますか?
と聞いてきたりします。
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 と同じです。
Describing Media Content of Binary Data in XML
%ContentType ;Content-Type
以外の情報を使うようですが、以前より幾分ましにはなっている模様。
2007-09-22 11:17:46 +09:00 版)
2007-11-18 14:32:36 +09:00 版)
Content-Type: text/html; charset=Shift_JIS lang=ja
(
2008-01-07 19:33:34 +09:00 版)
CONTENT_TYPE (CGI)
CONTENT_TYPE = "" | media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
CONTENT_TYPE application/x-www-form-urlencoded LWS SP ... というような実装があります。
text/plain; charset=iso-8859-1 なんだが、
Content-Type: 欄 (CGI)Content-Type = "Content-Type:" media-type NL
charset
document() DAV:getcontenttype 特性 (WebDAV)
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]
Initially, the type parameter would be limited to the following set of values:
type:= "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
"DVI"/"X-"atomThese 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.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"
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-partFor type = TROFF
resource-ref:= "eqn"/"tbl"/"me"/local-part
The comment field can be any additional comment text the user desires. Comments are enclosed in parentheses as specified in RFC-822.
RFC 1049 に定義されていない型は IANA に登録申請できることになっていますが、 現在 IANA 登録簿でそれらしいものはありません。
「text」型が使われていたようです(CT:省略時の既定値)。 = text/plain
IETF のメイル・サーバー
古い
「x-uuencode-apple-single」型。中身は uuencoded Macintosh binary (未対応読者への注釈つき)っぽい。
「x-be2」。古い版の Andrew System で使われていたと、 RFC 2046 だったかに 書いてありました。 Google で探してみると、古い archive から幾つか 実例が見つかります。 Andrew Mail System の古い版とやらもどっか 探したら出て来ますかね?
この他にも、幾つかの型が使われていたっぽい形跡はありますが、 まとまった文書は見当りません。
ちなみに RFC 2049 によりますと、 MIME の CT: 定義的に不正な
値は MIME 適合 UA は
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 はより簡単であまり強力ではない構文でしたが、これはここに示す仕組みとかなり互換性があります。
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.
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.
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.
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.
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.
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.
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.
In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows:
RFC 822 の拡張 BNF 記法により、 Content-Type 頭領域値は 次のように定義します。
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.; 媒体型及び亜型の照合は常に大文字・小文字を区別しません。
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-tokencomposite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>; <標準化過程 RFC で定義され、 IANA に登録された拡張 token>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>; <2文字「X-」または「x-」に、空白間隔を挟まずに続く token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>; <公式に定義された拡張 token。この形式の token は RFC 2048 で規定された 通りに IANA に登録されなければならない。>
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.; 属性の照合は常に大文字・小文字を区別しない。
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials> tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values; 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例は完全に同等です。
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
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:
(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. (2) New standard values should be registered with IANA as
described in RFC 2048.The second document in this set, RFC 2046, defines the initial set of media types for MIME.
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 頭欄がない時は、受信した
構文的に不正なんだけど、それを
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 参照) で、投稿者は関係する特定の階層や集団で 確立されている方針あるいは慣習の認めるところでなければ 使用するべきではありません。・・・
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.
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).
The Content-Type entity-header field indicates the media type of the
{1945} Entity-Body{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.
Media types are defined in section
{1945} 3.6{2068,2616} 3.7. An example of the field is
Further discussion of methods for identifying the media type of an entity is provided in section 7.2.1.
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.
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.
CONTENT_TYPE = "" | media-type
media-type = type "/" subtype *( ";" parameter)
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-stringThe 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].
Example:
application/x-www-form-urlencoded
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.
この
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.
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 NLThis 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 対話では 重要であるので、ここに列します。
media-type = type "/" subtype *( ";" parameter)
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-stringContent-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
Content-Typeが2回
Content-Type: text/html; charset="UTF-8"
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].
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.
Content-Type: text/html; charset:shift_jis
スラドの記事のメール受信を利用しています。時々文字化けが起こることがあり、調べてみた所、スラドから送られてくるメールの文字コード指定方法が間違っているため、メールアプリが正しくデコードできないことがあるということがわかりました。
Content-type: text/plain; charset="iso-2022-jp"
というヘッダが送られてきていますが、文字コード指定はクオートせず、
Content-type: text/plain; charset=iso-2022-jp
というのが正しいMIMEの記述です。 このため、メールアプリはこの文字コード指定を正しく解釈できず、本文を独自に文字コード判断することとなり、文面によってはたまにコードの判断を誤ることがあるようです。