从一开始，.NET 栈就对不受管理的库提供了一流的支持。通过使用 P/Invoke，开发者可以访问大多数的 Win32 API，同时还能获得 COM 支持以访问大量的应用和第三方库。随着近期动态语言运行时的不断发展，使用 Python、Ruby 及 JavaScript 编写的脚本也加入进来了。
但.NET 开发者应该这样做么？ Clint Hill 说：不。
这项工作很棒而且工具也在不断改进着。.NET 来了，这真令人感到兴奋。但 6 年过去了，兴奋的感觉却在不断消褪。整个文化开始变得有点疯狂了。这种文化的一个原则（从广义上来说，我使用了原则）是你所用的所有组件都必须从.NET 继承下来。也就是说如果你需要一个 Web 控件库，那么它必须是个.NET C#库，因为你正使用它来构建项目。如果这个库不是免费的，或者是花钱也买不到，那你只能自己去构建了。
这会导致一些问题，往小里说会导致项目开发速度变慢以致延期。往大里说会导致开发者不再相信其他的技术了，无论这些技术是如何完美的解决问题的。现在我对这种情况感到非常失望。
Clint 将这些问题一股脑儿的回复给了畅销书作者 Jeff Atwood 所发布的一篇博文。Jeff 与知名作者 Joel Spolsky 现在正从事于一个名为 Stack Overflow 的论坛。当他们想清理其站点的 HTML 时，Jeff 对现有的库都不太满意。他的原因是：因为他们不是用.NET 编写的。
我花费了整整一周的时间为 Stack Overflow 构建了一套 HTML 清理函数，我会对此感到后悔么？肯定会的。在.NET 生态圈外有大量的清理解决方案，但针对 C#或 VB.NET 的却少之又少。我已经将核心代码贡献给社区了，所以未来的.NET 冒险家们可以将我们的代码作为其旅途上的路标了。他们可以从我们编写的简单、常规的代码中学习，然后将其继续用在 Stack Overflow 上。
Dare Obasanjo 解释了通常情况下这为什么不是一个好办法。
Jeff 尝试解决的问题是允许 HTML 标签的部分子集而排除其他的标签以避免跨站点脚本（XSS）攻击。Jeff 的解决方案的问题（社区中的很多人包括 Simon Willison 都已经指出了）在于他使用了正则表达式来过滤 HTML 输入，这种方式会假设你所得到的 HTML 都是格式良好的。而这时问题就来了，正如很多开发者所指出的那样，你不得不考虑由于很多现代的 Web 浏览器自由的 HTML 解析方式所产生的不规则 HTML。这样如果你不想将貌似安全实则有风险的 HTML 存储起来，那你就必须对常用浏览器所处理的每个 HTML 进行反向工程。这样，要想使用这种方法，Jeff 真的应该考虑使用功能更加完善的 HTML 解析器，如 SgmlReader 或者 Beautiful Soup 而不是正则表达式。
这场争论不仅仅只是关于 HTML 清理，它还触及到了.NET 文化的核心。对于.NET 开发者来说，在你每天的工作中使用非.NET 库好么？
查看英文原文： Is It Appropriate to Use Non-.NET Libraries in Your Day to Day Work?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论