看样子，大家很少使用OpenPOP……所以，对
关于OpenPOP/OpenSMTP/Mail.Net的一些东西……
都没有啥反应……
不过，我很想知道开发OpenPOP的灵感之源是没有看到这些讯息还是怎么回事呢？
Well……偶又来说OpenPOP了……不过，只是要说其附带的MIME Parser而已……将email从 RFC 822 格式转换为Object的类……
被它搞得真是很郁闷……
它Parse的时候，很多地方都使用了Encoding.Default，不管email的具体编码是什么，全部都使用当前系统的编码去parse……
因为，这个Parse在很多情况下都可以正确解码，并且源代码中有注释说明：
<param name="encode">encoding method, "Default" is suggested</param>
推荐使用系统默认编码……偶实在不明白其中奥妙……
看其Parse Email Header部分的代码……似乎……也是有一个小bug……
有时候时候charset的信息都是紧跟在content-type后面的……这样的情况，Parser可以正确获得Email的编码……
但是，有的时候charset还是在content-type后面，但是，会换行，并且加一个tag，如：
Content-Type: text/html;
charset="us-ascii"
这样的情况，Parser貌似就把charset给忽略掉了……
或者，这就是Parse UTF-8编码的中文信件出错的原因……
但是，还有另一个很严重的问题：解Quoted-Printable的函数有错……
DecodeQP.cs中138行有这样的内容及注释：
if(isBegin&& (count % 2==0)) //wait until even items to handle all character sets
但，如果是UTF-8编码，每个字符都是三个字节……貌似，应该改为：
if(isBegin&& (count % 3==0)) //wait until even items to handle all character sets including utf-8
否则，会缺字。
唉……郁闷的OpenPOP的MIME Parser……
不过，我很想知道开发OpenPOP的灵感之源是没有看到这些讯息还是怎么回事呢？
Well……偶又来说OpenPOP了……不过，只是要说其附带的MIME Parser而已……将email从 RFC 822 格式转换为Object的类……
被它搞得真是很郁闷……
它Parse的时候，很多地方都使用了Encoding.Default，不管email的具体编码是什么，全部都使用当前系统的编码去parse……
因为，这个Parse在很多情况下都可以正确解码，并且源代码中有注释说明：
<param name="encode">encoding method, "Default" is suggested</param>
推荐使用系统默认编码……偶实在不明白其中奥妙……
看其Parse Email Header部分的代码……似乎……也是有一个小bug……
有时候时候charset的信息都是紧跟在content-type后面的……这样的情况，Parser可以正确获得Email的编码……
但是，有的时候charset还是在content-type后面，但是，会换行，并且加一个tag，如：
Content-Type: text/html;
charset="us-ascii"
这样的情况，Parser貌似就把charset给忽略掉了……
或者，这就是Parse UTF-8编码的中文信件出错的原因……
但是，还有另一个很严重的问题：解Quoted-Printable的函数有错……
DecodeQP.cs中138行有这样的内容及注释：
if(isBegin&& (count % 2==0)) //wait until even items to handle all character sets
但，如果是UTF-8编码，每个字符都是三个字节……貌似，应该改为：
if(isBegin&& (count % 3==0)) //wait until even items to handle all character sets including utf-8
否则，会缺字。
唉……郁闷的OpenPOP的MIME Parser……
本文转自 Wuvist 51CTO博客，原文链接:http://blog.51cto.com/wuvist/847749
