QP编码

Quoted-Printable   加码规则(RFC   1341):

1.   字符用   =XX   形式表示，其中   XX   是该字符的十六进制值，
必须为   0-9   或者   A-F   （使用大写字符）,除非有可替换说明，
否则，此原则是强制性的。

2.   其中，十进制值   33-60   &   62-126(注意:   即不包含   '= '   )  
可以作为标准   ASCII   从而不进行转换。

3.   另外，十进制值   9-32   也可以作为制表和格式控制字符，
从而不进行转换。(注意，这个不是必须执行的，即也可以转换)

4.   由于在   RFC822   协议中规定主体   body   文本中各行均有最大字
符限制，因此，当主体文本中出现   CRLF   或者   LFCR   字符序列，
或者单独的   CR   以及   LF   字符的时候，必须转换成对应的  
"=0D=0A ", "=0A=0D ", "=0D ", "=0A "   等编码来表示。

5.   (关于软回车的问题)   Quoted-Printable   编码要求编码后每行
最大字符数量不得超过   76   个字符。如果对大于该字符数量的行进
行编码，则必须使用软回车。所以，对于某个以编码行的最后加上
'= '符号，则表示最后这个   '= '   是一个无意义的软回车。所以，如
果一个尚未编码的行的内容如下的话:

Now 's   the   time   for   all   folk   to   come   to   the   aid   of   their   country.

那么在   Quoted-Printable   中可以表示为:

Now 's   the   time   =
for   all   folk   to   come=
  to   the   aid   of   their   country.

他提供了一种对过长的行进行编码并恢复到用户原来的输入内容的
机制。虽然一行的末尾的   CRLF   不计入   76   个字符的限制之中，但
是所有的其他字符，包括   '= '   符号都将被计算在内。

由于连字符号   '- '   在   Quoted-Printable   编码中表示他自己，所以当
我们在对一个   multipart   实体的主体内容编码的时候，我们必须注
意：我们决不能让一个   boundary   标志符出现在编码的主体部分！
(一个比较好的办法是在   boundary   中包含一个 "=_ ",这样就决不会重复
了，具体情况清查阅   RFC   1341   中的   multipart   message   的定义部分。)

注意：采用   Quoted-Printable   编码是邮件的传输过程中，对于易读性
和可靠性折衷的一种编码。对于使用   Quoted-Printable   编码的邮件主
体，绝大多数邮件网关(mail   gateway)都能够可靠的工作，但是也可能
在极少的邮件网关上工作的并不十分好，最显著的莫过于涉及到那些
EBCDIC   的传输的时候。(理论上来说，   EBCDIC   网关能够对   Quoted-Pintable
编码进行解码，然后使用   Base64   编码来重新对主体内容进行编码，但是
这些网关在实际中还没有出现呢。)
对于更高的要求，我们使用   Base64   编码。一种适度可信的传输通过
EBCDIC   网关的方法就是依照   [规则   1]   引用如下的   ASCII   码：

! "#$@[\]^`{|}~

更多信息请查看   RFC1341   的   [附录   B]。

由于被   Quoted-Printable   编码的数据通常被认为是行导向的(line-oriented)，
对于使用   Quoted-Printable   编码的数据我们希望行与行之间换行符在传输中被
改写(译者注：由于不同的系统   unix,   windows,   mac得换行符不同)，同样的，我
们希望一封普通文本文件内容的邮件(plain   text   mail)可以在不同的系统中转换
成不同换行符的互联网邮件(Internet   mail)。如果这种转换可能导致原始数据大
量变化(a   corruption   of   the   data)，那么比较明智的选择是应用   base64   编码，
来替换   Quoted-Printable   编码！

5.1  Quoted-Printable Content-Transfer-Encoding            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 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            Borenstein & Freed                                 [Page 14]            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992                 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                 part,   independent   of  what  its  representation  is                 following the  canonical  representation  of  the  data                 being  encoded, must be represented by a (RFC 822) line                 break,  which  is  a  CRLF  sequence,  in  the  Quoted-                 Printable  encoding.  If isolated CRs and LFs, or LF CR                 and CR LF sequences are allowed  to  appear  in  binary                 data  according  to  the  canonical  form, they must be                 represented   using  the  "=0D",  "=0A",  "=0A=0D"  and                 "=0D=0A" notations respectively.                 Note that many implementation may elect to  encode  the                 local representation of various content types directly.                 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            Borenstein & Freed                                 [Page 15]            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992                      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 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.            Borenstein & Freed                                 [Page 16]