发信人: kenmlee()
整理人: kenmlee(2000-07-08 16:49:02), 站内信件
|
3.7 Media Types
#3.7 介质类型 /#
HTTP uses Internet Media Types in the Content-Type (section 14.18)
and Accept (section 14.1) header fields in order to provide open an
d
extensible data typing and type negotiation.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
# HTTP在内容类型(Content-Type 第14.18节)和接受(Accept 第14.1节)头域中
使用
Internet介质类型(Internet Media Type)，提供开放和可扩展的数据类型定
义和
类型协商。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
/#
Parameters may follow the type/subtype in the form of attribute/val
ue
pairs.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
# 参数可以在类型/子类型（type/subtype）格式之后以属性/值（attribute/v
alue）
对的形式出现。
parameter = attribute "=" value
attribute = token
value = token | quoted-string
/#
The type, subtype, and parameter attribute names are case-
insensitive. Parameter values may or may not be case-sensitive,
depending on the semantics of the parameter name. Linear white spac
e
(LWS) MUST NOT be used between the type and subtype, nor between an
attribute and its value. User agents that recognize the media-type
MUST process (or arrange to be processed by any external applicatio
ns
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.
# 类型，子类型和参数属性名是大小写不敏感的。参数值可以是，也可以不是大
小写
敏感的，这依赖于参数名的语义。LWS（Linear white space）一定不能出现
在类
型和子类型之间，属性和它的值之间。用户代理能识别介质类型时必须处理（
或由
用户代理安排其他外部程序去处理）这种由类型/子类型定义的MIME类型的参
数，
并且在处理中存在问题时提示用户。
/#
Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
implementations should only use media type parameters when they a
re
required by that type/subtype definition.
# 注意：一些旧的HTTP应用程序不能识别介质类型参数，但向旧的HTTP应用程
序
发送数据时，只有请求的类型/子类型定义中要求有介质类型参数时才使用
。
/#
Media-type values are registered with the Internet Assigned Number
Authority (IANA). The media type registration process is outlined i
n
RFC 2048 [17]. Use of non-registered media types is discouraged.
# 介质类型值在IANA中登记，介质类型登记过程在RFC 2048[17]中描述，不鼓励
使用
未登记的介质类型。
/#
3.7.1 Canonicalization and Text Defaults
#3.7.1 规范化和文本缺省 /#
Internet media types are registered with a canonical form. In
general, an entity-body transferred via HTTP messages MUST be
represented in the appropriate canonical form prior to its
transmission; the exception is "text" types, as defined in the next
paragraph.
# Internet介质类型以规范化的形式登记，一般来说，一个实体体在传输前必须
给出它的规范形式并以这种形式通过HTTP消息传输；例外的是“text”类型，
下一段给出它的定义。
/#
When in canonical form, media subtypes of the "text" type use CRLF
as
the text line break. HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a li
ne
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR, and bare LF as being
representative of a line break in text media received via HTTP. In
addition, if the text is represented in a character set that does n
ot
use octets 13 and 10 for CR and LF respectively, as is the case for
some multi-byte character sets, HTTP allows the use of whatever oct
et
sequences are defined by that character set to represent the
equivalent of CR and LF for line breaks. This flexibility regarding
line breaks applies only to text media in the entity-body; a bare C
R
or LF MUST NOT be substituted for CRLF within any of the HTTP contr
ol
structures (such as header fields and multipart boundaries).
# 在规范格式中，介质类型"text"的子类型使用CRLF作为文本行结束符。HTTP放
宽了
这种要求，允许用单个CR或LF在传输的文本中表示行结束符，只要在整个实体
体中
的使用是一致的。HTTP应用程序必须接受CRLF，单个CR，单个LF作为通过HTT
P接收
的文本的行结束符标志。并且，如果文本使用的字符集中，八位字节13和10不
代表
CR和LF，如一些多字节字符集，HTTP允许使用字符集中定义为行结束符的能够
起CR
和LF作用的任何字符作为行结束符使用。这种行结束符的灵活性只允许在实体
体的
文本介质中使用；单个CR或单个LF不允许代替HTTP控制结构中的CRLF对（如头
域
和多部分边界）。
/#
If an entity-body is encoded with a Content-Encoding, the underlyin
g
data MUST be in a form defined above prior to being encoded.
The "charset" parameter is used with some media types to define the
character set (section 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" wh
en
received via HTTP. Data in character sets other than "ISO-8859-1" o
r
its subsets MUST be labeled with an appropriate charset value.
# 如果实体体由内容编码(Content-Encoding)所编码，接下来的数据必须在被编
码
之前是上面定义的形式。参数“charset”用于在某些介质类型中定义数据的
字符
集（见3.4节）。当发送者未提供显式的字符集参数时，介质子类型“text”
在通
过HTTP接收时缺省的字符集被定义成“ISO-8859-1”。不是“ISO-8859-1”及
其
子集的数据必须用合适的字符集值标出。
/#
Some HTTP/1.0 software has interpreted a Content-Type header withou
t
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
# 有些HTTP/1.0的软件将没有字符集参数的内容类型头(Content-Type)解释为“
接
收者应该猜测”。如果发送者希望防止这种行为可以在即使字符集参数是ISO
-8859-1
时也加一个字符集参数，并且在知道不会搞混接收者的情况下应该如此。
/#
Unfortunately, some older HTTP/1.0 clients did not deal properly wi
th
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that ha
ve
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document.
# 不幸，某些旧的HTTP/1.0客户程序不能适当的处理显式声明的字符集参数。符
合
HTTP/1.1的接收者必须处理发送者发来的字符集标签；并且当初始显示文档时
那
些有猜测字符集能力的用户代理必须使用内容类型域（content-type）给出的
字
符集而不是接收者配置使用的字符集，只要它能够支持。
/#
3.7.2 Multipart Types
#3.7.2 多部分（Multipart）类型 /#
MIME provides for a number of "multipart" types -- encapsulations o
f
one or more entities within a single message-body. All multipart
types share a common syntax, as defined in MIME [7], and MUST
include a boundary parameter as part of the media type value. The
message body is itself a protocol element and MUST therefore use on
ly
CRLF to represent line breaks between body-parts. Unlike in MIME, t
he
epilogue of any multipart message MUST be empty; HTTP applications
MUST NOT transmit the epilogue (even if the original multipart
contains an epilogue).
# MIME提供了一些多部分“multipart”类型用于在单个消息体中封装一个或多
个
实体，所有多部分类型共用MIME[7]定义的一种通用语法，并且必须包含一个
边
界参数作为介质类型值的一部分。消息体本身是一个协议元素，因此必须在消
息
体个部分间只使用CRLF作为行结束标志。与MIME不同的是，任何多部分消息的
结
束符必须是空的，HTTP应用程序一定不能传送这个结束符（即使原始的多部分
包
含一个结束符）。
/#
In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part. A Content-Location header
field (section 14.15) SHOULD be included in the body-part of each
enclosed entity that can be identified by a URL.
# 在HTTP中,多部分的信息体部分可能包含对这一部分有重要意义的头域，内容
定位
（Content-Location）头域应该包含在每个能用URL表示出来的实体的信息体
部分。
/#
In general, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart typ
e.
If an application receives an unrecognized multipart subtype, the
application MUST treat it as being equivalent to "multipart/mixed".
# 一般来说，接收到一个多部分类型消息时一个HTTP用户代理应该和一个MIME用
户代理
一样，如果应用程序接收到不能识别的多部分子类型必须将它视为“multipa
rt/mixed”
类型。
/#
Note: The "multipart/form-data" type has been specifically define
d
for carrying form data suitable for processing via the POST reque
st
method, as described in RFC 1867 [15].
# 注意：“multipart/form-data”类型特别定义用来携带表单数据已处理
RFC 1867[15] 描述的POST请求的处理。
/#
--
※ 修改:．kenmlee 于 Jul 8 16:30:15 修改本文．[FROM: 61.140.188.222]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 61.140.188.222]
|
|