CRLF
Click on the red underlined text to get to the source
... CRLF ...
...
The term CRLF, in this set of documents, refers to the sequence of
octets corresponding to the two US-ASCII characters CR ...
...
"7bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821std10(-> 2821prop)]. No octets with decimal values greater than 127
...
... (decimal value 13) and LF (decimal value 10) octets only occur as
part of CRLF line separation sequences.
...
... "8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821std10(-> 2821prop)]), but octets with decimal values greater than 127
...
... CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.
...
...
"Lines" are defined as sequences of octets separated by a CRLF
sequences. This is consistent with both RFC 821std10(-> 2821prop) and RFC 822std11(-> 2822prop) ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... US-ASCII
data with lines no longer than 1000 characters including any trailing
CRLF line separator.
...
... line break in the quoted-printable form represents a
CRLF sequence in the canonical form of the data. It must therefore be
converted to a corresponding encoded CRLF ...
... CRLF sequence in the canonical form of the data. It must therefore be
converted to a corresponding encoded CRLF in the base64 form of the
data. Similarly, a CRLF ...
... CRLF in the base64 form of the
data. Similarly, a CRLF sequence in the canonical form of the data
obtained after base64 ...
... Line Breaks) A line break in a text body, represented
as a CRLF sequence in the text canonical form, must be
represented by a (RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop)) line break, which is also a
CRLF sequence, in the Quoted-Printable encoding. Since
...
... text do not generally include the representation of
line breaks as CRLF sequences, no hard line breaks
(i.e. line breaks ...
... representation. In particular, this may apply to plain
text material on systems that use newline conventions
other than a CRLF terminator sequence. Such an
implementation optimization is permissible, but only
when the combined canonicalization ...
... by the user agent. The 76 character limit does
not count the trailing CRLF, but counts all other characters,
including any equal signs.
...
... hexadecimal digit (including "abcdef") nor the CR
character of a CRLF pair is illegal. This case can be
the result of US-ASCII text having been included in a
...
... CR and LF as
parts of CRLF pairs, must not appear. The same is true
for octets with decimal values greater than 126. If
found in incoming quoted-printable ...
... Encoded lines must not be longer than 76 characters,
not counting the trailing CRLF. If longer lines are
found in incoming, encoded data, a robust
implementation might nevertheless decode the lines, and
...
... CR and LF characters as "=0D"
and "=0A", respectively. In particular, a CRLF sequence in binary
data should be encoded as "=0D=0A". Otherwise, if CRLF were
...
... and "=0A", respectively. In particular, a CRLF sequence in binary
data should be encoded as "=0D=0A". Otherwise, if CRLF were
represented as a hard line break, it might be incorrectly decoded on
...
... CRLF ...
... CRLF ...
... canonical form. In particular, text line breaks must be
converted into CRLF sequences prior to base64 encoding. The
important thing to note is that this may be done directly by the
...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...
... CRLF ...