摘要: Katze，是德文猫的意思，猫是很懒的……用Katze为偶这个“ORM”命名，是要强调其目的：少打代码。ORM加引号，是因为偶不认为它是真正的ORM，它只是个穿上ORM马甲的SqlHelper……它没有xml配置文件，默认映射类名为表名、属性名为列名。如果不一致，通过 Attribute修改。
Katze只支持单数字主键表 （最好还是自增，然后叫做id），不支持各种神奇的关系，只对外键有一定支持。没有缓存机制。企图支持多数据库，但目前只能在MSSQL上跑，还必须是2005版~纯VB.Net开发，只有.net 2.0版本！
呃，如果这样你还有兴趣，就继续看吧……
阅读全文
摘要: 在.Net framework中StreamReader的使用encoding必须在构造器中指定，而且中途完全不可以更改。偶碰巧遇到非修改不可的需求，便根据偶的实际需求，实现了一个"DynamicStreamReader"，以随时修改StreamReader的CurrentEncoding。
阅读全文
原文网址：http://www.blogwind.com/Wuvist/29321.shtml
本来，我不觉得我这篇东西应该上博客园首页，因为跟.Net无关，但，碰巧现在首页上有篇东西是讲FCKEditor（http://www.cnblogs.com/esshs/archive/2006/04/07/369169.html）的……既然讲FCKEditor的可以上，偶也就拿这篇来献丑了……
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
不得不承认，TinyMCE是一个极其强悍的所见即所得网页编辑器。我用过FreeTextBox 1/2/3，CuteEditor 5.0，FckEditor等，使用还是觉得TinyMCE最好。
研究了它的一些代码，非常精彩……
如果说，它有什么缺点的话，那么便就是它无法插入音乐。
（Well，我坚决不认为无法插入音乐是一个缺点；网页中，本来就不应该插入音乐的，特别是自动播放的流氓音乐。）
但是，这也是完全可以解决的……TinyMCE的插件系统是非常强悍的……它自带的插件中有可以插入Flash的，自然也可以依样画葫芦写出插入其它的……只是，Google了N遍，似乎都没有人愿意去写这么个插件。
问如何插入音乐的人倒是很多……Google到的答案，基本都是讲直接编辑html的（这还很可能需要修改extended_valid_elements的值）或者去hack TinyMCE……
很不nice的做法……
还是写插件吧……没有人写，那就我来写好了……
插件下载地址：http://www.cnblogs.com/Files/wuvist/tinymce_Music_plugin.zip
基本上，这个插件跟TinyMCE自带的Flash插件是一样的……事实上，我也是那它的Flash插件改出来的……我这个插件是会插入类似下面的代码：
<object type="application/x-mplayer2" width="100" height="48" data="http://ftp.nxnews.net/music/200491112123673399.mp3">
<param name="src" value="http://ftp.nxnews.net/music/200491112123673399.mp3" />
<param name="filename" value="http://ftp.nxnews.net/music/200491112123673399.mp3" />
<param name="type" value="application/x-mplayer2" />
<param name="AutoStart" value="0" />
</object>
这个是我所找到的兼容性最好的音乐播放代码了，貌似还是符合xhtml 1.1 strict的……
但是，原有的Flash插件太过霸道，会Parse所有的<object...代码，所以如果在TinyMCE中使用flash跟偶的Music插件，一定要先加载Music，再加载flash，否则flash插件会把音乐的干掉。
最后，偶插件中只提供了en跟zh_cn的语言包，而且，zh_cn是utf-8的。
是的，这篇翻译是下篇，上篇是在：
http://www.blogwind.com/Wuvist/6984.shtml
我在2005年2月13日翻译的。如果你没有看过上篇，也没有看过原文（http://www.joelonsoftware.com/articles/APIWar.html），请先看上篇。而且建议去看原文，因为，我在翻译的时候去掉了一些附带说明与链接。
原文作者：Joel Spolsky
Sunday, June 13, 2004
一统天下的运行时
.Net降临了。这是一个浩大的工程；一个企图彻底根除所有混乱局面的工程。它自然有内存管理。它不仅有Visual Basic，还有一门新的语言。这语言继承了Visual Basic的精神，但却有着C风格的语法－大括号跟引号。最妙的是这门糅合了VB跟C的新语言叫C#，也就是说你再也不用跟别人说你是一个“Basic”基本程序员了。那些恐怖的拖泥带水的Window函数、钩子、向后兼容的Bug还有无从解释的字符串返回语法都被扫除了；取而代之的是一个崭新只有一种字符串并面向对象的接口。一统天下的运行时。这很美，在技术得赞下微软。.Net是一个超赞的程序开发环境，它可以帮你管理内存，拥有丰富、完整并统一的操作系统接口；而且还有丰富、超级完整还很优雅供基本操作的对象库。
但是，程序员不用.Net做太多开发。
当然，也有用.Net的人。
但，使用一个全新彻底革新的程序开发环境来统一VB跟Windows API开发并存造成的混乱是愚蠢的。现在，我们不是有一种或者是两种开发语言，而是有三种开发语言（还是四种？）！就跟对两个在吵架的小孩大喊：“你们都别吵了！”一样愚蠢。在电视里面，这样子大喊也许会有效；但在现实生活中这样搞法的必然结果就是你跟两个小孩三个人一起吵得更加大声。
（顺便说一下，那些有关注神秘但被政治所改变的网志聚合格式世界的朋友，你们可以发现同样的事情也发生了。RSS被分裂成为了几个版本－不准确的规则跟一堆政治性质的斗争。而企图解决这一切的做法竟然是定义一个新的叫ATOM的聚合格式。结果便是不同版本的RSS现在多了一个ATOM来搅局－不准确的规则跟一堆政治性质的斗争。当你企图引入第三方来解决对立的两方时，结果便是三足鼎立。你什么也没有统一而且你也没有解决任何事情。）
所以，.Net现在并没有统一并简化世界，我们现在反倒陷入了更大的混乱。所有的人都在犹豫他们的开发策略，究竟有没有足够能力把现有程序转到.Net上呢？
无论微软的市场信息是多么的统一（“用.Net吧！相信我们！”），它的大部分用户还是在使用C,C++,VB 6.0跟传统的ASP做开发。更不用说其它公司提供的开发工具了。然后，仅剩的使用.Net做开发的公司做的是ASP.Net！ASP.Net需要跑在Windows服务器上，但，它需要一个Windows做客户端。这就是我谈到Web时要强调的重点。
哦，等一下，还有其它的东西！
现在微软有了太多的开发人员搞得它重新发明一次整套Windows API还觉得不够爽，它竟然重新发明了两次！在去年（应该是03年，Wuvist注。）的PDC上，微软宣布了它们的下一代操作系统，代号长角。长角不仅有上述的东西，还有一套全新的用户界面API，代号Avalon。Avalon再次把一起推倒从来以利用现在电脑高速的显卡跟实时三维渲染的优势。所以，如果你现在正在开发Windows界面程序，并且使用了微软现在“官方”宣称的最先进的开发环境：WinForms；那么两年后你得重新开始以支持长角跟Avalon。这解释了为什么WinForms在诞生之时便死翘翘了。但愿你还没有在WinForms上投入太多。Jon Udell从微软那找到了一个题为：“我如何在Windows Forms与Avalon间做选择？”的幻灯片，并且问了这么个问题。这是个好问题，并且没有人可以很好的回答它。
所以，我们有了Windows API，有VB，现在还有了带若干种不同语言供选择的.Net；但，我们不能在这些环境下浸淫太久。因为，微软正在开发Avalon呢！注意到没？Avalon可只能在微软最新的操作系统上跑，但是，它得等很久很久以后才能开跑。对我个人来说，我没有时间很深入的学习.Net，并且，我们也没有把Fog Creek的两个应用程序从传统的ASP跟VB 6.0转到.Net上。因为投入做这么件事情对我们没有回馈。一点都没有。在我关心的范围里，它纯粹是一件“开火并动作”的事情：微软会爱死我们停止给Bug跟踪软件跟CMS开发新的功能，并浪费几个月的时间转移到新的开发环境里。这无法使我的任何一个客户获利，也没法让我多卖一套软件。但这对微软来说很妙，因为微软也有它自己的CMS跟Bug跟踪软件。对微软来说，再也没有比使我为追时髦而浪费时间重新绕着.Net转，并且一两年后在为Avalon浪费一次时间的事情让它感到更的爽了。在我忙着转的时候，它却在给它的软件加新功能，懂了没？
没有一个有日常工作的程序员可以有时间可以去追赶所有从雷德蒙出来的新开发工具。因为，微软有太多该死的员工在研发新的开发工具！
现在不是1990年
微软是在八十年代成长起来的，那正式个人电脑高速发展的年代：新出厂的电脑比现有的还多。这意味着如果你的产品只能够在新电脑上跑的话，过不了一两年它也可以占领市场，既便没有人刻意“转用”你的产品。这是Word跟Excel能如此彻底取代WordPerct跟Lotus的原因之一。微软只需要等待下一波硬件升级的浪潮，然后把Windows,Word跟Excel一块卖给企业用户（有些企业还是第一次买电脑）。所以，从很多方面来说，微软从来没有学习如何促使用户从产品的N版升级到N＋1版的必要。当用户买了新电脑，他们会很高兴在新电脑上使用微软的各种最新产品，经管他们不太可能纯粹的做软件升级。这也无所谓，个人电脑市场当时在疯狂的增长。但是，现在的世界，个人电脑市场已经饱和了，并且现有的电脑都跑得不错。谢谢，微软突然意识到它花长时间等待最新的产品进入市场了。当它企图“终结”Windows 98的时候，现实是有太多的人还在使用着Windows 98，而微软得打破自己的诺言，无奈的继续给这老爷系统做多几年支持。
不幸的是，当所有人都用着98年产的电脑用得很开心的时候，像.Net、长角跟Avalon这些美丽的新技术锁定用户的企图便变得不容易实现了。即使长角真的在2006年如此发布（我此刻其实也并不相信这点），它也得花上几年的时间以获得足够的人认同它是新的开发平台。开发者，开发者，开发者跟开发者在开发软件的时候，并不卖微软那“人格分裂”开发建议的帐。
走进网络
我不能理解我说了这么多却没有提到网络。所有的开发者机会做新软件的时候都有一个选择：做网站或者做“胖客户端”在PC上跑的软件。两者的利弊很简单：网站更加容易配置（deploy），而胖客户端软件则能提供更快的反应时间以提供更有趣的用户界面。
网站更容易配置，因为它不需要安装。对用户来说，“安装”一个网络应用程序等于在浏览器地址栏里输入一个网址。我今天刚装了Google的新Email程序：按Alt+D，输入gmail，再按Ctrl+Enter。网络应用程序有着相当少的兼容性问题或者跟其它软件冲突的机会。所有使用你产品的用户都使用着你最新的版本，你不必为各种旧版本提供支持。你可以使用任何你喜欢的开发环境，只要你能够让程序在你自己的服务器上跑就好。你的程序实质上也能自动为所有地球上的电脑服务。而且，你用户的数据在实质上也能自动供地球上所有的电脑使用。
但，这些需要牺牲流畅的用户界面做代价。这边有一些网站无法做得很好的事情的例子：
1.建立快速画图的程序
2.实时带红色下划线的拼写检查
3．警告用户说他们点浏览器的关闭按钮时会丢失手头的资料
4．根据用户的操作更新部分显示内容而不访问服务器
5．建立一个键盘按键驱动而不需要鼠标的程序
6．让用户在断开网络的情况下继续操作。
这些也并不是多大不了的事情。而且有些会很快被聪明的Javascript程序员搞定。Gmail跟Oddpost这两个新的网站正巧都是做Email应用的，并且巧妙的绕过或者彻底的解决了上述的一些问题。并且，用户似乎不是很在意UI上的不足以及界面迟钝的反应。几乎我认识的所有正常人都因为某种原因非常满意基于web的Email程，无论我多么努力的向他们推荐富客户端软件。唉～更富的客户端软件其实。
所以，Web用户界面已经有八成火候了，并且即使没有新的浏览器我们也很可能可以把它做到九成半。这对绝大多数人来说已经足够好了。而此用户基础对那些选择Web做新软件开发的程序员来说也足够好了。
这也就意味着，微软的API突然间变得无足轻重了。Web程序不需要Windows！
这不是说微软并没有意识到这些事情的发生。他们当然清楚。而且，在事情表面化的时候，他们突然紧急刹车了。很有潜力的技术如HTA跟DHTML停止发展了。Internet Explorer的整个开发团队似乎消失了；他们以及好几年没有任何作为了。微软没有理由让DHTML变得比现状更好；因为这对于它的核心业务－富客户端软件太危险了。微软这些日子来的口号是：“微软在富客户端软件开发公司上压了重注。”你可以在长角的幻灯片上看到这些。来自Avalon团队的Joe Beda说：“Avalon跟长角在整体上说，是微软的根基。这说明我们相信桌面软件的威力，坐在本机前就能够玩很酷的东西。这里，我们正对桌面软件做投资，我们认为这是跟很好的方向，并且我们希望开启新一轮激动人心的……”
问题是已经太晚了。
我自己对此是有点伤心的
我自己真的是对此有点伤心。对我来说，Web很棒；但是，基于Web的软件反应慢，用户界面不统一是对日常稳定操作的一大退步。我爱我的富客户端软件，而且当我需要去使用这些软件的Web版本的时候，我会呆掉的。我每天使用的这些 软件有：Visual Studio,CityDesk,Outlook,Corel PhotoPaint,QuickBooks。 但，这些却是程序员即将要带来给我们的。没有人（我再重复一次，没有人意味着少过一百万人）会再使用Windows API做开发。风险投资商不会给做Windows应用程序的公司钱的，因为他们担心来自微软的威胁。并且，绝大多数用户不像我这么在意蹩脚的Web界面。
这里有个铁证：我注意到（并且，我从人事部门的朋友处证实了）纽约的Windows API开发并懂得C++跟COM的程序员年薪大约是十三万美金；而典型的使用托管语言（包括Java,PHP,Perl甚至ASP.Net）的Web程序员年薪是八万美元。差距是巨大的。而且当我跟在微软做客服的朋友聊天时，他们承认微软已经错过了一整代的程序员。请一个有COM开发经验的程序员每年需要十三万美金，是因为在过去约八年的时间里没有人在乎去学COM开发了。所以，你一定得找到有相当资历的程序员，并说服这些往往已经处于管理人员的层次人去处理底层的程序（神啊！救救我吧！）如处理marshalling跟monikers跟apartment线程跟aggregates跟tearoff跟其它一千万种基本上只有Don Box能理解的事情，事实上Don Box也受不了再跟这些玩意打交道了。
我讨厌说这点。但一堆开发人员已经转到Web上很久了，并且不愿转回去。大多数.Net的开发人员是开发ASP.Net的，做微软Web服务器端的开发。ASP.Net是卓越的；我已经做了十年的Web开发，但ASP.Net便硬是再往前夸了一步。但它是服务器端的技术，客户端可以使用任何桌面软件。更甚者，ASP.Net在Linux中使用Mono也跑得很好。
所有的这些兆头都对微软不妙，它无法再从API垄断上获得巨额利润了。新的API是HTML，而市场的新胜利者将会是那些能玩转HTML的人。
看样子，大家很少使用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……
原文网址：http://www.blogwind.com/Wuvist/21079.shtml
感谢hamidsforge, sheda0, unruledboy等牛人的贡献……所以，我们才能够有OpenPOP/OpenSMTP这两个开源.net email组件可以用……以及，由这两个项目合并后成为的Mail.Net。
除了这两个（Mail.Net貌似还没有发布）东西，我实在是不知道还有别的什么.Net POP3 client可以用，.Net内置的smtp功能则实在是太弱了……
最近一直在跟email打交道，用了这两个东西很久……有些经验，不敢独享，所以便发表在这里：
1。OpenPOP在处理基于UTF-8 Q编码的中文信件时会出现乱码，包括标题与信的内容
这应该是内置的MIME Parser的QuotedCoding这个类中的bug，如果不想修改OpenPOP的代码，可以使用类似：
If msg.ContentCharset = "UTF-8" Then
Subject=System.Text.Encoding.UTF8.GetString(System.Text.Encoding.GetEncoding("GB2312").GetBytes(msg.Subject))
End If
的简单代码便可以搞定。
2。OpenPOP的MIME Parser中Message类的Date属性刻意忽略了时区的影响，应该调用DateTimeInfo这个属性获得时区信息，再对Date提供的时间做修正，修正时我使用的是类似下面的代码：
Public Shared Function fixTimeZone()Function fixTimeZone(ByVal timez As String, ByRef dt As DateTime)
Dim lt As TimeSpan
Dim i As Integer
If timez.IndexOf("+") > -1 Then
timez = timez.Substring(timez.IndexOf("+") + 1)
If Char.IsDigit(timez.Chars(2)) Then
i = 2
Else
i = 3
End If
lt = TimeSpan.FromHours(Convert.ToDouble(timez.Substring(0, 2)))
lt = lt.Add(TimeSpan.FromMinutes(Convert.ToDouble(timez.Substring(i, 2))))
lt = lt.Subtract(System.TimeZone.CurrentTimeZone.GetUtcOffset(New DateTime(1999, 1, 1)))
dt = dt.Subtract(lt)
ElseIf timez.IndexOf("-") > -1 Then
timez = timez.Substring(timez.IndexOf("-") + 1)
If Char.IsDigit(timez.Chars(2)) Then
i = 2
Else
i = 3
End If
lt = TimeSpan.FromHours(Convert.ToDouble(timez.Substring(0, 2)))
lt = lt.Add(TimeSpan.FromMinutes(Convert.ToDouble(timez.Substring(i, 2))))
lt = lt.Add(System.TimeZone.CurrentTimeZone.GetUtcOffset(New DateTime(1999, 1, 1)))
dt = dt.Add(lt)
ElseIf timez.IndexOf("GMT") > -1 Then
dt = dt.Add(System.TimeZone.CurrentTimeZone.GetUtcOffset(New DateTime(1999, 1, 1)))
End If
End Function 3。OpenSMTP在发送文件名为中文的附件时候，没有设置文件名的编码信息，造成乱码。
因为添加、发送附件的时候，都是OpenSMTP内部完成的，所以必须修改它的代码，重新compile……需要修改的是Attachment.cs中ToMime这个函数，下面是我修改后的函数内容：
public String ToMime()
{
StringBuilder sb=new StringBuilder();
if (ContentId!=null)
{
sb.Append("Content-ID: <" + ContentId + ">\r\n");
}
String fname;
fname="\"=?UTF-8?Q?" + MailEncoder.ConvertToQP(name,"UTF-8") + "?=\"";
fname=fname.Replace("\r\n","");
fname=fname.Replace("==","=");
sb.Append("Content-Type: " + mimeType + ";\r\n");
sb.Append(" name=" + fname + "\r\n");
sb.Append("Content-Transfer-Encoding: " + encoding + "\r\n");
sb.Append("Content-Disposition: attachment;\r\n");
sb.Append(" filename=" + fname + "\r\n\r\n");
FileStream fin = new FileStream(encodedFilePath, FileMode.Open, FileAccess.Read);
byte[] bin;
while (fin.Position != fin.Length)
{
bin = new byte[76];
int len = fin.Read(bin, 0, 76);
sb.Append(System.Text.Encoding.UTF8.GetString(bin , 0, len)+"\r\n");
}
fin.Close();
return sb.ToString();
} OpenPOP跟OpenSMTP分别使用了两个用途一致的Email Parser，不仅是在重复发明轮子，也阻碍了两者的整合，Mail.Net的出现是很应该了……Well……其实，我觉得，Email Parser本身也应该可以做为一个独立的.Net控件，其中对于Email发送时间的时区问题以及各种五花八门的编码，其实都还是有完善的空间的。
而说到完善，即使Mail.Net顺利诞生，它其实也还不足以称为最强……因为它完全没有支持IMAP……大家可以去Google一下IMAP .Net，N多公司在靠这样的组件赚钱，而且还很贵……连php/perl等都有提供对IMAP的支持库，相比之下，.Net的程序员貌似太可怜了……不过，也不是没有人提供开源的.Net IMAP Client，CodeProject上便有一个由Rohit Joshi提供的C# IMAP Client library，虽然这个组件很粗糙，但是，我稍微封装一下便可以使用OpenPOP的Email Parser完成最基本的到不同目录查取新信等功能。
不知道，什么时候，才有一个真正的最强.Net开源邮件组件呢？如果已经有了，请拜托告诉我……