QP(Quote-Printable) 方法，通常缩写为“Q”方法，其原理是把一个
8 bit 的字符用两个16进制数值表示，然后在前面加“=”。所以我们看到经过QP编码
后的文件通常是这个样子：=B3=C2=BF=A1=C7=E5=A3=AC=C4=FA=BA=C3=A3=A1。
Quoted-Printable 加码规则(RFC 1341):
1. 字符用 =XX 形式表示，其中 XX 是该字符的十六进制值，
必须为 0-9 或者 A-F （使用大写字符）,除非有可替换说明，
否则，此原则是强制性的。
2. 其中，十进制值 33-60 & 62-126(注意: 即不包含 ‘= ‘ )
可以作为标准 ASCII 从而不进行转换。
3. 另外，十进制值 9-32 也可以作为制表和格式控制字符，
从而不进行转换。(注意，这个不是必须执行的，即也可以转换)
4. 由于在 RFC822 协议中规定主体 body 文本中各行均有最大字
符限制，因此，当主体文本中出现 CRLF(carriage return/line feed)或者 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 码：
! "#[email protected][\]^`{|}~
更多信息请查看 RFC1341 的 [附录 B]。
由于被 Quoted-Printable 编码的数据通常被认为是行导向的(line-oriented)，
对于使用 Quoted-Printable 编码的数据我们希望行与行之间换行符在传输中被
改写(译者注：由于不同的系统 unix, windows, mac得换行符不同)，同样的，我
们希望一封普通文本文件内容的邮件(plain text mail)可以在不同的系统中转换
成不同换行符的互联网邮件(Internet mail)。如果这种转换可能导致原始数据大
量变化(a corruption of the data)，那么比较明智的选择是应用 base64 编码，
来替换 Quoted-Printable 编码！
引:http://topic.csdn.net/t/20031008/20/2334682.html