專利名稱：一種基于rfc1867規(guī)范的http協(xié)議的文件上傳方法
技術(shù)領(lǐng)域：
本發(fā)明涉及互聯(lián)網(wǎng)HTTP領(lǐng)域，特別涉及一種基于RFC1867規(guī)范的HTTP協(xié)議 的文件上傳方法。
背景技術(shù)：
文件上傳是互聯(lián)網(wǎng)的一項基本應用，現(xiàn)有上傳技術(shù)按照架構(gòu)可以分為兩類C/S
模式和B/S模式。C/S模式上傳技術(shù)，需要在客戶端和服務器端安裝專門軟件，功能 強大，但操作復雜、移植不便。常見的有FTP以及版本管理軟件。HTTP是一種基 于請求/響應(B/S)模式的協(xié)議， 一個客戶機與服務器建立連接后，發(fā)送一個請求給 服務器，請求包括請求的方法、URI (Uniform Resource Identifier)、協(xié)議版本號。 隨后還有MIME(Multipurpose InternetMail Extension protocol)信肩、包括請求修飾 符、客戶機信息和可能的內(nèi)容。服務器接到請求后，給予相應的響應信息，其格式 為一個狀態(tài)行，包括信息的協(xié)議版本號、 一個成功或錯誤的代碼，后邊是MIME信 息包括服務器信息、實體信息和可能的內(nèi)容。而基于FORM表單的文件上傳，文件 的信息和內(nèi)容正是封裝在MIME信息內(nèi)發(fā)送到服務器端的。B/S模式上傳技術(shù)包括 了三類機制RFC 1867、 PUT和WebDav。遵循RFC 1867規(guī)范的上傳方法因為定制 部署方便的優(yōu)勢，現(xiàn)今獲得廣泛應用，主流的瀏覽器、Web服務器和服務器端語言 都對此規(guī)范有很好的支持，它在用戶端的基本形式是瀏覽器中的Fonn表單，圖l為 RFC1867協(xié)議流程，處理步驟如下
1、 用戶在瀏覽器端填寫特定類型(multipart/form-data)的Form表單，并提交；
2、 服務器監(jiān)聽HTTP服務端口 (一般80)，接收表單混合數(shù)據(jù)；
3、 Web服務器按照RFC1867規(guī)范解析表單，使用服務器端程序(PHP、 JSP、 ASP)的接口變量獲得解析后的內(nèi)容進行處理；
4、 返回給用戶執(zhí)行結(jié)果。
RFC1867上傳方法通用性強，服務器端不需要提供Web外其它服務，但是其可 控性差，不會即時解析上傳過程的進度信息，無法獲得即時狀態(tài)；而且表單上傳會 受到Web服務器對每個進程分配內(nèi)存大小的限制，使得上傳的文件存在連接時間和 文件大小方面的限制，對大文件支持不好，這就導致了封裝RFC1867協(xié)議的第三方 組件大量出現(xiàn).-1、 JAVA實現(xiàn)的組件
常用的有Commons-fileupload和smartupload:前者的缺點是把上傳數(shù)據(jù)流全部 寫入內(nèi)存，導致內(nèi)存占用過多，并在上傳大文件時會受到web服務器限制；后者是 Jakarta —個項目中的組件，沒有進度控制，用戶體驗不好。目前的上傳組件支持進 度顯示，基于JAVA實現(xiàn)的接收文件處理服務需要經(jīng)過虛擬機層的編譯，效率不高。 另外存在Java實現(xiàn)的Applet小程序，可以嵌入網(wǎng)頁，繞開RFC1867實現(xiàn)上傳，其 本質(zhì)是一個小客戶端，并且需要安裝額外的JVM插件。
2、 ASP實現(xiàn)的組件
常用的有SlickUpload、 SAFileUp，其性能優(yōu)越，但是需要付費，源碼沒有公開， 就不能根據(jù)具體需求適應更改更新，而且使用ASP語言只能適用于Windows IIS服 務器。
3、 ActiveX上傳組件
使用ASP調(diào)用組件，可以完成較豐富的上傳功能，但是因為安全性因素，ActiveX 控件在用戶端會被瀏覽器控制選項禁用。

