由于项目问题是基于web的，最近一直在改进web界面，由于产品需要升级，而且升级操作是由客户在web端完成，将软件包放在本地，由web上传到后台完成更新，之前做的是TFTP更新方式，但是需要借助第三方软件，TFTP服务器，最近在网页优化的过程中感觉太麻烦，于是改成在web直接上传的方式，不借助于第三方软件。效果图：

1、文件传输：post方式，不编码，用到HTML的file属性，代码：

（1）框架部分：

 

（2）JS部分：

 

此函数包括TFTP更新和WEB更新两种方式，代码截图有点重复。。。

（3）JS文件属性函数：

（4）JS完成上传：

其中四个监听函数从上到下分别为：进度条、上传完成、上传失败和取消上传；

（5）回调函数如下：

进度条：

（6）CGI接收：

 

回调函数：

3、如果只是单个文件上传（非压缩包方式），这样目的就达到了，但是当打开server1的时候会注意到比源文件多了五行：

 

即第一行至第四行（空行），还有最后一行，我单独写了一个脚本去掉这多余的五行：

解释：第一行的意义是去掉前四行，第二行是去掉最后一行；

这样目的虽然达到了，然而在传输大文件时出现了问题，提示：

同时网页也会提示：

错误信息是文件大小已经超出了boa默认接收数据的长度，（按理说当已GET方式发送数据时才会有数据大小的限制，POST没有，具体情况还有待查证！！！也希望知道的朋友告知，谢谢！！！）

于是，我找到boa源码，打开src/defines.h,更改如下：（boa默认数据大小为1M）

然后重新make，重启boa服务器！

4、压缩包问题已经得到解决，在此感谢艳姐的提示！

压缩包其实就是个文件，因此和单个文件传输原理是一样的，而且代码也很类似，如果是单个文件，保存到后台，通过CGI将其内容读取再写到另一个文件就好了，压缩包只不过是把保存的文件格式变了而已，经验证http协议头中支持的压缩格式有两种：.zip压缩包和.rar压缩包，而这两种压缩包在http协议的MIME头部分别为Content-Type:application/x-zip-compressed和Content-Type: application/octet-stream。

zip压缩包在Linux下的压缩和解压缩命令分别为：zip和unzip;(zip all.zip *.jpg和unzip all.zip)

rar压缩包在Linux下的压缩和解压缩命令分别为：rar a all.rar *.jpg; unrar e all.rar

（在进行调用rar压缩包的相关命令时首先安装rar和unrar:sudo apt-get install rar和sudo apt-get install unrar）

代码截图如下：

http协议的MIME头部好像还有这种格式： Content-Type:application/x-gzip代表支持gzip格式的压缩包，但是由于360压缩包压缩不成该格式的，没进行测试，在网上查的得知，Linux好像有命令执行成功，等待测试成功了再继续更新！！！