WebService接收上传文件想法

在Web程序中上传文件是很常见的需求。利用HTTP协议上传文件的方式非常有限，最常见的莫过于使用元素进行上传。这种上传方式会将内容使用multipart/form-data方案进行编码，并将内容POST到服务器端。使用multipart/form-data编码方式与默认的application/x-url-encoded编码方式相比，在大数据量情况下效率要高很多。

使用上传文件最大的优势在于编程方便，几乎各种服务器端技术都对这种上传方式做了良好的封装，使得程序员能够直观地对客户端上传的文件进行处理。不过总体来说，这个协议并不适合做文件传输，解析数据流内容的代价相对较高，并且没有一些例如断点续传的机制来辅助，导致在上传大文件时经常会力不从心。

有朋友认为使用上传文件最大的问题在于内存占用太高，由于需要将整个文件载入内存进行处理，导致如果用户上传文件太大，或者同时上传的用户太多，会造成服务器端内存耗尽。这个观点其实是错误的。对于某些服务器端的技术，例如Spring Framework，或者早期ASP.NET 1.1时，为了供程序处理，都会将用户上传的内容完全载入内存，这的确会带来问题。但是其实协议本身并没有规定服务器端应该使用何种方式来处理上传的文件。例如在现在的ASP.NET 2.0中就已经会在用户上传数据超过一定数量之后将其存在硬盘中的临时文件中，而这点对于开发人员完全透明，也就是说，开发人员可以像以前一样进行数据流的处理。

ASP.NET 2.0启用硬盘临时文件的阈值（threshold）是可配置的：

<system.web>
  <httpRuntime
    maxRequestLength="Int32"
    requestLengthDiskThreshold="Int32" />
</system.web>

maxRequestLength自不必说，刚接触ASP.NET的朋友总会发现上传文件不能超过4M，这就是因为maxRequestLength的大小默认为4096，这就限制着每个请求的大小不得超过4096KB。这么做的目的是为了保护应用程序不受恶意请求的危害。当请求超过maxRequestLength之后，ASP.NET处理程序将不会处理该请求。这里和ASP.NET抛出一个异常是不同的，这就是为什么如果用户上传文件太大，看到的并非是ASP.NET应用程序中指定的错误页面（或者默认的），因为ASP.NET还没有对这个请求进行处理。requestLengthDiskThreshold就是刚才所提到的阈值，其默认值为256，即一个请求内容超过256KB时就会启用硬盘作为缓存。这个阈值理论上和客户端是否是在上传内容无关，只要客户端发来的请求大于这个值即可。因此，在ASP.NET 2.0中服务器的内存不会因为客户端的异常请求而耗尽。

如果我们需要在ASP.NET（如果没有特别说明，以下ASP.NET均指ASP.NET 2.0）应用中上传文件，我们一般就会直接使用控件进行文件上传。如果一个页面中存在控件，那么页面中form元素的enctype就会被自动改为multipart/form-data，而且我们可以在页面PostBack之后通过控件的引用来获得客户端通过该控件所上传得文件。不过，如果上传文件的功能需要较为特别的需求——例如需要进度条提示，控件就无能为力了。

确切地说，应该是所能提供的支持非常有限，因此一些特殊需求我们不能实现——严格说来，应该是无法轻易地、直接地实现。这样，在实现这些功能时，我们就会绕一个大大的弯。为了避免每次实现相同功能时都要费神费时地走一遍弯路，因此出现了各种上传组件。上传组件提供了封装好的功能，使得我们在实现文件上传功能时变得轻松了很多。例如几乎所有的上传组件都直接或间接地提供了进度提示的功能，有的提供了当前的百分比数值，有的则直接提供了一套UI；有的组件只提供了简单的UI，有的却提供了一整套上传、删除的管理界面。此外，有的组件还提供了防止客户端恶意上传的能力。