最近的项目需要上传大文件,我使用uploadify的flash上传,可是100多M就不行了。有没有什么更好的办法能支持传几百M、上G的大文件?

解决方案 »

  1.   

    先用php内置的功能试试,传大文件时,要把php.ini 中memory_limit、max_file_uploads、post_max_size 的值改大一些,至少要大于你要上传的文件的大小。
      

  2.   

    问题就是uploadify上传100多M的文件会失败。您用过uplodify么?
      

  3.   

    这个需求需要借助于第三方控件来实现。uploadify或者其它的jqueyr,flash方式都无法传100MB的文件,甚至几十MB的文件都无法上传。
      

  4.   

    需要使用控件来传大文件。你可以看下QQ邮箱,163邮件,DBank网盘,115网盘,360网盘,百度网盘,他们都是使用控件来实现的。普通的Flash或者form方式是无法实现100MB文件上传的。而且由于客户网络环境并不稳定,所以有可能在上传过程中出现网络错误导致上传失败的问题。
      

  5.   

    网上有一个Web超大文件上传断点续传控件:http://www.cnblogs.com/xproer/archive/2012/10/26/2741264.html
    此控件支持100G文件的断点续传操作,提供了完善的开发文档,支持文件MD5验证,支持文件批量上传。
    支持浏览器:Internet Explorer 6,Internet Explorer 7,Internet Explorer 8,Internet Explorer 9
    Maxthon(遨游)1.x,Maxthon(遨游)2.x,TT浏览器,QQ浏览器,360安全浏览器,
    Chrome(Google浏览器),Maxthon3.x,360极速浏览器6.x,Firefox
    粘贴文件,简化选择文件操作:文件MD5值计算进度:文件MD5值计算完毕服务器根据MD5检测是否存在相同文件续传文件从服务器加载文件列表文件上传中文件上传完毕上传文件夹与Discuz!X2整合-后台安装断点续传控件与Discuz!X2整合-后台启用断点续传控件与Discuz!X2整合-后台断点续传控件启用成功与Discuz!X2整合-前台发帖页面与Discuz!X2整合-上传
    页面调用示例代码:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" >
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>HTTP断点续传控件与MySQL数据库演示页面(UTF-8)</title>
        <link href="HttpUploader/HttpUploader.css" type="text/css" rel="Stylesheet"/>
        <script type="text/javascript" charset="utf-8" src="HttpUploader/FileLister.js"></script>
        <script type="text/javascript" charset="utf-8" src="HttpUploader/HttpUploader.js"></script>
        <script type="text/javascript" charset="utf-8" src="HttpUploader/combinbox.js"></script>
        <script type="text/javascript" src="HttpUploader/jquery-1.3.2.min.js"></script>
        <script language="javascript" type="text/javascript">
         var cbItemLast = null;
         var cbMgr = new CombinBoxMgr();     $(document).ready(function()
         {
         cbMgr.LoadInControl("FilePanel");
         cbMgr.Init();
         });
        </script>
    </head>
    <body>
    <div id="FilePanel"></div>
    </body>
    </html>资源下载:
    cab安装包(x86)
    cab安装包(x64)
    crx安装包
    xpi安装包
    exe安装包
    开发文档
    升级日志 
    ASP.NET(C#)示例代码:
    ASP.NET-ACCESS示例
    ASP.NET-SQL2005示例
    JSP示例代码:
    JSP-ACCESS-GB2312示例
    JSP-ACCESS-UTF8示例
    JSP-SqlServer2005-UTF8示例
    JSP-MySQL-UTF8示例
    PHP示例代码:
    PHP-MySQL-UTF8示例
    Chrome,Firefox,IE断点续传控件示例(以下示例已整合IE32,IE64,Firefox,Chrome平台的插件)
    ASP.NET-ACCESS示例
    ASP.NET-SQL2005示例
    JSP示例代码:
    JSP-ACCESS-GB2312示例
    JSP-ACCESS-UTF8示例
    JSP-SqlServer2005-UTF8示例
    JSP-MySQL-UTF8示例
    PHP示例代码:
    PHP-MySQL-UTF8示例Chrome,Firefox,IE断点续传控件示例(以下示例已整合IE(x86),IE(x64),Firefox,Chrome平台的插件)
    ASP.NET-ACCESS示例
    ASP.NET-SQL2005示例
    JSP-ACCESS-GB2312示例
    JSP-ACCESS-UTF8示例
    JSP-SQL2005-UTF8示例
    JSP-MySQL-UTF8示例
    PHP-MySQL-UTF8示例
      

  6.   

    php内置功能最多只能上传十几MB的文件,如果是局域网的项目,使用PHP内置功能或许可以上传几十MB的文件。但是100MB的文件是不能成功的。非常容易产生错误。如果用户上传100MB的文件,上传到50MB时,网络错误,那就白传了。
      

  7.   

    这控件传大文件确实比较方便。上次我们做的一个大型项目也是用的这个控件。我们的需求是10G左右的文件。开始我们技术部的人本来打算直接用免费的Flash控件的,结果在百度和谷歌上面搜了许多的文章,发现都是乱写的,基本上没有一个真正的解决方案,浪费了我们公司不少的时间,大多数所谓的解决方案都是一些个人开发人员凭一时兴趣写的一点想法,自已实际也没有验证过。害得我们技术部被老大批了一通。后来技术部的人做测试,用Flash的控件选择完10G的文件后浏览器就挂掉了。内存被撑爆了,这让客户怎么用啊。最后我们还是采用的这个控件。老实说他们做的确实不错,整合也比较方便,开发文档也非常全面。最重要的就是技术支持服务比较到位。对于公司来讲也不可能随便用一些网上的免费东西。不出问题还好,出了问题找个负责的人都找不到。
      

  8.   

    在实际网络环境中一般30MB左右的文件都需要借助于控件来实现。一方面是因为国内的网络环境不太稳定,另一方面是从服务器的负载方面考虑。
    一般情况下我们的网站用户有的可能用的电信的网络,有的用的是联通的网络,有的是用的教育网,有的在南有的在北,这种复杂的网络环境导致他们访问网站的速度是不同的。有的用户网速快,比如电信的用户访问电信的机房肯定快,他上传大文件可能没有问题。但是联通的访问电信的机房可能就慢了,他上传大文件可能就出现上传超时,掉线等问题。服务器负载的问题,现在普通的文件上传技术对服务端带来的压力还是非常大的。普通的HTML上传1G的文件,服务端需要先分配1G的内存,然后开个长连接一直等待客户上传完毕。在这个期间如果有其它的用户也要上传1G的文件,那么服务端就再分配1G的内存。可以想象如果用户多了,那服务器肯定扛不住挂扯。就算是用Flash也一样,比如swfupload还有其它的几个Flash控件,他们使用的技术还是和普通的HTML一样。腾迅他们正是考虑了这个问题,所以使用控件来解决这个问题。他们通过控件将一个大文件,比如1G划分成许多的小块,每一小块大约是128KB,然后循环上传,直到上传完。这样做的优点就是减轻了服务端的压力,提高了服务端的负载能力,使得服务端能够处理的用户请求数多了。也节省了成本。
      

  9.   

    这控件传大文件确实比较方便。上次我们做的一个大型项目也是用的这个控件。我们的需求是10G左右的文件。开始我们技术部的人本来打算直接用免费的Flash控件的,结果在百度和谷歌上面搜了许多的文章,发现都是乱写的,基本上没有一个真正的解决方案,浪费了我们公司不少的时间,大多数所谓的解决方案都是一些个人开发人员凭一时兴趣写的一点想法,自已实际也没有验证过。害得我们技术部被老大批了一通。后来技术部的人做测试,用Flash的控件选择完10G的文件后浏览器就挂掉了。内存被撑爆了,这让客户怎么用啊。最后我们还是采用的这个控件。老实说他们做的确实不错,整合也比较方便,开发文档也非常全面。最重要的就是技术支持服务比较到位。对于公司来讲也不可能随便用一些网上的免费东西。不出问题还好,出了问题找个负责的人都找不到。
    传统的HTML方式已经难已满足超大文件的上传。别说是100MB,50MB对服务器来说都是非常大的,服务不仅要专门开一个socket连接接一直等待这个文件上传完毕,还要分配同等大小的内存来保存这个文件对服务器造成的压力相当的大,而且这个压力将会随着用户的增加而成几何式的增加。就算是用Flash也不行,因为目前的Flash不支持断点续传操作,也不支持文件分块操作,Flash和传统的HTML方式上传原理一样。用Flash上传100MB图片,服务器也要分配100MB的内存。10个用户同时上传100MB数据的话,就要吃掉服务器1G的内存。
    Flash上传时是将整个文件加截到内存中的,这是比较严重的问题。因为如果用户要上传5G的文件,Flash也会将5G文件全部加载到内存中。这样会严重影响用户的操作体验。因为这时用户的电脑会处于假死状态。一般用户电脑也就2G,所以直接挂掉,内存不足,或内存溢出。有些朋友试过用Flash文件上传控件来上传超大文件,但是经常遇到上传超时,或上传出错的问题。这是因为现在的Flash文件上传控件使用的技术还是和传统的HTML方式上传一样。让服务器打开一个连接,然后一直等到客户端把这个文件传完。但是在实际的网络环境中,用户的网速可能只有50KB/S,上传200MB的文件可能要花2.8小时。但是服务器的SESSION连接不可能为用户等2.8个小时,这还不考虑复杂的网络环境,比如数据包丢失的情况。如果遇到数据包丢失和网络异常的情况,那用户前面的100MB文件是白传了。这相当于浪费了用户一个小时的时间。给用户带来了极差的体验。
    对于服务器来讲,连接资源是非常有限的,就算服务器能够为一个用户等2.8个小时,如果用户访问一大,每一个用户都占用一个连接并且占用这么长时间,那么服务器的并发处理能力就变的非常低了。其它的用户就算是请求一个简单的1KB的HTML页面也必须等服务器处理完前面的用户的请求。同时Flash也无法满足超大文件的上传需求。因为超大文件上传需求有一个要求就是要保证数据传输的稳定性。比如用户上传1G的文件,已经上传了500MB,这时网突然断了,但是用户希望下次传这个文件的时侯是从最后一次上传的位置开始传输,也就是从500MB的位置开始传输,这一个需求是Flash是无法做到的。像QQ邮箱中的超大附件上传功能,115网盘中的超大附件上传控件,华为网盘(DBank),金山快盘他们都是使用控件来实现超大文件上传功能的。这样做主要是减轻服务器压力(服务器响应时间更快,并发处理能力更强),节省服务器内存(服务器不必为每个用户都分配与文件同等大小的内存),同时提高用户体验(用户可在复杂的网络环境中上传超大文件)。当然从技术角度来讲,像这些互联网知名企业也是考虑了支撑海量用户的分布式文件存储构架设计。因为他们的文件存储服务器不可能是一台,而且会动态的随着用户数的增加而增加。如果真如某些朋友所说的Flash控件就能解决超大文件上传的问题,那么腾迅也不会花那么大的力气专门为QQ邮箱开发一个控件了。