text/plain のように
text/plain
全体を指しますが、稀に text のみを指していることがあります。
Content-Type の値」といったような表現を使っており、現在の「
plain、
png、pdf
などがあります。
image を video に置き換えるような使い方はできず、
まったく異なる
video/ogg audio/ogg /、
/ ;
= = #,
. + ! #, $ & ^ ; を含まないものです
/ の場合、; の場合、= でも ; でもない; の場合、= の場合、" の場合、; でないdata: URL処理器overrideMimeTypeContent-Type:Content-Type: sendsend (XHR) <script type><form enctype>/、MIME型の;、
名前、
= を連結した結果を追加します。" や \ が含まれる場合、
そのすべての直前に \ を挿入します。"、値、"
を連結した結果を追加します。data: の
<script language> text/
を省略したものと規定されています。
<script type> との処理の統合のため
typ, cty は
application/ を省略できると規定しています。
data: では text/plain を省略して
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| [GNOME] | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Open Inventor 3次元 scenes |
| |
| |
| |
| [freedesktop.org] |
| |
| |
| |
| |
| |
| |
| |
| |
mce-no/type | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
riot/tag | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| [Namazu] |
| |
| |
| |
| |
urdu/urdu98 | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| 未知 (自動判別) |
| |
| |
| |
| |
|
*/**/* が認められており、任意のファイル型と説明されています。
<script type>
multipart/* application/* video/* video/*
x-
+ と構文名がついているものは、その構文の一応用であることを表します。
この例では、
vnd. prs.
revision
text/plain format charsetapplication/xop+xml typetext/markdown charsetapplication/coap-payload cf
process (text/troff)versions (text/troff)
application/json text/xml
application/xhtml-voice+xml
markdown (temporary registered 2014-11-11, extension registered
2015-09-17, expires 2016-11-11)... という謎の注記付き部分型で登録されています。
application/mud+json は次のような謎の注釈付きで登録されています。
<record date="2016-11-17">
<name>mud+json (TEMPORARY - registered 2016-11-17, expires 2017-11-17)</name>
<xref type="draft" data="draft-ietf-opsawg-mud"/>
<file type="template">application/mud+json</file>
</record>TEMPORARY - registered 2016-11-17, extension registered 2017-10-02, expires 2018-11-17
... となっています。
text/css なら
text/plain のものはありません。
application/vnd.openxmlformats-officedocument.presentationml.template
1. Deprecated alias names for this type: application/vnd.adobe.xfdf
とある。しかし現在のapplication/vnd.adobe.xfdf
が掲載されていない。かつては application/vnd.adobe.xfdf
が
application/vnd.fdf → application/fdf
でも同じ現象が起こっている。
MimeType MimeTypeArray accept=""Content-Type: Accept: Content-Style-Type: Content-Script-Type: type type application/vnd.pwg-multiplexed accept enctype srctype contentStyleType contentScriptType contentType overrideMimeType data: (ct= navigator.mimeTypes preview-typetyp、ctydata: URL構造体
The definition of a top-level media type consists of:
上位媒体型の定義は次のものから構成されます。
(1) a name and a description of the type, including
criteria for whether a particular type would qualify
under that type,(1) 型の名前と説明。特定の型をその型の下に置けるかどうかの適合基準
(2) the names and definitions of parameters, if any, which
are defined for all subtypes of that type (including
whether such parameters are required or optional),(2) その型のすべての亜型用に定義するパラメーターがあればその名前と定義 (そのパラメーターが必須か省略可能かを含む)
(3) how a user agent and/or gateway should handle unknown
subtypes of this type,(3) 利用者代理者や関門がその型の未知の亜型をどう取り扱うべきか
(4) general considerations on gatewaying entities of this
top-level type, if any, and(4) 必要なら、この上位型の実体の関門通過に関しての考慮一般
(5) any restrictions on content-transfer-encodings for
entities of this top-level type.(5) この上位型の実体の内容転送符号化の制限
The five discrete top-level media types are:
5つの個々上位媒体型は次の通りです。
(1) text -- textual information. The subtype "plain" in
particular indicates plain text containing no
formatting commands or directives of any sort. Plain
text is intended to be displayed "as-is". No special
software is required to get the full meaning of the
text, aside from support for the indicated character
set. Other subtypes are to be used for enriched text in
forms where application software may enhance the
appearance of the text, but such software must not be
required in order to get the general idea of the
content. Possible subtypes of "text" thus include any
word processor format that can be read without
resorting to software that understands the format. In
particular, formats that employ embeddded binary
formatting information are not considered directly
readable. A very simple and portable subtype,
"richtext", was defined in RFC 1341, with a further
revision in RFC 1896 under the name "enriched".(1) text —— 文字情報。亜型 "plain" は特に、いかなる類の書式化命令・指令 を含まない平文 (plain-text) を示します。平文は「そのまま」表示する ことを意味します。文の完全な意味を得るのに、指定された文字集合への対応を 除いて特別なソフトウェアは必要ありません。他の亜型は応用ソフトウェアが 文の見た目をよくする裕福文に使われるかもしれませんが、内容の 一般的な着想を得るのにはこのようなソフトウェアは必須ではありません。 ですから "text" の亜型となりえるものにはその形式を理解するソフトウェア 無しに読むことが出来る言葉処理器 (ワード・プロセッサー) の形式を含みます。 特に、バイナリ書式付け情報を埋め込んだ形式は直接可読とは言えません。 とても単純で移植性ある亜型, "richtext" (裕福文) は RFC 1341 で定義されていましたが、 RFC 1896 で "enriched" (裕福化) という名前で 更に改訂されています。
訳注: embeddded は d が一個多い。
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial
subtype is defined for the widely-used image format
JPEG. . subtypes are defined for two widely-used image
formats, jpeg and gif.(2) image ——画像データ。 "image" は情報を見るのに表示機器 (画像画面, 画像印刷機, FAX 機器など) が必要です。初期亜型としては 広く使われている画像形式 JPEG を定義します。。 亜型としては 2つの広く使われている画像形式, jpeg と gif を定義します。 (訳注: 誤植というか編集ミスというか。)
(3) audio -- audio data. "Audio" requires an audio output
device (such as a speaker or a telephone) to "display"
the contents. An initial subtype "basic" is defined in
this document.(3) audio ——音声データ。 "audio" は音声出力機器 (スピーカーとか電話とか) が内容を「表示」するのに必要です。初期亜型としては "basic" をこの文書で定義します。
(4) video -- video data. "Video" requires the capability
to display moving images, typically including
specialized hardware and software. An initial subtype
"mpeg" is defined in this document.(4) video 動画データ。 "video" は動く画像を表示する能力が必要です。 典型的には特別なハードウェアとソフトウェアを含みます。 初期亜型としては "mpeg" をこの文書で定義します。
(5) application -- some other kind of data, typically
either uninterpreted binary data or information to be
processed by an application. The subtype "octet-
stream" is to be used in the case of uninterpreted
binary data, in which case the simplest recommended
action is to offer to write the information into a file
for the user. The "PostScript" subtype is also defined
for the transport of PostScript material. Other
expected uses for "application" include spreadsheets,
data for mail-based scheduling systems, and languages
for "active" (computational) messaging, and word
processing formats that are not directly readable.
Note that security considerations may exist for some
types of application data, most notably
"application/PostScript" and any form of active
messaging. These issues are discussed later in this
document.(5) appliaction 他の種類のデータ, 典型的には解釈出来ないバイナリ・データ や応用により処理される情報です。亜型 "octet-stream" は解釈出来ない バイナリ・データに使われ、この場合の最も簡単な推奨動作は情報を ファイルに書き出すと利用者に申し出ることです。 "PostScript" 亜型も PostScript 物体を転送するために定義します。他の "application" で使うべきものには表計算, 基メイル予定系統, 「動的」(計算的)メッセージの言語, 直接可読でないワード・プロセッサーの形式があります。なお、 応用データの幾つかの型, とりわけ "application/PostScript" や動的 目セージの形式には安全性について考慮すべきことがあたりします。 この問題についてはこの文書の後の方で話します。
The two composite top-level media types are:
2つの合成上位媒体型は次の通りです。
(1) multipart -- data consisting of multiple entities of
independent data types. Four subtypes are initially
defined, including the basic "mixed" subtype specifying
a generic mixed set of parts, "alternative" for
representing the same data in multiple formats,
"parallel" for parts intended to be viewed
simultaneously, and "digest" for multipart entities in
which each part has a default type of "message/rfc822".(1) multipart 複数の独立したデータ型の実体で構成されるデータ。 4つの亜型がはじめから定義されています。 "mixed" 亜型は 一般の混成の部分の集合を示し, "alternative" は同じデータを複数の形式で 表現していることを表し, "parallel" は同時に表示されることを意図した 部分を組み合わせたもので、 "digest" は各部分の既定値が "message/rfc822" の多部分実体で構成されるものです。
(2) message -- an encapsulated message. A body of media
type "message" is itself all or a portion of some kind
of message object. Such objects may or may not in turn
contain other entities. The "rfc822" subtype is used
when the encapsulated content is itself an RFC 822
message. The "partial" subtype is defined for partial
RFC 822 messages, to permit the fragmented transmission
of bodies that are thought to be too large to be passed
through transport facilities in one piece. Another
subtype, "external-body", is defined for specifying
large bodies by reference to an external data source.(2) message カプセル化メッセージ。媒体型 "message" の本文は それ自体が何らかの種類のメッセージ物体の一部又は全部です。 この物体が今度は他の実体を含むかもしれませんし、含まないかもしれません。 "rfc822" 亜型はカプセル化内容が RFC 822 メッセージである時に使います。 "partial" 亜型は RFC 822 メッセージの一部用に定義するもので、 転送機能を一片でまとめて通過させるには大き過ぎると思われる 本文を断片化して送ることが出来ます。他の亜型, "external-body" は外部データ源を使って大きな本文を示すのに定義します。
It should be noted that the list of media type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially.
媒体型値は上述の機構でいつ増補されるかもしれませんし、 亜型の集合は本質的に増えて行くだろうことに注意して下さい。
A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-". (Older versions of the widely used Andrew system use the "X-BE2" name, so new systems should probably choose a different name.)
文字 "X-" から始まる媒体型値は私用値で、相互の同意により同意系統で 使われます。厳密に公的に定義されていない形式は "X-" 接頭辞つきで 名前をつけなければなりませんし、公的規定値は "X-" で始めてはいけません。 (広く使われている Andrew の系統の古い版は "X-BE2" 名を使っていましたので、 新しい系統は違う名前を選ぶのがよろしいでしょう。)
In general, the use of "X-" top-level types is strongly discouraged. Implementors should invent subtypes of the existing types whenever possible. In many cases, a subtype of "application" will be more appropriate than a new top-level type.
通常、 "X-" を上位型に使うのは強く非推奨です。実装者は出来る限り 既存の型の亜型をでっち上げるべきです。多くの場合、 "application" の亜型にするのが新しい上位型にするのより適切です。
HTTP uses Internet Media Types
{1945} [13]{2616} [17] in the Content-Type{1945} header field({1945} Section 10.5section{2068} 14.18{2616} 14.17) {2068,2616} and Accept (section 14.1) header fields in order to provide open and extensible data typing {2068,2616} and type negotiation.
- media-type = type "/" subtype *( ";" parameter )
- type = token
- subtype = token
Parameters
may{2616} MAY follow the type/subtype in the form of attribute/value pairs {2616} (as defined in section 3.6).
{1925,2068}
- parameter = attribute "=" value
- attribute = token
- value = token | quoted-string
The type, subtype, and parameter attribute names are case-insensitive. Parameter values
may{2616} might ormaymight not be case-sensitive, depending on the semantics of the parameter name.{1945} LWS must not be generatedLinear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value.{2616} The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.{1945} Upon receipt of a media type with an unrecognized parameter, a user agent should treat the media type as if the unrecognized parameter and its value were not present.{2068} User agents that recognize the media-type MUST process (or arrange to be processed by any external applications used to process that type/subtype by the user agent) the parameters for that MIME type as described by that type/subtype definition to the and inform the user of any problems discovered.
認識できない引数のある媒体型を受信した際は、その認識できない引数と値は現れていないものとして取扱うべきです。 ある media-type を認識する
Note
:that some{1945} Someolder HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, implementations{1945} HTTP/1.0 applications{1945,2068} shouldSHOULD only use media type parameters when they are{1945} necessary to define the content of a messagerequired by that type/subtype definition.
Media-type values are registered with the Internet Assigned Number Authority (IANA
{1945} [15]{2616} [19] ). The media type registration process is outlined in RFC]] 1590 [172048 [171590 [13INS[{1945} INS[{2068} INS[{2616} ]]]] 2048 [17INS[{Errata} ]]. Use of non-registered media types is discouraged.
→
→
When an
Entity-Bodyentity-body is included with a message, the data type of that body is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
メッセージに
- entity-body := Content-Encoding( Content-Type( data ) )
AContent-Type specifies the media type of the underlying data.AContent-Encoding may be used to indicate any additional content codings applied to thetypedata, usually for the purpose of data compression, thatisare a property of theresource requestedrequested resource.The default for the content encoding is none (i.e., the identity function).There is no default encoding.
Content-Type はそのデータのContent-Encoding は、そのデータに適用されている、
要求された
Any
HTTP/1.0HTTP/1.1 message containing an entity-bodyshouldSHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Typeheader, as is the case for Simple-Response messagesfield, the recipientmayMAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the{1945,2068} URL{2616} URI used to identify the resource. If the media type remains unknown, the recipientshouldSHOULD treat it as type "application/octet-stream".
Content-Type
頭欄を含めるべきです。
媒体型が Content-Type 頭欄で与えられていない場合と は、
この場合に限って、受信者は内容Simple-Response メッセージの場合
model/*
matter-transport/sentient-life-form HKCR \.拡張子\"Content Type"(REG_SZ )ファイル タイプ非
Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-".
この規定(?)に従うと、
内容型 ― Describes the content stored in a part. Content types define a media type, a subtype, and an optional set of parameters, as defined in RFC 2616.
A MIME type is used to specify the format of the file containing the logotype data.
MIME types MAY include parameters.
MIME type matching in the Android framework is case-sensitive, unlike formal RFC MIME types. As a result, you should always specify MIME types using lowercase letters.
A valid media type is string that matches the production for valid-MIME-type in the following [ABNF]:
valid-MIME-type = type "/" subtype *(";" parameter)
The type, subtype, and parameter tokens are defined in the [MIME] specification.
scriptFormat
A link property giving the single URL for the format that is used by the script or template. If one has been defined, this should be a URL for a media type, in the form http://www.iana.org/assignments/media-types/media-type such as http://www.iana.org/assignments/media-types/application/javascript. Otherwise, it can be any URL that describes the script or template format.
NOTE
The scriptFormat URL is intended as an informative identifier for the template format, and applications should not access the URL. The template formats that an application supports are implementation defined.
targetFormat
A link property giving the single URL for the format that will be created through the transformation. If one has been defined, this should be a URL for a media type, in the form http://www.iana.org/assignments/media-types/media-type such as http://www.iana.org/assignments/media-types/text/calendar. Otherwise, it can be any URL that describes the target format.
NOTE
The targetFormat URL is intended as an informative identifier for the target format, and applications should not access the URL.
How can I create my own custom content-types that are representations of users, categories, articles etc?
Do not use a standard text/xml content-type. A client is not capable of handling this kind of information. Instead, use a custom format in the following form:
Content-type: application/vnd+company.category+xml
Content-type: application/vnd+company.category+html
Content-type: application/vnd+company.category+json
This allows your clients to process the information (in this case: your categories) as the specified content-type. All three of these content-types are categories, but they are represented in different formats (xml, html and json). Even though this is still information that clients need to know in advance, clients know what to expect, since they can ask for the specific information (categories, in this case), without outside knowledge like the URL etc.
All application/vnd are vendor-specific content-types and are not standardized. These are for non-standard content-types only.
The value is either an Internet Media Type (see [RFC2046]) or a
keyword (such as "abnf"). The set of recognized keywords varies
across implementations.
How it is used depends on context and application. For instance, a
formatter can attempt to syntax-highlight code in certain known
languages.
The content-types attribute lists one or more (space separated) content types that this input port will accept. A content type must be of the form “type/subtype+ext” where any of type, subtype, and ext can be specified as “*” meaning “any”. The “+ext” is optional. Here are some examples of content types for matching:
text/plain, plain text documents
text/*, any kind of text document.
*/*+xml, any XML content type.
*/*, any content type.
The value of the property should be the media-type of the format, following the [rfc6838] specification.
To remedy this loss of flexibility, we introduce the concept of a
"loose" media type mapping, where media types that are
specializations of a more generic media type can be aliased to their
super-class and then mapped (if possible) to one of the CoAP content-
formats.
<record date="2018-03-19">
<name>
q pplication/wasm</name><org>W3C</org>
<xref type="person" data="Bradley_Nelson"/>
</record>
mimetype,
mime-subtype