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

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


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