邮件乱码纠错
为了适应有些传统系统会把8bits首位过滤掉的问题，
邮件协议里专门添加了base64和quoted-printable两种编码方式，把多字节字符转换成7bits字符，
具体的概念以及编码规则本文就不说了。
按照rfc的规范， “简单email测试”这几个字会被转成
=?gb2312?B?vPKlpWVtYWlssuLKlA==?=
抽象的说，是以 "=?" 开头 , "?="结束，中间 两个问号夹着编码规则， Q表示quoted-printable , B 表示 base64 。 如果按照Q或B规则重新解码，邮件原字就能正确显示。
但是有些软件会有一个不同于rfc要求的处理，即在使用base64编码时对一个字符串进行分段处理。比如上面的“简单email测试”， 就会分成三段 “简单” “email" "测试”。
按照这样处理的编码就成了出来的
=?gb2312?B?vPKlpQ==?=email=?gb2312?B?suLKlA==?=
大家应该都能看出来，区别在于处理时对于天然就是7bits的字符，不作任何编码转换，保持原貌，其他的分段编码。
这样处理的目的，我感觉程序员是为了空间上的考虑，毕竟base64对字符编码时会产生1/3的空间浪费（3个字符变成4个字符），而其中如果出现7bits字符的话，base64转换其实都是不必要的。
自然，很多有和我会有同样的考虑，由于 ?=gb2312?B?......?= 这样一个格式会产生额外的开销，所以当字符串里出现短促7bits字符时，这种处理反倒浪费空间。
空间上的开销是本文额外话题，因为现在的邮件支持8bits的字符，所以，大胆在邮件编写时使用中文字（多字节字）就可以了，不必管那些原始的、只支持7bits的系统。 不过这样的处理又需要注意一点，字符本身不会告诉我们它到底是采用 gb字符还是utf8字符，所以不同字符环境（locale）下邮件内容可能无法正常显示。 这点rfc编码里面到是作了聪明的处理， 在 ?= 和第二个问号之间要求标明字符集。
关于字符集问题，其他文章里再说。 回到本文题目里说的纠错，我的一个建议是：
如果看到邮件字符串只正常显示一个部分，可能就是因为没有对上面的编码串作“宽”处理。
庆幸的是，outlook，foxmail，thunderbird都有这些。我是在使用evolution的时候遇到的这个问题，不过最后还是解决了 ：）
