關於B/S模式CGI上傳文件，遇到的問題概括(待更新。。。)

    因爲項目問題是基於web的，最近一直在改進web界面，因爲產品須要升級，並且升級操做是由客戶在web端完成，將軟件包放在本地，由web上傳到後臺完成更新，以前作的是TFTP更新方式，可是須要藉助第三方軟件，TFTP服務器，最近在網頁優化的過程當中感受太麻煩，因而改爲在web直接上傳的方式，不借助於第三方軟件。效果圖：

一、文件傳輸：post方式，不編碼，用到HTML的file屬性，代碼：

（1）框架部分：

 

（2）JS部分：

 

此函數包括TFTP更新和WEB更新兩種方式，代碼截圖有點重複。。。

（3）JS文件屬性函數：

（4）JS完成上傳：

其中四個監聽函數從上到下分別爲：進度條、上傳完成、上傳失敗和取消上傳；

（5）回調函數以下：

進度條：

（6）CGI接收：

 

回調函數：

三、若是隻是單個文件上傳（非壓縮包方式），這樣目的就達到了，可是當打開server1的時候會注意到比源文件多了五行：

 

即第一行至第四行（空行），還有最後一行，我單獨寫了一個腳本去掉這多餘的五行：

解釋：第一行的意義是去掉前四行，第二行是去掉最後一行；

這樣目的雖然達到了，然而在傳輸大文件時出現了問題，提示：

同時網頁也會提示：

錯誤信息是文件大小已經超出了boa默認接收數據的長度，（按理說當已GET方式發送數據時纔會有數據大小的限制，POST沒有，具體狀況還有待查證！！！也但願知道的朋友告知，謝謝！！！）

因而，我找到boa源碼，打開src/defines.h,更改以下：（boa默認數據大小爲1M）

而後從新make，重啓boa服務器！

四、壓縮包問題已經獲得解決，在此感謝豔姐的提示！

壓縮包其實就是個文件，所以和單個文件傳輸原理是同樣的，並且代碼也很相似，若是是單個文件，保存到後臺，經過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好像有命令執行成功，等待測試成功了再繼續更新！！！