Many Content-Types which could usefully be transported via email are
represented, in their "natural" format, as 8-bit character or binary
data. Such data cannot be transmitted over some transport protocols.
For example, RFC 821std10(-> 2821prop) restricts mail messages to 7-bit US-ASCII data
with lines no longer than 1000 characters.
It is necessary, therefore, to define a standard mechanism for re-
encoding such data into a 7-bit short-line format. This document
specifies that such encodings will be indicated by a new "Content-
Transfer-Encoding" header field. The Content-Transfer-Encoding field
is used to indicate the type of transformation that has been used in
order to represent the body in an acceptable manner for transport.
Unlike Content-Types, a proliferation of Content-Transfer-Encoding
values is undesirable and unnecessary. However, establishing only a
single Content-Transfer-Encoding mechanism does not seem possible.
There is a tradeoff between the desire for a compact and efficient
encoding of largely-binary data and the desire for a readable
encoding of data that is mostly, but not entirely, 7-bit data. For
this reason, at least two encoding mechanisms are necessary: a
"readable" encoding and a "dense" encoding.
The Content-Transfer-Encoding field is designed to specify an
invertible mapping between the "native" representation of a type of
data and a representation that can be readily exchanged using 7 bit
mail transport protocols, such as those defined by RFC 821std10(-> 2821prop) (SMTP).
This field has not been defined by any previous standard. The field's
value is a single token specifying the type of encoding, as
enumerated below. Formally:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" ; case-insensitive
/ "quoted-printable"
/ "base64"
/ "8bit"
/ "binary"
/ x-token
These values are not case sensitive. That is, Base64 and BASE64 and
bAsE64 are all equivalent. An encoding type of 7BIT requires that
the body is already in a seven-bit mail-ready representation. This
is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is
assumed if the Content-Transfer-Encoding header field is not present.
The values "8bit", "7bit", and "binary" all mean that NO encoding has
been performed. However, they are potentially useful as indications
of the kind of data contained in the object, and therefore of the
kind of encoding that might need to be performed for transmission in
a given transport system. In particular:
"7bit" means that the data is all represented as short
lines of US-ASCII data.
"8bit" means that the lines are short, but there may be
non-ASCII characters (octets with the 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 transport.
The difference between "8bit" (or any other conceivable bit-width
token) and the "binary" token is that "binary" does not require
adherence to any limits on line length or to the SMTP CRLF semantics,
while the bit-width tokens do require such adherence. If the body
contains data in any bit-width other than 7-bit, the appropriate
bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
for unencoded 8 bit wide data). If the body contains binary data,
the "binary" Content-Transfer-Encoding token must be used.
NOTE: The distinction between the Content-Transfer-Encoding values
of "binary", "8bit", etc. may seem unimportant, in that all of
them really mean "none" -- that is, there has been no encoding of
the data for transport. However, clear labeling will be of
enormous value to gateways between future mail transport systems
with differing capabilities in transporting data that do not meet
the restrictions of RFC 821std10(-> 2821prop) transport.
Mail transport for unencoded 8-bit data is defined in RFC-1426(-> 1652draft)
[RFC-1426]. As of the publication of this document, there are no
standardized Internet mail transports for which it is legitimate
to include unencoded binary data in mail bodies. Thus there are
no circumstances in which the "binary" Content-Transfer-Encoding
is actually legal on the Internet. However, in the event that
binary mail transport becomes a reality in Internet mail, or when
this document is used in conjunction with any other binary-capable
transport mechanism, binary bodies should be labeled as such using
this mechanism.
NOTE: The five values defined for the Content-Transfer-Encoding
field imply nothing about the Content-Type other than the
algorithm by which it was encoded or the transport system
requirements if unencoded.
Implementors may, if necessary, define new Content-Transfer-Encoding
values, but must use an x-token, which is a name prefixed by "X-" to
indicate its non-standard status, e.g., "Content-Transfer-Encoding:
x-my-new-encoding". However, unlike Content-Types and subtypes, the
creation of new Content-Transfer-Encoding values is explicitly and
strongly discouraged, as it seems likely to hinder interoperability
with little potential benefit. Their use is allowed only as the
result of an agreement between cooperating user agents.
If a Content-Transfer-Encoding header field appears as part of a
message header, it applies to the entire body of that message. If a
Content-Transfer-Encoding header field appears as part of a body
part's headers, it applies only to the body of that body part. If an
entity is of type "multipart" or "message", the Content-Transfer-
Encoding is not permitted to have any value other than a bit width
(e.g., "7bit", "8bit", etc.) or "binary".
It should be noted that email is character-oriented, so that the
mechanisms described here are mechanisms for encoding arbitrary octet
streams, not bit streams. If a bit stream is to be encoded via one
of these mechanisms, it must first be converted to an 8-bit byte
stream using the network standard bit order ("big-endian"), in which
the earlier bits in a stream become the higher-order bits in a byte.
A bit stream not ending at an 8-bit boundary must be padded with
zeroes. This document provides a mechanism for noting the addition
of such padding in the case of the application Content-Type, which
has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all data in
ASCII. Thus, for example, suppose an entity has header fields such
as:
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
This must be interpreted to mean that the body is a base64 ASCII
encoding of data that was originally in ISO-8859-1, and will be in
that character set again after decoding.
The following sections will define the two standard encoding
mechanisms. The definition of new content-transfer-encodings is
explicitly discouraged and should only occur when absolutely
necessary. All content-transfer-encoding namespace except that
beginning with "X-" is explicitly reserved to the IANA for future
use. Private agreements about content-transfer-encodings are also
explicitly discouraged.
Certain Content-Transfer-Encoding values may only be used on certain
Content-Types. In particular, it is expressly forbidden to use any
encodings other than "7bit", "8bit", or "binary" with any Content-
Type that recursively includes other Content-Type fields, notably the
"multipart" and "message" Content-Types. All encodings that are
desired for bodies of type multipart or message must be done at the
innermost level, by encoding the actual body that needs to be
encoded.
NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
using content-transfer-encodings on data of type multipart or
message may seem overly restrictive, it is necessary to prevent
nested encodings, in which data are passed through an encoding
algorithm multiple times, and must be decoded multiple times in
order to be properly viewed. Nested encodings add considerable
complexity to user agents: aside from the obvious efficiency
problems with such multiple encodings, they can obscure the basic
structure of a message. In particular, they can imply that
several decoding operations are necessary simply to find out what
types of objects a message contains. Banning nested encodings may
complicate the job of certain mail gateways, but this seems less
of a problem than the effect of nested encodings on user agents.
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding
could be inferred from the characteristics of the Content-Type
that is to be encoded, or, at the very least, that certain
Content-Transfer-Encodings could be mandated for use with specific
Content-Types. There are several reasons why this is not the case.
First, given the varying types of transports used for mail, some
encodings may be appropriate for some Content-Type/transport
combinations and not for others. (For example, in an 8-bit
transport, no encoding would be required for text in certain
character sets, while such encodings are clearly required for 7-
bit SMTP.) Second, certain Content-Types may require different
types of transfer encoding under different circumstances. For
example, many PostScript bodies might consist entirely of short
lines of 7-bit data and hence require little or no encoding.
Other PostScript bodies (especially those using Level 2
PostScript's binary encoding mechanism) may only be reasonably
represented using a binary transport encoding. Finally, since
Content-Type is intended to be an open-ended specification
mechanism, strict specification of an association between
Content-Types and encodings effectively couples the specification
of an application protocol with a specific lower-level transport.
This is not desirable since the developers of a Content-Type
should not have to be aware of all the transports in use and what
their limitations are.
NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64
encodings are designed so that conversion between them is
possible. The only issue that arises in such a conversion is the
handling of line breaks. When converting from quoted-printable to
base64 a line break must be converted into a CRLF sequence.
Similarly, a CRLF sequence in base64 data must be converted to a
quoted-printable line break, but ONLY when converting text data.
NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in
earlier drafts of this memo, regarding the model for when email
data was to be converted to canonical form and encoded, and in
particular how this process would affect the treatment of CRLFs,
given that the representation of newlines varies greatly from
system to system, and the relationship between content-transfer-
encodings and character sets. For this reason, a canonical model
for encoding is presented as Appendix G.
The Quoted-Printable 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
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 may also be encoded in Quoted-Printable to ensure the
integrity of the data should the message pass through a character-
translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined by the
following rules:
Rule #1: (General 8-bit representation) Any octet, except those
indicating a line break according to the newline convention of the
canonical (standard) form of the data being encoded, may be
represented by an "=" followed by a two digit hexadecimal
representation of the octet's value. The digits of the
hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
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
SIGN) can be represented by "=3D". Except when the following
rules allow an alternative encoding, this rule is mandatory.
Rule #2: (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
TAB (HT) or SPACE characters on an encoded line MUST thus be
followed on that line by a printable character. In particular, an
"=" at the end of an encoded line, indicating a soft line break
(see rule #5) may follow one or more TAB (HT) or SPACE characters.
It follows that an octet with value 9 or 32 appearing at the end
of an encoded line must be represented according to Rule #1. This
rule is necessary because some MTAs (Message Transport Agents,
programs which transport messages from one user to another, or
perform a part of such transfers) are known to pad lines of text
with SPACEs, and others are known to remove "white space"
characters from the end of a line. Therefore, when decoding a
Quoted-Printable body, any trailing white space on a line must be
deleted, as it will necessarily have been added by intermediate
transport agents.
Rule #4 (Line Breaks): A line break in a text body, independent of
what its representation is following the canonical representation
of the data being encoded, must be represented by a (RFC 822std11(-> 2822prop)) line
break, which is a CRLF sequence, in the Quoted-Printable encoding.
Since the canonical representation of types other than text do not
generally include the representation of line breaks, no hard line
breaks (i.e. line breaks that are intended to be meaningful and
to be displayed to the user) should occur in the quoted-printable
encoding of such types. Of course, occurrences of "=0D", "=0A",
"0A=0D" and "=0D=0A" will eventually be encountered. In general,
however, base64 is preferred over quoted-printable for binary
data.
Note that many implementations may elect to encode the local
representation of various content types directly, as described in
Appendix G. In particular, this may apply to plain text material
on systems that use newline conventions other than CRLF
delimiters. Such an implementation is permissible, but the
generation of line breaks must be generalized to account for the
case where alternate representations of newline sequences are
used.
Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES
that encoded lines be no more than 76 characters long. If longer
lines are to be encoded with the Quoted-Printable encoding, 'soft'
line breaks must be used. An equal sign as the last character on a
encoded line indicates such a non-significant ('soft') line break
in the encoded text. Thus if the "raw" form of the line is a
single unencoded line that says:
Now's the time for all folk to come to the aid of
their country.
This can be represented, in the Quoted-Printable encoding, as
Now's the time =
for all folk to come=
to the aid of their country.
This provides a mechanism with which long lines are encoded in
such a way as to be restored by the user agent. The 76 character
limit does not count the trailing CRLF, but counts all other
characters, including any equal signs.
Since the hyphen character ("-") is represented as itself in the
Quoted-Printable encoding, care must be taken, when encapsulating a
quoted-printable encoded body in a multipart entity, to ensure that
the encapsulation boundary does not appear anywhere in the encoded
body. (A good strategy is to choose a boundary that includes a
character sequence such as "=_" which can never appear in a quoted-
printable body. See the definition of multipart messages later in
this document.)
NOTE: The quoted-printable encoding represents something of a
compromise between readability and reliability in transport.
Bodies encoded with the quoted-printable encoding will work
reliably over most mail gateways, but may not work perfectly over
a few gateways, notably those involving translation into EBCDIC.
(In theory, an EBCDIC gateway could decode a quoted-printable body
and re-encode it using base64, but such gateways do not yet
exist.) A higher level of confidence is offered by the base64
Content-Transfer-Encoding. A way to get reasonably reliable
transport through EBCDIC gateways is to also quote the ASCII
characters
!"#$@[\]^`{|}~
according to rule #1. See Appendix B for more information.
Because quoted-printable data is generally assumed to be line-
oriented, it is to be expected that the representation of the breaks
between the lines of quoted printable data may be altered in
transport, in the same manner that plain text mail has always been
altered in Internet mail when passing between systems with differing
newline conventions. If such alterations are likely to constitute a
corruption of the data, it is probably more sensible to use the
base64 encoding rather than the quoted-printable encoding.
WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
printable, care must be taken to encode 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
represented as a hard line break, it might be incorrectly decoded on
platforms with different line break conventions.
For formalists, the syntax of quoted-printable data is described by
the following grammar:
quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
; Maximum line length of 76 characters excluding CRLF
ptext := octet /<any ASCII character except "=", SPACE, or TAB>
; characters not listed as "mail-safe" in Appendix B
; are also not recommended.
octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; octet must be used for characters > 127, =, SPACE, or TAB,
; and is recommended for any characters not listed in
; Appendix B as "mail-safe".
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable. The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data. This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421hist.
The base64 encoding is adapted from RFC 1421hist, with one change: base64
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, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is
represented identically in all versions of ISO 646, including US
ASCII, and all characters in the subset are also represented
identically in all versions of EBCDIC. Other popular encodings,
such as the encoding used by the uuencode utility and the base85
encoding specified as part of Level 2 PostScript, do not share
these properties, and thus do not fulfill the portability
requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8-bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single digit in the base64 alphabet.
When encoding a bit stream via the base64 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first byte, and the eighth bit will be the low-order bit in the
first byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected so as to be universally representable, and the set excludes
characters with particular significance to SMTP (e.g., ".", CR, LF)
and to the encapsulation boundaries defined in this document (e.g.,
"-").
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The output stream (encoded bytes) must be represented in lines of no
more than 76 characters each. All line breaks or other characters
not found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Padding at the end of
the data is performed using the '=' character. Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any '=' characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data. The same applies to any illegal sequence of
characters in the base64 encoding, such as "====="
Care must be taken to use the proper octets for line breaks if base64
encoding is applied directly to text material that has not been
converted to 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 encoder rather
than in a prior canonicalization step in some implementations.
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of multipart
entities because no hyphen characters are used in the base64
encoding.