發(fā)明內(nèi)容
本發(fā)明的目的在于，為了克服現(xiàn)有技術(shù)當中Web服務器對文件長度和傳輸時間 限制、上傳組件可控性差、不支持上傳進度、可擴展性差、移植部署不便的缺點， 提供一種基于RFC1867規(guī)范的HTTP協(xié)議的文件上傳方法，通過將數(shù)據(jù)上傳至非 HTTP指定端口，由自己的數(shù)據(jù)處理段進行接收和解析，實現(xiàn)了可移植性好的對大文 件支持組件；并且通過異步通信獲得實時進度進行顯示。
所述文件上傳方法是基于UGiA-PHP-UPLOADER組件的系統(tǒng)架構(gòu)，實現(xiàn)客戶端 進度控制，服務器端數(shù)據(jù)接收、按照RFC1867協(xié)議的即時解析和狀態(tài)日志讀取，包 括以下步驟
(1) 瀏覽器提交的步驟，是指終端用戶在瀏覽器中填寫基于RFC1867規(guī)范、 屬性設置為"multipart/form-data"的表單，然后提交到客戶控制端；
(2) 客戶控制端控制的步驟，是指客戶控制端向服務器端上傳表單數(shù)據(jù)并與服 務器端通信，包括
(21)啟動定時器，并初始化XMLHTTP的實例，設置GET方法定時發(fā)送異步 請求到服務響應端輪詢狀態(tài)，得到端口號信息Port，代表服務端已做好接收數(shù)據(jù)準 備；取得父頁面表單對象，設置"action"屬性為"http:〃IP:Port"，即設置Port為新上傳 端口，開始文件的表單數(shù)據(jù)的上傳；同時，初始化進度條頁面設置抬頭信息"開始
5上傳"，顯示服務器端口；
(22)客戶控制端接到數(shù)據(jù)傳送完成信號，重組表單的數(shù)據(jù)項，將flle控件替換 成值為接收文件存放位置的text控件，然后通過HTTP向服務器端提交表單；所述 完成信號是包含表單數(shù)據(jù)的數(shù)組數(shù)據(jù)；
(3) 服務器端數(shù)據(jù)接收處理模塊處理的步驟，是指服務器端數(shù)據(jù)接收處理模塊 監(jiān)聽Port端口，接收、解析表單數(shù)據(jù)，儲存數(shù)據(jù)文件和狀態(tài)文件，包括以下步驟
(31) 數(shù)據(jù)接收處理模塊采用32位隨機數(shù)對上傳表單命名，然后確定臨時文件 存儲文件夾的個數(shù)P，采用哈希函數(shù)對文件進行均勻分配；
(32) 服務器端初始化新上傳端口 Port,將服務器端的IP地址和Port端口信息 寫入狀態(tài)文件，實例化Socket對象并監(jiān)聽新上傳端口 Port，表單數(shù)據(jù)從Port端口傳 入并由服務器端數(shù)據(jù)處理模塊的UGiA-PHP-UPLOADER組件接收處理；
(33) 遵照HTTP協(xié)議編寫200的響應頭，將響應頭回復給Port請求端口的客 戶端，隨后按照一定字節(jié)長度循環(huán)讀取Socket數(shù)據(jù)流，將讀取數(shù)據(jù)作為一個單元壓 入到一定長度的字符隊列；
(4) 服務器端響應模塊響應的步驟，是指服務器端讀取狀態(tài)日志、組織文件信 息和進度數(shù)據(jù)、回復客戶端請求。
其中，所述步驟(21)的初始化進度條頁面的步驟還包括，客戶端定時請求服 務器端日志數(shù)據(jù)，通過DOM接口處理進度條的即時狀態(tài)顯示的步驟；
所述進度條中顯示文件的相關(guān)信息包括上傳的文件名和混合數(shù)據(jù)的長度信息； 所述進度條中顯示上傳進度的信息包括上傳文件的比例、平均速度和剩余時間。
其中，所述步驟(31)包括文件上傳過程中基于哈希映射算法的文件管理；文 件上傳時分配的步驟如下首先，數(shù)據(jù)文件命名的采用32位隨機數(shù)，即時時間time() 疊加隨機數(shù)rand(0,99999)得到種子，將種子輸入MD5函數(shù)運算得到文件名name; 然后，確定臨時文件存儲文件夾的個數(shù)P，再采用哈希函數(shù)對文件名name進行映射， 哈希函數(shù)中對文件名name中每一位字符的ASCII碼求和，所得和值對P取模，哈希 函數(shù)的輸出是文件名為name的數(shù)據(jù)文件的儲存文件夾，所述哈希函數(shù)公式如下
其中，儲存文件夾數(shù)目P是系統(tǒng)初始化時根據(jù)峰值并發(fā)量確定。其中，所述步驟(33)包括以下子步驟
(331) 在循環(huán)讀取次數(shù)是隊列長度的整數(shù)倍次時，將隊列中內(nèi)容全部順次寫入 磁盤數(shù)據(jù)文件/wame.^^;
(332) 新數(shù)據(jù)壓入隊列后，按照RFC1867規(guī)范即時解析隊列中內(nèi)容，獲得上傳 狀態(tài)，寫入日志文件。
其中，所述步驟(332)包括以下子步驟
(332.1) 解析HTTP頭HEAD中內(nèi)容，獲得兩部分信息數(shù)據(jù)長度和分隔符； 所述數(shù)據(jù)長度在數(shù)據(jù)格式中用"Content-Length"標記，獲得后寫入/name.co";所述分 隔符是"Content-Type"標記、并以分號相隔賦值的第二部分，取值存入一個全局變量；
(332.2) 解析HTTP頭正文內(nèi)容，每個分隔符換行之后就是表單各控件的輸入 內(nèi)容，分號分開的各部分有"name"、 "value"、 "Content-Disposition"值；如果是文件 控件，還會有"filename"、 "Content-Type"分別代表在客戶電腦存儲路徑和上傳文件類 型；將上傳文件的內(nèi)容寫入
(332.3) 解析中遇到分界符連上兩個"-"，換行之后"ok"，代表HTTP包傳輸結(jié) 束；整理(332.2)解析出來的表單內(nèi)容和新文件的信息寫入/mw^./rw。
本發(fā)明的優(yōu)點在于
1、 本發(fā)明的服務器端初始化一個新的上傳端口 Port，將服務器IP和端口 Port 信息寫入狀態(tài)文件，實例化Socket對象并監(jiān)聽Port端口，表單數(shù)據(jù)從Port端口傳入、 由UGiA-PHP-UPLOADER組件的數(shù)據(jù)端接收處理，這樣就脫離了 Web服務器對表 單上傳的控制，擺脫了其對文件長度和傳輸時間的限制；同時不需要額外的插件就 能完成文件的上傳。
2、 本發(fā)明中分配文件采用自己設計的哈希函數(shù)，使計算效率高，并保證對文件 夾的均衡分配。
3、 本發(fā)明定時請求服務端日志數(shù)據(jù)，通過DOM接口處理進度條的即時狀態(tài)顯 示，支持文件上傳進度顯示的同時具有良好的可擴展性和可移植性。
4、 本發(fā)明中新數(shù)據(jù)壓入隊列后，按照RFC1867規(guī)范即時解析隊列中內(nèi)容，獲 得上傳狀態(tài)，寫入日志文件，避免了傳輸結(jié)束再處理時需要對整個文件讀取造成的 時間和資源的浪費。


