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
ASCII
Click on the red underlined text to get to the source
... languages require the use of character sets richer than US ASCII
[US-ASCII]. Since RFC 822std11(-> 2822prop) ...
... electronic mail messages to
relatively short lines of seven-bit ASCII. This forces users to
convert any non-textual data that they may wish to send into seven-
...
... convert any non-textual data that they may wish to send into seven-
bit bytes representable as printable ASCII characters before invoking
a local mail UA (User Agent ...
... messages specify either that X.400 non-textual body parts must be
converted to (not encoded in) an ASCII format, or that they must be
discarded, notifying the RFC 822std11(-> 2822prop) user that discarding has occurred.
...
...
This document is being published in two versions, one as plain ASCII
text and one as PostScript (PostScript ...
... The term CRLF, in this document, refers to the sequence of the two
ASCII characters CR (13) and LF (10) which, taken together, in this
...
... series of octets. This definition is intended to allow various kinds
of text encodings, from simple single-table mappings such as ASCII to
complex table switching methods such as those that use ISO ...
... 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.
...
... "8bit" means that the lines are short, but there may be
non-ASCII characters (octets with the high-order
bit set).
...
... high-order
bit set).
"Binary" means that not only may non-ASCII characters
be present, but also that the lines are not
necessarily short enough for SMTP ...
... The encoding mechanisms defined here explicitly encode all data in
ASCII. Thus, for example, suppose an entity has header fields such
...
...
This must be interpreted to mean that the body is a base64 ASCII
encoding of data that was originally in ISO ...
... encoding is intended to represent data that
largely consists of octets that correspond to printable characters in
the ASCII character set. It encodes the data in such a way that the
resulting octets are unlikely to be modified by mail transport. If
...
... resulting octets are unlikely to be modified by mail transport. If
the data being encoded are mostly ASCII text, the encoded form of the
data remains largely recognizable by humans. A body which is
entirely ASCII ...
... ASCII text, the encoded form of the
data remains largely recognizable by humans. A body which is
entirely ASCII may also be encoded in Quoted-Printable to ensure the
integrity ...
... Uppercase letters must be used when sending hexadecimal data,
though a robust implementation may choose to recognize lowercase
letters on receipt. Thus, for example, the value 12 (ASCII form
feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
...
... letters on receipt. Thus, for example, the value 12 (ASCII form
feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
SIGN) can be represented by "=3D". Except when the following
rules allow an alternative encoding ...
... Literal representation) Octets with decimal values of 33
through 60 inclusive, and 62 through 126, inclusive, MAY be
represented as the ASCII characters which correspond to those
octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN
through TILDE, respectively).
...
...
Rule #3: (White Space): Octets with values of 9 and 32 MAY be
represented as ASCII TAB (HT) and SPACE characters, respectively,
but MUST NOT be so represented at the end of an encoded line. Any
...
... CRLF
ptext := octet /<any ASCII character except "=", SPACE, or TAB>
; characters not listed as "mail-safe" in Appendix B
; are also not recommended.
...
... 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, "=",
...
... versions of ISO 646, including US
ASCII, and all characters in the subset are also represented
identically in all versions of EBCDIC ...
... 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
...
... Content-Type header field. "US-
ASCII" does not indicate an arbitrary seven-bit character code, but
specifies that the body uses character coding that uses the exact
...
... bit character code, but
specifies that the body uses character coding that uses the exact
correspondence of codes to characters specified in ASCII. National
use variations of ISO 646 [ISO-646 ...
... use variations of ISO 646 [ISO-646] are NOT ASCII and their use in
Internet mail is explicitly discouraged. The omission of the ISO ...
... character set is deliberate in this regard. The character set name
of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
...
... US-ASCII] only.
The character set name "ASCII" is reserved and must not be used for
any purpose.
...
...
NOTE: RFC 821std10(-> 2821prop) explicitly specifies "ASCII", and references an
earlier version of the American Standard. Insofar as one of the
...
... sender
intended the coded message to be interpreted, assuming anything
other than "strict ASCII" as the default would risk unintentional
and incompatible changes to the semantics of messages now being
...
... control characters including DEL (0-31, 127) have no defined
meaning apart from the combination CRLF (ASCII values 13 and 10)
indicating a new line. Two of the characters have de facto meanings
in wide use: FF ...
... 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
...
... entities of type "multipart". The multipart delimiters and header
fields are always represented as 7-bit ASCII in any case (though the
header fields may encode non-ASCII ...
... ASCII in any case (though the
header fields may encode non-ASCII header text as per [RFC-1522]),
...
... --simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
...
... transport enclaves, RFC 822std11(-> 2822prop) restrictions such as
the one that limits bodies to printable ASCII characters may not
be in force. (That is, the transport domains may resemble
...
... relaxation of these restrictions should be construed as locally
extending the definition of bodies, for example to include octets
outside of the ASCII range, as long as these extensions are
supported by the transport ...
... message headers or body-part headers) allowed to
contain anything other than ASCII characters.
NOTE: Conspicuously missing from the multipart type is a notion of
...
... 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 ...
... header field in the encapsulated
message will reflect this. Non-ASCII text in the headers of an
encapsulated ...
... 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
...
... RFC-783]. The legal values for access-type "FTP"
are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
...
... message/external-body data must be used to declare the Content-type
of the external body if it is anything other than plain ASCII text,
since the external body does not have a header section to declare its
...
... certain level of implementation that allows the useful interworking
of messages with content that differs from US ASCII text. In this
section, we specify the requirements for such conformance.
...
... 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 ...
... automatically converted to variable numbers of spaces. This is
unavoidable in some environments, notably those not based on the
ASCII character set. Such conversion is STRONGLY DISCOURAGED, but
it may occur, and mail formats must not rely on the persistence of
TAB (HT) characters.
...
...
(6) Many mail domains use variations on the ASCII character set,
or use character sets such as EBCDIC ...
... 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 ...
... hosts use character sets other than
ASCII internally. The definition of Printable Strings in X.400
adds further restrictions in certain special cases. In
...
... "=" (ASCII code 61)
"?" (ASCII code 63)
A maximally portable mail representation, such as the base64
encoding ...
... a closing encapsulated text message in a non-ASCII character set.
The embedded multipart message has two parts to be displayed in
...
... 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.]
...
... transport enclaves, RFC 822std11(-> 2822prop) restrictions such as
the one that limits bodies to printable ASCII characters may not
be in force. (That is, the transport domains may resemble
...
... relaxation of these restrictions should be construed as locally
extending the definition of bodies, for example to include octets
outside of the ASCII range, as long as these extensions are
supported by the transport ...
... message headers or body-part headers) allowed to
contain anything other than ASCII characters.
boundary := 0*69<bchars> bcharsnospace
...
... preamble := discard-text ; to be ignored upon receipt.
ptext := octet / <any ASCII character except "=", SPACE, or TAB>
; characters not listed as "mail-safe" in Appendix B
...
...
token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@"
...
... encoding
is needed and the character set is mostly an ASCII superset.
Security considerations ...