java 文件上传 插件_Java文件上传组件，Fastupload 0.31 功能完备速度飙升

Fastupload

0.31版本上周已经发布，因为工作的关系，只到今天才有点时间来写一些0.31版本中深层次的东西。fastupload以前的版本，尽管在性能上取得

了不小的进步，但只支持解析文件，不支持解析非文件的内容，因为HttpFileUploadParser这个类来解析ServletRequest的输

入流的过程中，忽略非文件的请求数据。举个列子来说，假如表单中有两个input标签，一个是文本输入控件，一个是文件输入控件，经过

HttpFileUploadParser解析后，只会把文件类型请求的数据保存在指定的目录下。

在fastupload项目编写之初，考虑的是如何把文件类型请求的数据保存到文件中去，在这种目标下，如何处理非文件类型请求数据？自然的”选择“了忽略这种方式。

在fastupload 0.23发布后 ，原计划是在下一个版本中提供对struts2、spring

mvc3的注解(annotation)一些高级特性的支持，有些网友对fastupload提出了批评和建议，其中，网友silence1214

提出了对于非文件类型请求数据的处理问题。经过仔细考虑后，决定先实现非文件类型请求数据的处理。于是，0.31版本中，类HttpMemoryUploadParser能处理非文件类型的请求数据了，具体的示例代码如下，

01

MultiPartDataFactory

mpdf = new MemoryMultiPartDataFactory("utf-8");

02

HttpMemoryUploadParser

uploadParser = new

HttpMemoryUploadParser(request,

mpdf);

03

long

s =

System.currentTimeMillis();

04

List

list = uploadParser.parseList();

05

06

File

dir = new File(System.getProperty("user.home") +

"/memoryupload/dump");

07

dir.mkdirs();

08

09

for

(MultiPartData e : list) {

10

String

target = String.format("%s/%s",

dir.getAbsolutePath(), e.getFileName());

11

if

(e.isFile()) {

12

e.toFile(target);

13

}

14

else

{

15

System.out.println(new

String(e.getContentBuffer()));

16

}

17

}

18

19

System.out.format("memoryupload

cost: %d %n",

System.currentTimeMillis() - s);

当新建一个HttpMemoryUploadParser类的实例时，首先读取ServletRequest输入流中所有的字节，写入内存缓冲中，parseList()函数从这片大的缓冲中解析上传表单中的内容，返回一个包含MultiPartData类型的数组。

这里的MultiPartData是multipart/form-data中两个边界(boundary)中数据的一个抽象。上传请求数据中的头

部信息表明这部分数据是一个文件中的内容，还是输入控件中“输入”的内容，MultiPartData.isFile()函数则实现了这个判断功能，此

外，MultiPartData.getContentHeaderMap()函数把这些“头部信息”以Map的形式暴露出来，供外部代码使用。

在成功解析上传表单后，每个MultiPartData都有一个自己的一片内存缓冲，用于保存解析后所得出的数据，如果需要把这些数据保存到文件中

去，则调用toFile()函数，如果想直接获得数据，则调用getContentBuffer()函数。需要提醒的是，创建

MemoryMultiPartDataFactory时，指定了字符集，MemoryMultiPartDataFactory在创建

MemoryMultiPartData对象时，对把name属性转换成所指定的字符集字符串，对于所解析出的内容，并不做字符集的转换，因为数据已经读

入到内存中，开发人员可以对其转换成所期望的字符集，不象MultiPartTextFile写入时，需要强制进行字符集转换。

对于支持非文件类型请求后，fastupload和Apache Commons

FileUpload的性能相比，是一个什么样的结果呢？继续做一个实际的测试对比，分别用fastupload的

HttpMemoryUploadParser和Apache Commons

FileUpload的相类似的API接受1.7M、1.7M和1.2M的图像文件。得到下面的测试结果，单位毫秒。

memoryupload cost: 10

memoryupload cost: 8

memoryupload cost: 11

memoryupload cost: 8

memoryupload cost: 12

memoryupload cost: 8

memoryupload cost: 48

memoryupload cost: 14

memoryupload cost: 346

memoryupload cost: 11

memoryupload cost: 8

memoryupload cost: 9

memoryupload cost: 14

memoryupload cost: 8

memoryupload cost: 14

memoryupload cost: 9

memoryupload cost: 10

memoryupload cost: 14

memoryupload cost: 10

memoryupload cost: 12

Apache Common File Upload costs: 379

Apache Common File Upload costs: 29

Apache Common File Upload costs: 66

Apache Common File Upload costs: 87

Apache Common File Upload costs: 92

Apache Common File Upload costs: 24

Apache Common File Upload costs: 195

Apache Common File Upload costs: 286

Apache Common File Upload costs: 25

Apache Common File Upload costs: 314

Apache Common File Upload costs: 50

Apache Common File Upload costs: 84

Apache Common File Upload costs: 217

Apache Common File Upload costs: 86

Apache Common File Upload costs: 314

Apache Common File Upload costs: 120

可以看出，两组数据中，最快的单次时间比是8:24，如果比较两组数据中前10个的平均值，这个比是8.8:51，如果比较最慢的10个数据的平均值，是49.6:229,

最慢的单次比值是 346:379，相差不大，平均时间比是29.2:140。

总的说来，得益于改进的BM查找算法，HttpMemoryUploadParser解析速度比Apache Commons

FileUpload的要快好很多，速度上占据了绝对的优势，从最慢那个对比来看，fastupload仍然有提高的空间，比如说尽可能的优化内存的使

用。

开源fastupload项目纯粹我当时的一个想法，没想到引起了广大网友的注意，不屑、质疑、建议、批评的都有，不管怎么说，你们的声音是fastupload项目前进中动力的重要部分，这里特别感谢广大网友。