圖1是現(xiàn)有技術(shù)RFC1867協(xié)議流程；
7圖2是本發(fā)明總體框架圖3是本發(fā)明的總體流程圖4是本發(fā)明具體實施例瀏覽器提交流程圖5是本發(fā)明具體實施例客戶端控制流程圖6是本發(fā)明具體實施例數(shù)據(jù)端處理流程圖7是本發(fā)明具體實施例服務端響應流程圖8是本發(fā)明具體實施例五次握手過程流程圖。
具體實施例方式
本發(fā)明提供的支持進度顯示的大文件上傳方法，如圖2所示涉及四類實體瀏覽 器，客戶控制端，數(shù)據(jù)接收處理端和服務響應端。
其中，瀏覽器包括了所有支持RFC1867、XMLHTTP實現(xiàn)的現(xiàn)今所有主流瀏覽器， 如Internet Explorer 、 FireFox、 Opera 。
客戶控制端是內(nèi)嵌于進度條頁面內(nèi)的軟件實體，本發(fā)明中一般由Javascript代碼 構(gòu)建，負責對上傳表單混合數(shù)據(jù)、與服務器的異步通信和控制進度條顯示。
數(shù)據(jù)接收處理端指處于Web服務器內(nèi)，負責接收和解析數(shù)據(jù)、記錄狀態(tài)文件的 軟件實體，本發(fā)明中一般由C語言代碼構(gòu)建。
服務響應端指處于Web服務器內(nèi)，負責回復客戶端請求的軟件實體，本發(fā)明中 一般由PHP語言代碼構(gòu)建。
基于RFC1867上傳文件組件一般會受到Web服務器對文件大小和傳輸時間的限 制，對大文件支持不好，本發(fā)明通過將數(shù)據(jù)上傳至非http指定端口，由自己的數(shù)據(jù) 處理段進行接收和解析，實現(xiàn)了可移植性好的對大文件支持組件；并且通過異步通 信獲得實時進度進行顯示。
如圖3所示，本發(fā)明提供的文件上傳方法包括-
步驟100:瀏覽器填寫內(nèi)容提交過程。
步驟200:客戶端上傳表單數(shù)據(jù)，與服務響應端通信控制進度顯示過程。 步驟300:數(shù)據(jù)接收處理端接收上傳數(shù)據(jù)，并按照RFC1867協(xié)議解析的過程。 步驟400:服務響應端度接受客戶端請求，按照階段讀取對應的狀態(tài)文件，將數(shù) 據(jù)返回客戶端。
如圖4所示，本實施例的瀏覽器提交流程圖。
所述瀏覽器提交過程是指終端用戶在瀏覽器中填寫表單內(nèi)容，然后提交的過程。
通過如下步驟實現(xiàn)(101) PC終端用戶在瀏覽器中(正、Firefox等)打開表單，表單中包含系統(tǒng) 需要的基于RFC1867規(guī)范的控件，其中File控件必須要有，表單類型(type)屬性設置 》"multipart/form- data"。
(102) 用戶按照控件輸入要求填寫表單，輸入File對象，如果輸入錯誤點擊"取 消"按鈕清除整個表單填寫內(nèi)容。
(103) 填寫完畢點擊"提交"按鈕啟動了輸入合法性的校驗函數(shù)，特別是對文件 名后墜進行校驗以滿足系統(tǒng)對文件類型的要求，不合格顯示"格式錯誤"提示，返回
(101)，合格就打開新頁面顯示進度條，重要的是給表單返回"false"信號阻斷HTTP 上傳，將混合文件的表單數(shù)據(jù)控制權(quán)交給客戶端，進入(201)步驟。 如圖5所示本實施例客戶端控制流程圖。
所述客戶端控制過程是指客戶端負責的向服務器上傳數(shù)據(jù)、與服務端通信以及 控制進度顯示的過程，此處客戶端由Javascript語言構(gòu)建，內(nèi)嵌于新打開進度條的頁 面中。這一過程通過如下步驟實現(xiàn)
(201) 啟動定時器，并初始化XMLHTTP的實例，設置GET方法定時發(fā)送異 步請求到服務響應端輪詢狀態(tài)，得到端口號信息代表服務端已做好接收數(shù)據(jù)準備； 取得父頁面表單對象，設置"action"屬性為"http:〃ip:port"，即設置非80的新上傳端口， 之后手動"submit"，開始混合文件的表單數(shù)據(jù)的上傳。同時初始化進度條頁面設置 抬頭信息"開始上傳"，顯示服務器端口。
(202) 定時請求服務端日志數(shù)據(jù)，通過DOM接口處理進度條的即時狀態(tài)顯示， 包括以下過程
(221) 在進度條中顯示文件相關(guān)信息，包括正在上傳的文件名和混合數(shù)據(jù)的長 度信息。
(222) 在進度條中顯示上傳進度信息，包括上傳比例、平均速度和剩余時間。 上傳比例處理需要根據(jù)返回的當前接收數(shù)據(jù)長度和文件總長度，計算比值，倍
乘以進度條總長度，得到進度即時長度，然后對獲得的控件對象長度進行賦值。在 這個過程中，還要統(tǒng)計上傳速度和剩余時間。前者的計算使用當前接收數(shù)據(jù)長度與 消耗時間的比值，消耗時間在客戶端用定時器累加一個全局變量得到；后者的計算， 使用剩余數(shù)據(jù)長度與之前得到的上傳速度的比值。速度和時間的數(shù)值經(jīng)過換算成文 字表述再顯示。比如時間統(tǒng)計以秒為單位，判斷其數(shù)值大于3600，就整除3600獲得 小時數(shù)，此步余數(shù)整除60得到分鐘數(shù)，余數(shù)為秒數(shù)。
(203) 接收到的傳送完成信號是一個容納Form表單的數(shù)組數(shù)據(jù)，通過這個數(shù) 據(jù)重組表單的數(shù)據(jù)項，關(guān)鍵是將file控件替換成值為接收文件存放位置的text控件，然后通過http提交表單，客戶端工作結(jié)束。
步驟(201)存在一種非正常中斷，用戶上傳中間點擊取消或者關(guān)閉進度頁面同 樣導致客戶端生命周期結(jié)束。
這個過程中涉及的XMLHTTP，是傳送XML格式數(shù)據(jù)的超文本傳輸協(xié)議；它 的數(shù)據(jù)傳輸形式非常靈活，通過此協(xié)議可以方便地在異構(gòu)平臺之間進行數(shù)據(jù)交換。 目前，絕大多數(shù)瀏覽器都增加了對XMLHTTP的支持，正中使用ActiveXObject方 式創(chuàng)建XMLHTTP對象，其他瀏覽器，如Firefox, Opera等通過 window.XMLHTTPRequest來創(chuàng)建XMLHTTP對象。提到的DOM是文檔對象模型 (Document Object Model),是一種與瀏覽器、平臺、語言無關(guān)的接口，用于開發(fā)者 訪問頁面的標準組件。
如圖6所示本實施例數(shù)據(jù)端處理流程圖。
所述數(shù)據(jù)端處理過程是指服務器接收、解析混合表單數(shù)據(jù)，存儲數(shù)據(jù)文件和狀 態(tài)日志的過程，通過如下步驟實現(xiàn)
(301) 命名上傳文件，為了防止沖突不能使用原文件名，采用32位隨機數(shù) (/""me)，計算方法是即時時間疊加隨機數(shù)，隨后用MD5函數(shù)運算；確定存儲文
件夾，文件夾的數(shù)目根據(jù)系統(tǒng)峰值并發(fā)量確定， 一般不選擇2的冪值，分配文件采
用自己設計的哈希函數(shù)，具體如下
/za我一)=Z ^"7(一(0) mod ; ^218，紅(0，1，2…)
對文件名中每一位字符的ASCII碼求和，其值作為分割的輸入；P是根據(jù)負載設置 的文件夾個數(shù)，限制是不能取2的冪；計算效率高并保證對文件夾的均衡分配。
(302) 初始化一個高端隨機端口，將服務器IP和端口信息寫入/"扁e.w狀態(tài) 文件，實例化Socket對象并監(jiān)聽此端口，表單數(shù)據(jù)從這個端口傳入、由這個組件的 數(shù)據(jù)端接收處理，這樣就脫離了 Web服務器對表單上傳的控制，同時擺脫了其對文 件長度和傳輸時間的限制。
(303) 遵照HTTP協(xié)議編寫200的響應頭，回復給Post此端口的客戶端，隨后 按照一定字節(jié)長度循環(huán)讀取Socket數(shù)據(jù)流，壓入一定長度的字符隊列，包括以下子 步驟
(331)在循環(huán)讀取次數(shù)是隊列長度的整數(shù)倍次時，將隊列中內(nèi)容全部順次寫入
10磁盤數(shù)據(jù)文件/wflwe.cto。
(332)新數(shù)據(jù)壓入隊列后，按照RFC1867規(guī)范即時解析隊列中內(nèi)容，獲得上傳 狀態(tài)，寫入日志文件，避免了傳輸結(jié)束再處理時需要對整個文件讀取造成的時間和 資源浪費，包括以下子步驟
(332.1) 解析HTTP頭HEAD中內(nèi)容，獲得兩部分信息數(shù)據(jù)長度和分隔符。 前者在數(shù)據(jù)格式中用"Content-Length"標記，獲得后寫入/""靴.co";后者是 "Content-Type"標記、并以分號相隔賦值的第二部分，取值存入一個全局變量。
(332.2) 解析HTTP頭正文內(nèi)容，每個分隔符換行之后就是表單各控件的輸入 內(nèi)容，分號分開的各部分有"name"、 "value"、 "Content-Disposition"等值；如果是文 件控件，還會有"filename"、 "Content-Type"分別代表在客戶電腦存儲路徑和上傳文件 類型；將上傳文件的內(nèi)容寫入/mw7"力/。
(332.3) 解析中遇到分界符連上兩個"-"，換行之后"ok"，代表HTTP包傳輸結(jié) 束；整理(332.2)解析出來的表單內(nèi)容和新文件的信息寫入/""/^./rw。
如圖7所示本實施例服務端響應流程圖。
所述服務端響應過程是指獲取狀態(tài)日志內(nèi)容，組織數(shù)據(jù)，回復客戶端請求的過
程，與數(shù)據(jù)端處理過程并行進行。通過如下步驟實現(xiàn)
(401) 服務端讀取/w"me.w文件，獲得服務器和端口信息；客戶段得到后提交 表單內(nèi)容到對應端口，初始化進度窗口。
(402) 服務端讀取yhflwe.cw7文件，獲得上傳混合數(shù)據(jù)總長度；客戶端設置進 度條。
(403) 服務端讀取/"^^./"/文件，獲得上傳文件信息，包括文件名和文件類型； 客戶端設置進度條。
(404) 服務端計算/wawe^W文件長度；客戶端以即時長度計算剩余時間等。
(405) 服務端重組/wflwe./n77表單信息，客戶端獲得form后上傳正常的80端 口 ，將控制權(quán)柄交給RFC 1867處理。
如圖8所示本實施例五次握手過程流程圖。
1權(quán)利要求
1、一種基于RFC1867規(guī)范的HTTP協(xié)議的文件上傳方法，該方法基于UGiA-PHP-UPLOADER組件的系統(tǒng)架構(gòu)，實現(xiàn)客戶端進度控制、服務器端數(shù)據(jù)接收、按照RFC1867協(xié)議的即時解析和狀態(tài)日志讀取，包括以下步驟(1)瀏覽器提交的步驟，是指通過瀏覽器填寫基于RFC1867規(guī)范、屬性設置為“multipart/form-data”的表單，然后提交到客戶控制端；(2)客戶控制端控制的步驟，是指客戶控制端向服務器端上傳表單數(shù)據(jù)并與服務器端通信，包括(21)啟動定時器，并初始化XMLHTTP的實例，設置GET方法定時發(fā)送異步請求到服務響應端輪詢狀態(tài)，得到端口號信息Port，代表服務端已做好接收數(shù)據(jù)準備；取得父頁面表單對象，設置“action”屬性為“http://IP:Port”，即設置Port為新上傳端口，開始文件的表單數(shù)據(jù)的上傳；同時，初始化進度條頁面設置抬頭信息“開始上傳”，顯示服務器端口；(22)客戶控制端接到數(shù)據(jù)傳送完成信號，重組表單的數(shù)據(jù)項，將file控件替換成值為接收文件存放位置的text控件，然后通過HTTP向服務器端提交表單；所述完成信號是包含表單數(shù)據(jù)的數(shù)組數(shù)據(jù)；(3)服務器端數(shù)據(jù)接收處理模塊處理的步驟，是指服務器端數(shù)據(jù)接收處理模塊監(jiān)聽Port端口，接收、解析表單數(shù)據(jù)，儲存數(shù)據(jù)文件和狀態(tài)文件，包括以下步驟(31)數(shù)據(jù)接收處理模塊采用32位隨機數(shù)對上傳表單命名，然后確定臨時文件存儲文件夾的個數(shù)P，采用哈希函數(shù)對文件進行均勻分配；(32)服務器端初始化新上傳端口Port，將服務器端的IP地址和Port端口信息寫入狀態(tài)文件，實例化Socket對象并監(jiān)聽新上傳端口Port，表單數(shù)據(jù)從Port端口傳入并由服務器端數(shù)據(jù)處理模塊的UGiA-PHP-UPLOADER組件接收處理；(33)遵照HTTP協(xié)議編寫200的響應頭，將響應頭回復給Port請求端口的客戶端，隨后按照一定字節(jié)長度循環(huán)讀取Socket數(shù)據(jù)流，將讀取數(shù)據(jù)作為一個單元壓入到一定長度的字符隊列；(4)服務器端響應模塊響應的步驟，是指服務器端讀取狀態(tài)日志、組織文件信息和進度數(shù)據(jù)、回復客戶端請求。
2、 根據(jù)權(quán)利要求1所述的文件上傳方法，其特征在于，所述步驟(21)的初始 化進度條頁面的步驟還包括，客戶端定時請求服務器端日志數(shù)據(jù)，通過DOM接口處 理進度條的即時狀態(tài)顯示的步驟；所述進度條中顯示文件的相關(guān)信息包括上傳的文件名和混合數(shù)據(jù)的長度信息；所述進度條中顯示上傳進度的信息包括上傳文件的比例、平均速度和剩余時間。
3、 根據(jù)權(quán)利要求1所述的文件上傳方法，其特征在于，所述步驟(31)包括文 件上傳過程中基于哈希映射算法的文件管理；文件上傳時分配的步驟如下首先， 數(shù)據(jù)文件命名的采用32位隨機數(shù)，即時時間疊加隨機數(shù)得到種子，將種子輸入MD5 函數(shù)運算得到文件名name;然后，確定臨時文件存儲文件夾的個數(shù)P，再采用哈希 函數(shù)對文件名進行映射，哈希函數(shù)中對文件名中每一位字符的ASCII碼求和，所得 和值對P取模，哈希函數(shù)的輸出是文件名為name的數(shù)據(jù)文件的儲存文件夾，所述哈 希函數(shù)公式如下p2 we (0,1,2...)其中，儲存文件夾數(shù)目P是系統(tǒng)初始化時根據(jù)峰值并發(fā)量確定。
4、 根據(jù)權(quán)利要求1所述的文件上傳方法，其特征在于，所述步驟(33)包括以 下子步驟(331) 在循環(huán)讀取次數(shù)是隊列長度的整數(shù)倍次時，將隊列中內(nèi)容全部順次寫入磁盤數(shù)據(jù)文件/rawe.必/;(332) 新數(shù)據(jù)壓入隊列后，按照RFC1867規(guī)范即時解析隊列中內(nèi)容，獲得上傳 狀態(tài)，寫入日志文件。
5、 根據(jù)權(quán)利要求4所述的文件上傳方法，其特征在于，所述步驟(332)包括 以下子步驟-(332.1) 解析HTTP頭HEAD中內(nèi)容，獲得兩部分信息數(shù)據(jù)長度和分隔符； 所述數(shù)據(jù)長度在數(shù)據(jù)格式中用"Content-Length"標記，獲得后寫入/"ame.co";所述分 隔符是"Content-Type"標記、并以分號相隔賦值的第二部分，取值存入一個全局變量；(332.2) 解析HTTP頭正文內(nèi)容，每個分隔符換行之后就是表單各控件的輸入 內(nèi)容，分號分開的各部分有"name"、 "value"、 "Content-Disposition，，值；如果是文件 控件，還會有"filename"、 "Content-Type"分別代表在客戶電腦存儲路徑和上傳文件類 型；將上傳文件的內(nèi)容寫入/w/;(332.3) 解析中遇到分界符連上兩個"-",換行之后"ok"，代表HTTP包傳輸結(jié) 束；整理(332.2)解析出來的表單內(nèi)容和新文件的信息寫入/"ame./rm。
全文摘要
本發(fā)明涉及一種基于RFC1867規(guī)范的HTTP協(xié)議的文件上傳方法，該方法基于UGiA-PHP-UPLOADER組件的系統(tǒng)架構(gòu)，實現(xiàn)客戶端進度控制、服務器端數(shù)據(jù)接收、按照RFC1867協(xié)議的即時解析和狀態(tài)日志讀取，包括(1)瀏覽器提交的步驟；(2)客戶控制端控制的步驟；(3)服務器端數(shù)據(jù)接收處理模塊處理的步驟；(4)服務器端響應模塊響應的步驟。其優(yōu)點在于(1)脫離了Web服務器對表單上傳的控制，擺脫了其對文件長度和傳輸時間的限制；同時不需要額外的插件就能完成文件的上傳；(2)計算效率高，并保證對文件夾的均衡分配；(3)支持文件上傳進度顯示的同時具有良好的可擴展性和可移植性；(4)避免了傳輸結(jié)束再處理時需要對整個文件讀取造成的時間和資源的浪費。
文檔編號H04L29/08GK101662484SQ20081011914
公開日2010年3月3日 申請日期2008年8月28日 優(yōu)先權(quán)日2008年8月28日
發(fā)明者王勁林, 鶴 白, 蘇孝強 申請人:中國科學院聲學研究所