html大文件传输示例

一、 功能性需求与非功能性需求

要求操作便利，一次选择多个文件和文件夹进行上传；
支持PC端全平台操作系统，Windows,Linux,Mac

支持文件和文件夹的批量下载，断点续传。刷新页面后继续传输。关闭浏览器后保留进度信息。

支持文件夹批量上传下载，服务器端保留文件夹层级结构，服务器端文件夹层级结构与本地相同。

支持大文件批量上传（20G）和下载，同时需要保证上传期间用户电脑不出现卡死等体验；
支持文件夹上传，文件夹中的文件数量达到1万个以上，且包含层级结构。

支持断点续传，关闭浏览器或刷新浏览器后仍然能够保留进度。

支持文件夹结构管理，支持新建文件夹，支持文件夹目录导航

交互友好，能够及时反馈上传的进度；

服务端的安全性，不因上传文件功能导致JVM内存溢出影响其他功能使用；

最大限度利用网络上行带宽，提高上传速度；

二、 设计分析

对于大文件的处理，无论是用户端还是服务端，如果一次性进行读取发送、接收都是不可取，很容易导致内存问题。所以对于大文件上传，采用切块分段上传

从上传的效率来看，利用多线程并发上传能够达到最大效率。

三、解决方案：

文件上传页面的前端可以选择使用一些比较好用的上传组件，例如百度的开源组件WebUploader，泽优软件的up6，这些组件基本能满足文件上传的一些日常所需功能，如异步上传文件，文件夹，拖拽式上传，黏贴上传，上传进度监控，文件缩略图，甚至是大文件断点续传，大文件秒传。 

 

在web项目中上传文件夹现在已经成为了一个主流的需求。在OA，或者企业ERP系统中都有类似的需求。上传文件夹并且保留层级结构能够对用户行成很好的引导，用户使用起来也更方便。能够提供更高级的应用支撑。

文件夹数据表结构

CREATE TABLE IF NOT EXISTS `up6_folders` (

  `f_id`               char(32) NOT NULL ,

  `f_nameLoc`               varchar(255) default '',

  `f_pid`                   char(32) default '',

  `f_uid`                   int(11) default '0',

  `f_lenLoc`           bigint(19) default '0',

  `f_sizeLoc`               varchar(50) default '0',

  `f_pathLoc`               varchar(255) default '',

  `f_pathSvr`               varchar(255) default '',

  `f_pathRel`               varchar(255) default '',

  `f_folders`               int(11) default '0',

  `f_fileCount`        int(11) default '0',

  `f_filesComplete`    int(11) default '0',

  `f_complete`              tinyint(1) default '0',

  `f_deleted`               tinyint(1) default '0',

  `f_time`                  timestamp NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

  `f_pidRoot`               char(32) default '',

  PRIMARY KEY  (`f_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

文件数据表结构

CREATE TABLE IF NOT EXISTS `up6_files` (

  `f_id`               char(32) NOT NULL,

  `f_pid`                   char(32) default '',        /*父级文件夹ID*/

  `f_pidRoot`               char(32) default '',        /*根级文件夹ID*/

  `f_fdTask`           tinyint(1) default '0',     /*是否是一条文件夹信息*/

  `f_fdChild`               tinyint(1) default '0',     /*是否是文件夹中的文件*/

  `f_uid`                   int(11) default '0',

  `f_nameLoc`               varchar(255) default '',    /*文件在本地的名称（原始文件名称）*/

  `f_nameSvr`               varchar(255) default '',    /*文件在服务器的名称*/

  `f_pathLoc`               varchar(512) default '',    /*文件在本地的路径*/

  `f_pathSvr`               varchar(512) default '',    /*文件在远程服务器中的位置*/

  `f_pathRel`               varchar(512) default '',

  `f_md5`                   varchar(40) default '',     /*文件MD5*/

  `f_lenLoc`           bigint(19) default '0',     /*文件大小*/

  `f_sizeLoc`               varchar(10) default '0',    /*文件大小（格式化的）*/

  `f_pos`                   bigint(19) default '0',     /*续传位置*/

  `f_lenSvr`           bigint(19) default '0',     /*已上传大小*/

  `f_perSvr`           varchar(7) default '0%',    /*已上传百分比*/

  `f_complete`              tinyint(1) default '0',     /*是否已上传完毕*/

  `f_time`                  timestamp NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

  `f_deleted`               tinyint(1) default '0',

  `f_scan`                  tinyint(1) default '0',

  PRIMARY KEY  (`f_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

该项目核心就是文件分块上传。前后端要高度配合，需要双方约定好一些数据，才能完成大文件分块，我们在项目中要重点解决的以下问题。

* 如何分片；

* 如何合成一个文件；

* 中断了从哪个分片开始。

如何分，利用强大的js库，来减轻我们的工作，市场上已经能有关于大文件分块的轮子，虽然程序员的天性曾迫使我重新造轮子。但是因为时间的关系还有工作的关系，我只能罢休了。最后我选择了百度的WebUploader来实现前端所需。

如何合，在合之前，我们还得先解决一个问题，我们如何区分分块所属那个文件的。刚开始的时候，我是采用了前端生成了唯一uuid来做文件的标志，在每个分片请求上带上。不过后来在做秒传的时候我放弃了，采用了Md5来维护分块和文件关系。

在服务端合并文件，和记录分块的问题&