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
US-ASCII
Click on the red underlined text to get to the source
... Default RFC 822std11(-> 2822prop) messages are typed by this protocol as plain text in
the US-ASCII character set, which can be explicitly specified as
"Content-type ...
... receiving User Agent can also assume that
plain US-ASCII text was the sender's intent. In the absence of a
MIME-Version ...
... sender's intent. In the absence of a
MIME-Version specification, plain US-ASCII text must still be
assumed, but the sender's intent might have been otherwise.
...
... MIME-Version header field, it is impossible to be certain that a
message is actually text in the US-ASCII character set, since it
might well be a message that, using the conventions that predate
...
... 821std10(-> 2821prop) restricts mail messages to 7-bit US-ASCII data
with lines no longer than 1000 characters.
...
... eliminates the "*" mechanism for embedded clear text.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
...
... description := "Content-Description" ":" *text
The description is presumed to be given in the US-ASCII character
set, although the mechanism specified in [RFC-1522] may be used for
...
... character
set, although the mechanism specified in [RFC-1522] may be used for
non-US-ASCII Content-Description values.
...
... 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
...
...
The default character set, US-ASCII, has been the subject of some
confusion and ambiguity in the past. Not only were there some
...
... character set is deliberate in this regard. The character set name
of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
...
... document.
NOTE: Beyond US-ASCII, an enormous proliferation of character sets
is possible. It is the opinion of the IETF working group ...
... MIME. This document does not
endorse the use of any particular character set other than US-ASCII,
and recognizes that the future evolution of world character sets
...
...
Note that the character set used, if anything other than US-ASCII,
must always be explicitly specified in the Content-Type field.
...
... denominator" character set possible. For example, if a body contains
only US-ASCII characters, it must be marked as being in the US-ASCII
character set ...
... character set possible. For example, if a body contains
only US-ASCII characters, it must be marked as being in the US-ASCII
character set, not ISO ...
... ISO-8859 family of
character sets, is a superset of US-ASCII. More generally, if a
widely-used character set is a subset of another character set ...
... Content-Type header field
implies that the corresponding body is plain US-ASCII text. The only
header fields that have defined meaning for body parts are those the
...
... message/external-body",
as specified below. The message header fields are always US-ASCII in
any case, and data within the body can still be encoded, in which
case the Content-Transfer-Encoding ...
... tokens that describe external-body
data, such as file names and mail server commands, are required to be
in the US-ASCII character set. If this proves problematic in
practice, a new mechanism may be required as a future extension to
...
... text/plain messages, with the
character set specified as a parameter if it is not US-ASCII.
4. Explicitly handle the following Content-Type ...
... -- Recognize and display "text" mail
with the character set "US-ASCII."
-- Recognize other character sets ...
... display those characters that are
common to ISO-8859-* and US-ASCII,
namely all characters represented
by octet values ...
... use character sets such as EBCDIC which contain most but not
all of the US-ASCII characters. The correct translation of
characters not in the "invariant" set cannot be depended on across
character converting gateways ...