DWR + FileUpload 多文件上传实例， 进度条 百分比 上传速度 文件大小...

WAR 包已更新， 修复中文乱码问题， 并采用了 Reverse Ajax技术

 

功能： 文件上传

特点： 动态显示进度， 百分比， 文件名， 文件长度， 上传速度... 剩下的自己看吧

主要技术： DWR， Apache commons FileUpload

原理： FileUpload实现上传功能， UploadListener 监听上传进度， DWR push (Reverse Ajax) 进度信息并更新页面， 实现无刷新多文件上传

运行环境： Tomcat 6， WAS 6 测试通过

 

WAR 包下载 见附件

 

 

顺便截个图：

 

评论

30 楼 javaprograms 2008-10-17  

好东西 正需要  学习一下

29 楼 aaron2007 2008-10-16  

呵呵很支持！但是测试了一些还有很多bug！因为对ext不熟悉，所以没有对程序进行修正不好意思！
1：传递中文的时候出现乱码。
2：有时候传递之后文件根本没有传递上去但是还有进度！

28 楼 itling 2008-10-16  

收藏了！！！

27 楼 jstudio 2008-10-16  

中文乱码问题。。。。。。

26 楼 kaki 2008-10-15  

Ext里面有一个现成的，做的很好楼主可以看看。

25 楼 xzj127 2008-10-14  

看了。。
      不好。。
      

24 楼 血之兽 2008-10-14  

说的挺好的

23 楼 icewubin 2008-10-12  

bruce.lu 写道

icewubin 写道

bruce.lu 写道

icewubin 写道

...
是这样的，HTTP长连接本质上相当于一个socket连接，如果采用HTTP长连接的方式最多就多占用一个socket连接，性能应该是可以接受的吧。

Icewubin 兄弟说的也不无道理。 我们在多用户并发这个极端条件下采用HTTP长连接， N个用户就会占用N个socket连接。 Application Server 会不会 connection starving？

用户在上传的时候本身就是一个HTTP长连接，如果说为了界面友好，多占一个HTTP长连接而已。
多消耗一倍的资源而已，只是连接数资源，带宽占用很小。

就是一个简单的取舍问题，对吧。

先不管这个方案真的在极端情况下有多烂，但是至少是可用的，如果访问量真的可喜的达到极端情况了，那就可以考虑其他方案应对了。

如果用你现在的方案，很快就会达到极端情况，也就是说，不同的方案，并发数负载不一样。

Hi， Icewubin, 能否详细给出你能想到的最好的方案？ 谢谢！

这无非就是做选择题：

1.绝大多数的选择就是，像EXT的例子那样，做一个假的进度条，简单高效。（目前我们公司用的就是这种，背景是客户上传的都是小文件，不超过30K，即使进度条是假的，用户也发觉不了）

2.再加一个长连接，用来实时推送当前的真实进度。

3.如果第二种方式有技术难度或者多一个长连接也不能接受的话，建议直接使用Flex的文件上传组件，功能强大的非常多，还不用自己开发。

4.局域网使用，并发数不是很高的情况下，用楼主的代码也没有太大的问题。

都是出于开发成本的考虑，做的太简单不能应用到互联网上，做的太复杂，又不可能做的有Flex组件那样强，需要一个折中，不就是做选择题么。

22 楼 differsky 2008-10-11  

楼主，在测试的时候有没有测试上传，有没有考虑上传文件或图片是中文命名，乱码问题，希望楼主改进一下......

21 楼 coolstar648 2008-10-11  

楼主，问你个问题。
你这个包里用到的servlet是哪个版本的？我用了我的servlet架包后报错。

20 楼 bruce.lu 2008-10-10  

icewubin 写道

bruce.lu 写道

icewubin 写道

...
是这样的，HTTP长连接本质上相当于一个socket连接，如果采用HTTP长连接的方式最多就多占用一个socket连接，性能应该是可以接受的吧。

Icewubin 兄弟说的也不无道理。 我们在多用户并发这个极端条件下采用HTTP长连接， N个用户就会占用N个socket连接。 Application Server 会不会 connection starving？

用户在上传的时候本身就是一个HTTP长连接，如果说为了界面友好，多占一个HTTP长连接而已。
多消耗一倍的资源而已，只是连接数资源，带宽占用很小。

就是一个简单的取舍问题，对吧。

先不管这个方案真的在极端情况下有多烂，但是至少是可用的，如果访问量真的可喜的达到极端情况了，那就可以考虑其他方案应对了。

如果用你现在的方案，很快就会达到极端情况，也就是说，不同的方案，并发数负载不一样。

Hi， Icewubin, 能否详细给出你能想到的最好的方案？ 谢谢！

19 楼 coolstar648 2008-10-10  

我们老师接了个项目，正好需要用到这种东西，本来打算自己写的。而且功能还没您写的这么全面。谢谢您提供了您的作品。感谢，打算下下来看看，不知道是否能用到我们的项目中。

18 楼 wallet 2008-10-10  

艾 看不太懂........

17 楼 lanniao 2008-10-10  

不管怎么样,下载下来研究再说

16 楼 david_3424 2008-10-09  

正好有多文件上传的需求，仔细研究下，谢谢楼主

15 楼 pdw2009 2008-10-08  

不管怎么样,下载下来研究再说

14 楼 icewubin 2008-10-07  

yufan10x 写道

后果不至于这样严重
如果是采用extjs组件的话
效果应该还算不错
在最近的项目中
正准备采用...

extjs组件的进度条是假的。而且一般都是这么做的。

13 楼 yufan10x 2008-10-07  

后果不至于这样严重
如果是采用extjs组件的话
效果应该还算不错
在最近的项目中
正准备采用...

12 楼 vern 2008-10-07  

好东西，正找它呢！谢谢楼主

11 楼 icewubin 2008-10-06  

bruce.lu 写道

icewubin 写道

...
是这样的，HTTP长连接本质上相当于一个socket连接，如果采用HTTP长连接的方式最多就多占用一个socket连接，性能应该是可以接受的吧。

Icewubin 兄弟说的也不无道理。 我们在多用户并发这个极端条件下采用HTTP长连接， N个用户就会占用N个socket连接。 Application Server 会不会 connection starving？

用户在上传的时候本身就是一个HTTP长连接，如果说为了界面友好，多占一个HTTP长连接而已。
多消耗一倍的资源而已，只是连接数资源，带宽占用很小。

就是一个简单的取舍问题，对吧。

先不管这个方案真的在极端情况下有多烂，但是至少是可用的，如果访问量真的可喜的达到极端情况了，那就可以考虑其他方案应对了。

如果用你现在的方案，很快就会达到极端情况，也就是说，不同的方案，并发数负载不一样。