模拟HTML表单上传文件（RFC 1867）
这篇讲的是HTTP文件上传中一个被广泛使用却常被忽略的标准——RFC 1867。作者从常见的开发困惑出发：当需要上传多个文件或附带额外信息时，很多人的第一反应是将文件二进制流转化为文本（比如Base64）再作为普通字段传递。这种方式虽然能用，但代价不小：Base64编码会让数据体积直接膨胀三分之一，效率不高。 更合理的做法是遵循互联网上已有的成熟协议。RFC 1867正是为解决HTML表单文件上传而生的标准，它定义了如何在POST请求中结构化地封装文件流与元数据，这正是我们日常使用 `` 时背后的工作原理。文章具体剖析了这种协议化方式相比“土办法”的优势：更高效的数据封装、更清晰的结构，以及对多文件场景的原生支持。 对于需要构建文件上传接口的开发者而言，这篇文章清晰地指明了一条路径：与其重复造轮子，不如深入理解并运用现有的RFC标准。它不仅解决了具体的效率与规范性问题，也提醒我们去挖掘HTTP协议中那些为特定场景精心设计的解决方案。
Jscex使用BSD授权协议正式发布
这篇讲的是JavaScript异步编程框架Jscex的正式发布。作者透露，他决定好好推进这个项目，并特意用英文在GitHub上撰写了项目说明。文章提到一个有趣的细节：发布后几小时内，就收到了另一个目标相似的项目StratifiedJS作者的邮件，双方就此进行了交流。 Jscex主要针对HTML5和Node.js等新兴技术环境，旨在简化其中的异步编程模型。项目现已采用BSD授权协议开源，这意味着它将以更开放的方式进行发展。作者表示，在完成一些细节优化后，便会开始推广工作。 对于关注JavaScript异步解决方案的开发者而言，这标志着又一个有潜力的工具正式加入了开源生态。它与其他类似项目的互动，也体现了技术社区中开放交流的积极态势。
适合JavaScript 1.7中迭代生成器的异步编程机制
作者从自己之前实现的AsyncIterator（一种基于迭代生成器yield的异步编程方式）出发，指出其最初是对C# AsyncEnumerator的仿制。在与同事讨论后，他受到启发，针对JavaScript 1.7区别于C# 2.0的特性，对这种异步编程机制进行了更优雅的改进。文章的核心在于展示如何利用yield特性，将回调风格的异步代码转换为更线性的、易于理解和维护的写法。 作者通过这个案例，具体探讨了语言特性如何影响编程模型的设计。他遗憾地提到，这个非常实用的yield特性后来在ECMAScript 5标准化过程中被剔除，并将其归结为“委员会设计模式”的产物。文章在提供一个清晰异步编程思路的同时，也折射出技术规范制定过程中的一种无奈现实。
JavaScript版本的AsyncEnumerator
这篇文章从C# 2.0中yield关键字和AsyncEnumerator的异步简化功能出发，探讨了异步编程模型的演变历程。作者为便于JavaScript开发者理解，亲自用JavaScript实现了一个AsyncEnumerator，展示了如何将C#中的迭代器概念移植到Web环境中。核心实现思路基于ES6的generator函数，通过yield来暂停和恢复执行，模拟异步操作的流程，同时结合Promise处理回调，使得异步代码更线性易读。JavaScript版本的巧妙之处在于，它保留了C# yield的简洁性，又适应了JavaScript的单线程事件循环，巧妙桥接了不同语言的异步模型。文章通过具体代码示例和实现细节，帮助读者直观看到如何用现代JavaScript特性优化异步处理，避免回调嵌套，为实际项目中的异步策略选择提供了实用参考。
Silverlight与微软技术（下）：微软技术与技术学习
这篇讲的是对微软技术“更新太快、追得累”这一流行看法的个人反思。作者从自身近十年追随.NET平台的体验出发，提供了不同的视角。 他观察到，尽管微软技术产品线众多，但在.NET这个核心领域，技术的迭代和过渡做得相当平滑和连贯。作者坦言自己并没有感受到社区内外常说的疲惫感。相反，正是这些丰富的技术体系拓宽了他的视野，让他对许多技术模式和思路变得熟悉，面对新技术时“新奇感”减少，更多的是感到自然与稳妥。 基于这段经历，文章进一步探讨了个人在面对庞大技术生态时的学习心态与方法。作者认为，关键在于抓住主线、深入理解其演进逻辑，而非被表面的快速变化所困扰。这种从容源自长期的积累与对技术脉络的把握，为焦虑于技术更迭的开发者提供了一种值得借鉴的思路。
Silverlight与微软技术（上）：微软抛弃Silverlight了么？
这篇讲的是微软在PDC大会上副总裁Bob Muglia的言论如何引发了社区对Silverlight命运的猜测。作者从“微软是否要抛弃Silverlight”这一热议出发，深入剖析了事件背后的真相与社区中的误解。 文章核心指出，微软的策略调整并非放弃Silverlight，而是将其应用于移动端（如Windows Phone 7）开发，同时用HTML5补足跨平台能力。作者批评了部分技术评论者连Silverlight是WP7基础开发平台这一基本事实都未厘清，便跟风散布“抛弃论”，这种捕风捉影的讨论偏离了技术本质。 作者呼吁技术讨论应回归事实，关注平台演进的实际逻辑，而非追逐夸张的舆论风向。对于关心微软技术栈发展的开发者而言，这篇文章有助于厘清当时的战略转向，避免被片面的信息误导。
分清“语言/规范”以及“平台/实现”，以及跨平台.NET开发
这篇讲的是如何理清.NET及跨平台开发中常被混淆的几个核心概念。作者从技术演进的角度切入，指出早年“语言即平台”（如C/C++）的观念，与如今以.NET、Java为代表的“通用平台”及多语言实现共存的现状已截然不同。 文章重点辨析了“语言/规范”与“平台/实现”这两对关键概念。语言或规范（如C#、F#）定义了语法规则，而平台与实现（如.NET Framework、.NET Core、Mono）则提供了具体的运行环境和库支持。作者强调，只有将这两者清晰区分，才能准确理解为何同一语言可在不同平台运行，或同一平台能承载多种语言。 这种概念上的厘清，对实际跨平台开发至关重要。它能帮助开发者摆脱历史观念的束缚，更精准地选择技术栈、诊断兼容性问题，并理解社区讨论中的各种技术取向。文章实际上为陷入概念迷雾的.NET开发者提供了一份清晰的认知地图。
PDC 2010：C#与Visual Basic的未来（下）
这篇讲的是C#之父Anders Hejlsberg在PDC 2010大会上，对.NET语言未来演进路径的一次重要擘画。演讲的核心聚焦于两项即将引入C#与Visual Basic的革命性特性：**异步编程**与**编译器即服务**。 作者从Anders的现场演示出发，重点剖析了异步编程如何通过引入`async`和`await`这两个简洁关键字，彻底革新了处理I/O密集型任务的编程模型。它使得开发者能以近乎同步代码的流畅逻辑，编写出高效、非阻塞的异步操作，极大提升了代码的可读性与可维护性。 另一部分则初步探触了“编译器即服务”这一更前沿的构想。它旨在将编译器的能力（如语法树、语义分析）作为一种服务开放出来，让开发者能够编写在编译期分析和操作代码的工具与扩展。这不仅是.NET生态中元编程的强大基础，也为代码分析、智能工具和领域特定语言（DSL）的创建打开了全新的大门。 Anders的分享清晰地勾勒出，未来语言设计不仅追求运行时性能与表达力，更致力于通过提升开发体验和赋予元编程能力，来应对软件复杂性不断增长的挑战。
PDC 2010：C#与Visual Basic的未来（中）
这篇总结聚焦于PDC 2010上Anders Hejlsberg关于C#与Visual Basic未来方向的关键演讲，重点剖析了“异步”与“编译器即服务”两大特性。不同于逐句翻译，作者以Anders的视角，用简捷的方式重构了演讲的核心内容。 文章深入阐述了async和await这两个关键字背后的实现原理。它解释了编译器如何将异步代码转换为状态机，从而在保持代码简洁性的同时，避免了传统回调模式的复杂性，并显著提升了应用的响应性。对于“编译器即服务”，文章探讨了其如何将编译器能力开放给开发者，使得在运行时分析和生成代码成为可能，这为元编程和开发工具链带来了新的想象空间。 作者通过梳理Anders对这两项特性的设计哲学与技术细节，清晰地勾勒出未来语言演进将如何更深入地解决并发编程的复杂性，并拓展开发者的工具边界。对于想理解现代C#核心语言特性起源和设计思想的开发者来说，这篇复盘提供了扎实的技术洞察。
PDC 2010：C#与Visual Basic的未来（上）
这篇讲的是PDC 2010大会上关于C#与Visual Basic未来发展方向的探讨。PDC作为微软的重要开发者会议，常常发布前沿技术信息，本文基于Anders Hejlsberg的演讲内容展开。文章详细分析了C#和
我们不是牛人，所以还是老老实实跟着兴趣走吧
作者从技术同行周筠老师关于“兴趣决定论”的博文出发，分享了自己对“兴趣重要性”的深度认同与亲身验证。有趣的是，这个例证并非来自他所熟悉的技术领域——相反，他坦言自己对诸多技术都感兴趣，反而很难找出一个对比鲜明的例子。因此，他选择了近几个月“找回”的爱好——弹钢琴，作为阐释这一观点的最佳载体。 这篇文章跳出了典型的技术成长叙事，用一个看似“不务正业”的兴趣案例，探讨了驱动人持续投入与获得内在满足感的根本动力。作者想传递的核心观点是：即使并非天才，普通人沿着自己真正的兴趣路径走，也能收获深刻的体验与成长。这或许能给忙于追赶技术浪潮的从业者一些启发——在代码和架构之外，那些纯粹因为热爱而做的事，可能同样定义着我们是谁，并为我们提供不可或缺的能量与平衡。
对HTML做白名单过滤
这篇讲的是如何构建一个安全高效的HTML白名单过滤系统。作者直指当前许多应用在处理用户富文本输入时，直接采用黑名单方式过滤危险标签或属性的不足——黑名单容易遗漏，面对复杂嵌套结构时更是防不胜防。
文章的核心方案是转向基于DOM解析的白名单机制。它强调在解析后操作节点，逐一检查标签、属性、事件处理器是否在预先定义的“安全名单”中，不在名单内则果断移除。文中还讨论了处理标签嵌套、属性值、以及如何安全地处理 ``、`` 等常用标签的具体实践，比如对 `href`、`src` 属性进行协议校验，阻止 `javascript:` 等伪协议。
相比于简单粗暴的黑名单正则替换，这种方案更精确、可维护，能有效防御包括XSS在内的多种注入攻击。作者通过这个案例展示了一种“默认拒绝”的安全思维：在内容安全领域，明确允许什么，往往比试图禁止所有危险项更可靠。
服务器端执行JavaScript代码
这篇讲的是作者为了在服务器端复用客户端的 JavaScript 验证逻辑，解决代码重复和维护难题，在 .NET 平台上对几款主流 JavaScript 执行引擎进行的一次深度体验和评测。 文章从一个常见痛点出发：客户端验证逻辑无法直接共享到服务器端，导致需要维护两套代码。为了解决这个问题，作者尝试了 IronJS、Jint、Jurassic 等引擎，并用它们执行了同一个简单的验证函数来实际检验。他发现 IronJS 性能虽好但功能不全，Jint 在多线程下有瓶颈，Jurassic 则存在一些兼容性问题，甚至无法正确运行常见的 showdown.js 库。 最让作者感到意外的结论是，在 .NET 平台上目前最靠谱的选择反而是通过 IKVM.NET 桥接的 Java 项目 Rhino JavaScript。尽管它使用起来稍显麻烦，但功能完整、调试支持好，性能也能满足实际需求。作者甚至分享了用它在自己的博客上处理近4000条评论的性能数据。 作者基于此打算将博客的 Markdown 转换逻辑迁移到基于 Rhino 的服务器端实现上。他的评测过程具体而实用，为在 .NET 生态中寻找可靠 JavaScript 执行方案的开发者提供了直接的参考和避坑指南。
使用Narcissus解析JavaScript代码
作者在开发一个JavaScript实验项目时，需要在客户端直接将JavaScript代码解析成语法树——也就是说，用JavaScript实现一个JavaScript解析器。这类工具其实不少，像yacc、lex、bison都有对应的JavaScript版本，用ANTLR生成JavaScript目标代码也是一种选择。不过作者希望快速投入实验核心，不想在解析器构建上耗费太多时间，于是把目光投向了现成的方案。 经过权衡，作者最终选择了Narcissus。这是一款由Mozilla开发者编写的JavaScript解析器，完全用JavaScript实现，可以直接将源码转换为抽象语法树（AST）。它的轻量和现成可用的特点，正好满足了作者“避免重复造轮子”的需求。文章从实际的开发痛点出发，对比了多种解析方案的优劣，并给出了明确的技术选型依据。对于同样需要在浏览器或Node.js环境中处理JavaScript代码结构的开发者来说，Narcissus提供了一个现成且高效的起点。
当类型转换表达式遇上自定义转换操作
作者在使用System.Json类库时遇到了一个棘手的限制：它只为少数特定类型（如Int32、String）定义了隐式转换，既无法直接转为泛型类型，也无法获得object引用来动态处理。这让他想实现一个通用的JsonValue到任意T类型的转换器时犯了难。 问题的根源在于System.Json的类型转换机制不够灵活。为了解决它，作者巧妙地借助了.NET中“运行时构建表达式树并编译成动态代码”的能力。他编写了一个JsonConverter辅助类，在其泛型静态构造函数中，核心思路是：为每种目标类型T动态生成一个转换Lambda表达式。 具体实现上，代码首先创建一个代表输入JsonValue参数的表达式，然后使用Expression.Convert方法构建将这个参数转换为类型T的表达式，最后将整个转换逻辑编译成一个可重复使用的Func委托。这样，.NET的运行时类型系统会为每种T自动选择最合适的转换路径，完美绕开了原有库的限制。 这个技巧的巧妙之处在于，它将编译时固定的类型转换问题，转化为运行时按需生成的转换代码，既优雅又高效。对于任何需要突破静态类型转换限制、实现类似动态分发逻辑的场景，这种基于表达式树的动态编译思路都提供了清晰的解决方案。
国内计算机图书真的不贵
这篇文章从社区里常见的“书好贵”抱怨切入，指出现实中很多人可能误解了国内计算机图书的真实定价。作者没有停留在情绪化的讨论上，而是直接将国内计算机类书籍与国外同类产品进行价格对比，用具体数据揭示了两者之间的显著差距。这种对比清晰地表明，国内计算机图书的定价实际上相当亲民，远没有达到“昂贵”的程度。 文章的核心观点通过实实在在的价格对比得以支撑，让读者能直观感受到国内外市场的差异。对许多开发者而言，这或许能改变其对购书成本的固有认知，有助于更理性地看待国内技术出版物的性价比。整体上，它用简洁的论证澄清了一个常见的误区，提醒读者在讨论成本时考虑更全面的市场背景。
JsonMe - 合约与类型分离的轻量级JSON映射类库
JsonMe 是一个专注于解决 .NET 平台 JSON 序列化/反序列化特定痛点的轻量级类库。作者在实际开发中发现，尽管 JavaScriptSerializer、DataContractJsonSerializer 等现有方案功能完备，但在某些场景下（比如需要更灵活的类型映射或处理复杂合约时）显得过于冗重或约束较多。为应对这类需求，他设计了 JsonMe，其核心思路是将数据“合约”（即类的结构定义）与 JSON 的具体映射逻辑分离，让开发者能更直观地控制序列化行为。 JsonMe 的最大特点是“轻”与“分”。“轻”体现在代码简洁、依赖少，专注于做好 JSON 与对象之间的基础转换；“分”则是指它允许你在不修改业务模型类的情况下，通过外部映射定义来指定字段如何对应 JSON 键名，这为处理遗留系统集成或第三方 API 对接时常见的命名不一致问题提供了优雅解法。例如，你可以将一个 C# 属性映射到 JSON 中完全不同的字段名，而无需改动属性本身。 如果你在项目中经常需要快速实现灵活的 JSON 绑定，同时又希望保持业务对象的纯净，JsonMe 提供了一个值得考虑的简洁选项。它的设计体现了一种务实思路：用最小化的代码解决最具体的问题。
Padding Oracle Attack实例分析
这篇讲的是Padding Oracle Attack的原理与实战分析。作者从翻译一篇经典的攻击技术文章入手，重点介绍了PadBuster这个自动化工具如何在ASP.NET等系统中实施Padding Oracle攻击。文章通过一系列详细实例
在Visual Studio中使用MonoTouch开发iOS应用程序（下）：开发体验
对于熟悉.NET的开发者来说，编写iOS应用程序的一个高效选择是使用MonoTouch。这篇教程紧接前文环境搭建，深入讲解了如何利用Visual Studio、Interface Builder与少量MonoDevelop配合，完成一个完整iOS应用的开发体验。 作者从创建一个空白解决方案和iPhone项目开始，演示了如何在Interface Builder中拖拽按钮、定义Outlet并建立连接。关键的一步是在Visual Studio中配置一个平行的解决方案与项目文件，通过引用MonoTouch的dll，让开发者能在熟悉的VS环境中享受智能提示和C# 3.0/4.0语法，同时保证代码与Mac端兼容。 实际编写时，仅需在`FinishedLaunching`方法中为按钮添加事件处理逻辑。整个流程中，开发者可在VS中完成大部分编码与调试，最终回到Mac端的MonoDevelop编译并在模拟器运行。此外，文章还探讨了单元测试的配置，以及通过创建.NET 3.5项目在Windows上进行更多本地测试的可行性与利弊。 整套工作流下来，开发者几乎能完全留在Windows环境下完成核心编码与测试，只有在需要查看模拟器实际效果时才切换到Mac端。这对于追求效率的.NET开发者而言，无疑打通了一条值得尝试的跨平台开发路径。
在Visual Studio中使用MonoTouch开发iOS应用程序（上）：环境配置
这篇文章详细记录了作者如何搭建一个以 Visual Studio 为核心，在 Windows 和 Mac OS X 之间协同工作，最终通过 MonoTouch 开发 iOS 应用程序的环境。 作者从选择 MonoTouch 的动机出发，解释了它让 .NET 开发者能复用熟悉的 C# 语言和大量类库（如 Json.NET）来开发 iOS 应用的核心优势。文中特别指出，MonoTouch 采用 AOT 编译方式，并会对应用体积带来约 3MB 的增量。 搭建环境的关键步骤包括：在 Windows 虚拟机（VirtualBox）中与 Mac OS X 共享项目文件夹，以便在 Windows 上用 Visual Studio 编写代码，同时在 Mac 上使用 Interface Builder 设计 UI。文章逐步演示了如何配置网络共享并在 Mac 中创建便捷的软链接。最后，说明了安装 Mono、MonoDevelop、iOS SDK 及 MonoTouch 试用版的具体过程，并提及试用版只能在模拟器上运行，发布至 App Store 需要购买授权。 整个配置方案为 .NET 开发者开辟了一条相对熟悉的 iOS 应用开发路径。
