郁闷的OpenPOP的MIME Parser

看样子，大家很少使用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……

[原创].Net中绑定到DataView的问题：【上一篇】
动态调用web服务：【下一篇】