1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W - X
charset
Click on the red underlined text to get to the source
... header fields. The ordering of
parameters is not significant. Among the defined parameters is a
"charset" parameter by which the character set used in the body may
be declared. Comments are allowed in accordance with RFC 822std11(-> 2822prop) ...
... example, the "boundary" parameter makes sense only for the
"multipart" content-type, but the "charset" parameter might make
sense with several content-types.
...
... "Content-type: text/plain; charset=us-ascii". If no Content-Type is
specified, this default is assumed. In the presence of a MIME ...
... no fully acceptable alternative to treating such untyped messages
as "text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version ...
... principally textual in form. It is the default Content-Type. A
"charset" parameter may be used to indicate the character set of the
body text for some text subtypes, notably including the primary
...
... The charset parameter ...
... text/plain data is the character set. This is specified with a
"charset" parameter, as in:
Content-type ...
...
Unlike some other parameter values, the values of the charset
parameter are NOT case sensitive. The default character set, which
must be assumed in the absence of a charset parameter ...
... charset
parameter are NOT case sensitive. The default character set, which
must be assumed in the absence of a charset parameter, is US-ASCII.
...
...
The specification for any future subtypes of "text" must specify
whether or not they will also utilize a "charset" parameter, and may
possibly restrict its values as well. When used with a particular
body, the semantics ...
... possibly restrict its values as well. When used with a particular
body, the semantics of the "charset" parameter should be identical to
those specified here for "text/plain", i.e., the body consists
...
... those specified here for "text/plain", i.e., the body consists
entirely of characters in the given charset. In particular, definers
of future text subtypes should pay close attention the the
implications of multibyte character sets ...
... definitions.
This RFC specifies the definition of the charset parameter for the
purposes of MIME to be a unique mapping of a byte stream ...
... mail use unless absolutely necessary.
The "charset" parameter has been defined primarily for the purpose of
textual data, and is described in this section for that reason.
However, it is conceivable that non-textual data might also wish to
...
... textual data, and is described in this section for that reason.
However, it is conceivable that non-textual data might also wish to
specify a charset value for some purpose, in which case the same
syntax and values should be used.
...
... Internet mail,
"text/plain; charset=us-ascii", describes existing Internet practice.
That is, it is the type of body defined by RFC 822std11(-> 2822prop) ...
...
text-type := "text" "/" text-subtype [";" "charset" "=" charset]
text-subtype := "plain" / extension-token ...
... token
charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
/ "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
/ "iso-8859-8" / "iso-8859-9" / extension-token ...
... no header fields were given and this is text,
with charset US ASCII. It could have been
done with explicit typing as in the next part.]
...
... / "," / "-" / "." / "/" / ":" / "=" / "?"
charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"
/ "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7"
/ "iso-8859-8" / "iso-8859-9" / extension-token ...