專利名稱：一種上傳和接收文件的方法、系統(tǒng)及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)，特別涉及一種上傳和接收文件的方法、系統(tǒng)及裝置。
背景技術(shù)：
隨著網(wǎng)絡(luò)技術(shù)的飛速發(fā)展，越來越多的用戶會將自己的文件上傳到服務(wù)器供其他用戶使用。
目前用戶通過Web網(wǎng)頁上傳圖片、視頻、音頻等文件的方式包括
用戶通過客戶端連接到服務(wù)器，并打開上傳頁面； 用戶在上傳頁面選擇需要上傳的文件后點擊上傳，上傳頁面將文件發(fā)送給服務(wù)器； 服務(wù)器先將接收的文件保存在內(nèi)存中，等到文件接收完成后，再將文件保存到硬盤中。 由于傳統(tǒng)的頁面對于上傳文件的大小是有限制的，比如在傳統(tǒng)頁面的web. config配置中，上傳文件大小是4M，這時只允許用戶上傳不大于4M的文件。 用戶通常上傳的文件都大于web. config配置中允許上傳的文件的容量，所以現(xiàn)有的方式中，可以通過修改web. config配置中的上傳的文件的容量，使上傳文件的大小不受限制。 但是如果用戶要上傳的文件容量比較大，比如1G的文件，由于服務(wù)器需要先將接收的文件保存在內(nèi)存中，所以要求服務(wù)器的內(nèi)存比較大，如果服務(wù)器的內(nèi)存不夠大，還是無法上傳文件。 綜上所述，目前通過Web網(wǎng)頁上傳大容量的文件，對于服務(wù)器的配置要求比較高。

發(fā)明內(nèi)容
本發(fā)明實施例提供一種上傳和接收文件的方法、系統(tǒng)及裝置，用以解決現(xiàn)有技術(shù)中存在的通過Web網(wǎng)頁上傳大容量的文件，對于服務(wù)器的配置要求比較高的問題。
本發(fā)明實施例提供的一種上傳文件的方法包括 客戶端在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊； 所述客戶端將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。
本發(fā)明實施例提供的一種接收文件的方法包括
服務(wù)器將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置； 所述服務(wù)器在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述指定位置中的數(shù)據(jù)塊合并成文件。
本發(fā)明實施例提供的一種傳輸文件的系統(tǒng)包括 客戶端，用于在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊，將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送； 服務(wù)器，用于將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置，在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述指定位置中的數(shù)據(jù)塊合并成文件。
本發(fā)明實施例提供的一種客戶端包括 劃分模塊，用于在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊； 發(fā)送模塊，用于將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。
本發(fā)明實施例提供的一種服務(wù)器包括 接收模塊，用于將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置； 處理模塊，用于在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將
所述指定位置中的數(shù)據(jù)塊合并成文件。 本發(fā)明實施例客戶端在接收到的HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊；所述客戶端將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。由于將大容量文件分成多個數(shù)據(jù)塊，分別上傳，從而降低了對于服務(wù)器的配置的要求，滿足了用戶上傳文件的需求，提高了用戶體驗以及文件上傳的可靠性。


圖1為本發(fā)明實施例上傳文件的方法流程示意圖； 圖2為本發(fā)明實施例接收文件的方法流程示意圖； 圖3為本發(fā)明實施例傳輸文件的方法流程示意圖； 圖4為本發(fā)明實施例傳輸文件的系統(tǒng)結(jié)構(gòu)示意圖； 圖5為本發(fā)明實施例客戶端的結(jié)構(gòu)示意圖； 圖6為本發(fā)明實施例服務(wù)器的結(jié)構(gòu)示意圖。
具體實施例方式
本發(fā)明實施例客戶端將需要發(fā)送的文件分成多個數(shù)據(jù)塊，將每個數(shù)據(jù)塊按順序發(fā)
送，服務(wù)器將接收到的數(shù)據(jù)塊在合并成文件，由于將文件分成多個數(shù)據(jù)塊發(fā)送，服務(wù)器一次
只會收到一個數(shù)據(jù)塊，然后再將收到的數(shù)據(jù)塊存儲到指定位置，這樣只需要保證服務(wù)器的
內(nèi)存能夠存儲一個數(shù)據(jù)塊就可以，從而降低了對服務(wù)器配置的要求。 下面結(jié)合說明書附圖對本發(fā)明實施例作進一步詳細描述。 如圖1所示，本發(fā)明實施例上傳文件的方法包括下列步驟 步驟400、客戶端在接收到的HTTP(Hyper Text Transport Protocol，超級文本傳
送協(xié)議)請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊。 步驟401、客戶端將多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。 在具體實施過程中，用戶進入上傳頁面，選中需要上傳的文件并點擊上傳后，會發(fā)
送一個HTTP請求，其中該HTTP請求中包含上傳信息(即multipart/form-data信息)。 分塊條件可以根據(jù)需要進行設(shè)定，比如設(shè)定分塊數(shù)量，還可以設(shè)定分成的一個數(shù)
據(jù)塊的容量，等等。 —種較佳的方式是根據(jù)服務(wù)器的內(nèi)存容 設(shè)定分成的數(shù)據(jù)塊的容量，比如服務(wù)器的內(nèi)存容量為1G，則可以設(shè)定數(shù)據(jù)塊的容量為100M。 客戶端可以向服務(wù)器發(fā)送獲取內(nèi)存容量的命令，服務(wù)器將自身內(nèi)存的容量返回給客戶端，從而客戶端獲得內(nèi)存容量。當然，其他能夠獲得服務(wù)器20的方式同樣適用本實施例。 發(fā)送順序同樣可以根據(jù)需要進行設(shè)定，比如按照數(shù)據(jù)先后順序，即將文件分成多個數(shù)據(jù)塊，每個數(shù)據(jù)塊發(fā)送的順序就是對應(yīng)的數(shù)據(jù)在文件中的順序； 還可以為每個數(shù)據(jù)塊分配一個數(shù)字，并將分配的數(shù)據(jù)置于對應(yīng)的數(shù)據(jù)塊中，按照設(shè)定的數(shù)字順序，將多個數(shù)據(jù)塊以及設(shè)定的數(shù)字順序向服務(wù)器發(fā)送。 假設(shè)有4個數(shù)據(jù)塊，對應(yīng)的數(shù)字為1，2，3和4，數(shù)字順序為4、3、2、1，則在發(fā)送的時候，按照數(shù)字順序發(fā)送對應(yīng)的數(shù)據(jù)塊，數(shù)字順序可以獨立發(fā)送給服務(wù)器20，也可以至于其中一個數(shù)據(jù)塊中，較佳的方式是置于第一個發(fā)送的數(shù)據(jù)塊中。 客戶端在劃分成數(shù)據(jù)塊后，可以在數(shù)據(jù)塊中添加文件標識，這樣可以讓服務(wù)器知道哪些數(shù)據(jù)塊屬于同一個文件。 客戶端10還可以在每個數(shù)據(jù)塊中增加一個狀態(tài)標識(比如l，指示還有數(shù)據(jù)塊，O指示是最后一個數(shù)據(jù)塊)，這樣服務(wù)器根據(jù)數(shù)據(jù)塊中的狀態(tài)標識可以確定該數(shù)據(jù)塊是否是收到的最后一個數(shù)據(jù)塊。 如圖2所示，本發(fā)明實施例接收文件的方法包括下列步驟 步驟500、服務(wù)器將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置。 需要說明的是，服務(wù)器接收的數(shù)據(jù)塊是按照本實施例的方法上傳的數(shù)據(jù)塊。 步驟501、服務(wù)器在數(shù)據(jù)塊全部接收完成后，根據(jù)客戶端上傳數(shù)據(jù)塊的方式，將指
定位置中的數(shù)據(jù)塊合并成文件。 在具體實施過程中，如果客戶端按照數(shù)據(jù)先后順序，則服務(wù)器根據(jù)收到的數(shù)據(jù)塊的順序，對數(shù)據(jù)塊進行合并(可以全部接收完成后在一起合并；也可以在收到第二個數(shù)據(jù)塊就和第一個數(shù)據(jù)塊進行合并，在收到第三個數(shù)據(jù)塊就和前面的數(shù)據(jù)塊進行合并，依次類推)。 如果客戶端按照設(shè)定的數(shù)字順序，將多個數(shù)據(jù)塊以及設(shè)定的數(shù)字順序向服務(wù)器發(fā)送，則服務(wù)器根據(jù)收到的數(shù)字順序和至于數(shù)據(jù)塊中的數(shù)字，對收到的數(shù)據(jù)塊進行排序，并進行合并處理。 其中，服務(wù)器可以根據(jù)客戶端的通知確定客戶端是按照哪種順序發(fā)送的數(shù)據(jù)塊；也可以根據(jù)預(yù)先的設(shè)定，即如果服務(wù)器收到的數(shù)據(jù)塊中沒有數(shù)字，則按照數(shù)據(jù)先后順序，進行合并；否則，按照數(shù)字順序進行合并。 服務(wù)器在收到數(shù)據(jù)塊中含有數(shù)據(jù)信息后，根據(jù)文件標識建立一個文件夾，將收到的含有相同文件標識的數(shù)據(jù)塊都放到該文件夾中。 這樣該文件夾就是指定位置。當然，還可以根據(jù)文件類型確定指定位置，比如音樂類和影視類可以分開存儲等等。 服務(wù)器有多種方式確定數(shù)據(jù)塊全部接收完成，比如如果服務(wù)器在收到第一個數(shù)據(jù)塊中含有文件的容量信息，則在每次收到數(shù)據(jù)塊后，都將收到的所有數(shù)據(jù)塊的容量與文件的容量信息進行比較，如果兩個容量相同，則確定數(shù)據(jù)塊全部接收完成；
如果服務(wù)器在收到的數(shù)據(jù)塊中含有狀態(tài)標識，則根據(jù)狀態(tài)標識確定數(shù)據(jù)塊是否全部接收完成； 服務(wù)器還可以在收到一個數(shù)據(jù)塊后查看客戶端是否還處于斷開狀態(tài)，如果客戶端處于斷開狀態(tài)，則確定數(shù)據(jù)塊全部接收完成。 如果服務(wù)器收到文件的容量信息，則服務(wù)器可以計算出收到的所有數(shù)據(jù)塊與文件容量比例，這樣可以實時返回上傳的進度，讓客戶端可以顯示上傳的進度，使用戶直觀看到多少數(shù)據(jù)沒有上傳，從而提高用戶體驗。 如圖3所示，本發(fā)明實施例傳輸文件的方法包括下列步驟 步驟600、客戶端在接收到的HTTP請求中包含上傳信息時，根據(jù)服務(wù)器的內(nèi)存容量，將需要上傳的文件分成多個數(shù)據(jù)塊。 步驟601、客戶端將文件標識(比如文件名)置于每個數(shù)據(jù)塊中，按照數(shù)據(jù)先后順序，確定需要發(fā)送的第一個數(shù)據(jù)塊，將文件的容量信息置于第一個數(shù)據(jù)塊中。
步驟602、客戶端按照數(shù)據(jù)先后順序，向服務(wù)器發(fā)送數(shù)據(jù)塊。 步驟603、服務(wù)器收到第一個數(shù)據(jù)塊后，根據(jù)數(shù)據(jù)塊中的文件名，在硬盤中創(chuàng)建一個相同名稱的文件夾，將收到的數(shù)據(jù)塊存儲到該文件夾中。 步驟604、服務(wù)器查看收到的數(shù)據(jù)塊的容量是否等于收到的文件的容量信息中的容量，如果是，則執(zhí)行步驟607 ;否則，執(zhí)行步驟605。 步驟605、服務(wù)器繼續(xù)接收下一個數(shù)據(jù)塊，并根據(jù)接收到的數(shù)據(jù)塊中的文件標識，將該數(shù)據(jù)塊與相同名稱的文件夾中的數(shù)據(jù)塊進行合并。 步驟606、服務(wù)器查看收到的所有數(shù)據(jù)塊的容量是否等于收到的文件的容量信息
中的容量，如果是，則執(zhí)行步驟607 ;否則，返回步驟605。 步驟607、服務(wù)器將合并后的數(shù)據(jù)塊進行處理，形成文件并保存。 需要說明的是，客戶端采用其他順序發(fā)送數(shù)據(jù)塊，以及服務(wù)器采用其他方式確定
數(shù)據(jù)塊是否全部接收完成，與本實施例的步驟類似，不再贅述。 如圖4所示，本發(fā)明實施例傳輸文件的系統(tǒng)包括客戶端10和服務(wù)器20。 客戶端IO，用于在接收到的HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上
傳的文件分成多個數(shù)據(jù)塊，將多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。 服務(wù)器20，用于將接收的來自客戶端10的數(shù)據(jù)塊存儲到指定位置，在數(shù)據(jù)塊全部
接收完成后，根據(jù)客戶端10上傳數(shù)據(jù)塊的方式，將指定位置中的數(shù)據(jù)塊合并成文件。 在具體實施過程中，用戶進入上傳頁面，選中需要上傳的文件并點擊上傳后，會發(fā)
送一個HTTP請求，其中該HTTP請求中包含上傳信息(即multipart/form-data信息)。 分塊條件可以根據(jù)需要進行設(shè)定，比如設(shè)定分塊數(shù)量，還可以設(shè)定分成的一個數(shù)
據(jù)塊的容量，等等。 —種較佳的方式是根據(jù)服務(wù)器的內(nèi)存容量設(shè)定分成的數(shù)據(jù)塊的容量，比如服務(wù)器20的內(nèi)存容量為1G，則可以設(shè)定數(shù)據(jù)塊的容量為IOOM。 客戶端10可以向服務(wù)器20發(fā)送獲取內(nèi)存容量的命令，服務(wù)器20將自身內(nèi)存的容量返回給客戶端IO，從而客戶端IO獲得內(nèi)存容量。當然，其他能夠獲得服務(wù)器20的方式同樣適用本實施例。 發(fā)送順序同樣可以根據(jù)需要進行設(shè)定，比如按照數(shù)據(jù)先后順序，即將文件分成多個數(shù)據(jù)塊，每個數(shù)據(jù)塊發(fā)送的順序就是對應(yīng)的數(shù)據(jù)在文件中的順序；相應(yīng)的，服務(wù)器20根據(jù)收到的數(shù)據(jù)塊的順序，對數(shù)據(jù)塊進行合并(可以全部接收完成后在一起合并；也可以在收到第二個數(shù)據(jù)塊就和第一個數(shù)據(jù)塊進行合并，在收到第三個數(shù)據(jù)塊就和前面的數(shù)據(jù)塊進行合并，依次類推)。 還可以為每個數(shù)據(jù)塊分配一個數(shù)字，并將分配的數(shù)據(jù)置于對應(yīng)的數(shù)據(jù)塊中，按照設(shè)定的數(shù)字順序，將多個數(shù)據(jù)塊以及設(shè)定的數(shù)字順序向服務(wù)器發(fā)送。 假設(shè)有4個數(shù)據(jù)塊，對應(yīng)的數(shù)字為1，2，3和4，數(shù)字順序為4、3、2、1，則在發(fā)送的時
候，按照數(shù)字順序發(fā)送對應(yīng)的數(shù)據(jù)塊，數(shù)字順序可以獨立發(fā)送給服務(wù)器20，也可以至于其中
一個數(shù)據(jù)塊中，較佳的方式是置于第一個發(fā)送的數(shù)據(jù)塊中；相應(yīng)的，服務(wù)器20可以根據(jù)收
到的數(shù)字順序和至于數(shù)據(jù)塊中的數(shù)字，對收到的數(shù)據(jù)塊進行排序，并進行合并處理。 其中，客戶端10可以通知服務(wù)器20，按照哪種順序發(fā)送數(shù)據(jù)塊；也可以根據(jù)預(yù)先
的設(shè)定，即如果服務(wù)器20收到的數(shù)據(jù)塊中沒有數(shù)字，則按照數(shù)據(jù)先后順序，進行合并；否
則，按照數(shù)字順序進行合并。 客戶端10在劃分成數(shù)據(jù)塊后，可以在數(shù)據(jù)塊中添加文件標識； 服務(wù)器20在收到數(shù)據(jù)信息后，根據(jù)文件標識建立一個文件夾，將收到的含有相同
文件標識的數(shù)據(jù)塊都放到該文件夾中。 這樣該文件夾就是指定位置。當然，還可以根據(jù)文件類型確定指定位置，比如音樂類和影視類可以分開存儲等等。 服務(wù)器20有多種方式確定數(shù)據(jù)塊全部接收完成，比如客戶端IO將文件的容量信息置于第一個發(fā)送的數(shù)據(jù)塊中，服務(wù)器20在收到一個數(shù)據(jù)塊后，就將收到的所有數(shù)據(jù)塊的容量與文件的容量信息進行比較，如果兩個容量相同，則確定數(shù)據(jù)塊全部接收完成；
客戶端10還可以在每個數(shù)據(jù)塊中增加一個狀態(tài)標識(比如l，指示還有數(shù)據(jù)塊，O指示是最后一個數(shù)據(jù)塊)，這樣服務(wù)器20根據(jù)收到的數(shù)據(jù)塊中的狀態(tài)標識就可以數(shù)據(jù)塊是否全部接收完成； 服務(wù)器20還可以在收到一個數(shù)據(jù)塊后查看客戶端10是否還處于斷開狀態(tài)，如果客戶端10處于斷開狀態(tài)，則確定數(shù)據(jù)塊全部接收完成。 具體采用什么方式確定數(shù)據(jù)塊是否全部接收完成，可以根據(jù)需要在進行設(shè)定。
如果服務(wù)器20收到文件的容量信息，則服務(wù)器20可以計算出收到的所有數(shù)據(jù)塊與文件容量比例，這樣可以實時返回上傳的進度，客戶端io可以顯示上傳的進度，從而使用戶直觀看到多少數(shù)據(jù)沒有上傳，從而提高用戶體驗。 如圖5所示，本發(fā)明實施例客戶端包括劃分模塊100和發(fā)送模塊110。 劃分模塊IOO，用于在接收到的HTTP請求中包含上傳信息時，根據(jù)分塊條件將需
要上傳的文件分成多個數(shù)據(jù)塊。 其中，劃分模塊100還可以進一步包括數(shù)量化分模塊1000和容量化分模塊1010。 數(shù)量化分模塊1000，用于根據(jù)設(shè)定的分塊數(shù)量，將需要上傳的文件分成多個數(shù)據(jù)塊。 容量化分模塊1010，用于根據(jù)設(shè)定的數(shù)據(jù)塊的容量，將需要上傳的文件分成多個數(shù)據(jù)塊。 在具體實施過程中，可以根據(jù)需要選擇數(shù)量化分模塊1000或容量化分模塊1010進行分塊處理。 發(fā)送模塊110，用于將劃分模塊100劃分的多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服 務(wù)器發(fā)送。 其中，發(fā)送模塊110還可以進一步包括確定模塊1100和第一發(fā)送模塊1110。
確定模塊1100，用于確定按照文件中的數(shù)據(jù)先后順序。 第一發(fā)送模塊1110，用于按照確定的數(shù)據(jù)先后順序，將多個數(shù)據(jù)塊順序向服務(wù)器 發(fā)送。 其中，發(fā)送模塊110還可以進一步包括分配模塊1120和第二發(fā)送模塊1130。
分配模塊1120，用于為每個數(shù)據(jù)塊分配一個數(shù)字，并將分配的數(shù)據(jù)置于對應(yīng)的數(shù) 據(jù)塊中。 第二發(fā)送模塊1130，用于按照設(shè)定的數(shù)字順序，將多個數(shù)據(jù)塊以及設(shè)定的數(shù)字順 序向服務(wù)器發(fā)送。 在具體實施過程中，可以根據(jù)需要選擇確定模塊1100和第一發(fā)送模塊1110的組
合，或者分配模塊1120和第二發(fā)送模塊1130的組合發(fā)送數(shù)據(jù)塊。 如圖6所示，本發(fā)明實施例服務(wù)器包括接收模塊200和處理模塊210。 接收模塊200，用于將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置。 需要說明的是，發(fā)送數(shù)據(jù)塊的客戶端為本發(fā)明實施例的客戶端。 處理模塊210，用于在接收的數(shù)據(jù)塊全部接收完成后，根據(jù)客戶端上傳數(shù)據(jù)塊的方
式，將指定位置中的數(shù)據(jù)塊合并成文件。 其中，處理模塊210還可以進一步包括第一合并模塊2100和第二合并模塊 2110。 第一合并模塊2100，用于在數(shù)據(jù)塊全部接收完成后，且客戶端上傳數(shù)據(jù)塊的方式 為按照數(shù)據(jù)的先后順序上傳數(shù)據(jù)塊時，按照接收的數(shù)據(jù)塊的順序，將收到的數(shù)據(jù)塊合成文 件。 第二合并模塊2110，用于在數(shù)據(jù)塊全部接收完成后，且客戶端上傳數(shù)據(jù)塊的方式
為按照設(shè)定的數(shù)字順序上傳數(shù)據(jù)塊時，根據(jù)收到的來自客戶端的數(shù)字順序和數(shù)據(jù)塊中的數(shù)
字，將收到的數(shù)據(jù)塊合成文件。 其中，服務(wù)器還可以進一步包括 確定模塊220，用于如果收到的所有數(shù)據(jù)塊的容量等于收到的來自客戶端的容量 信息，確定數(shù)據(jù)塊全部接收完成；或 如果客戶端處于斷開狀態(tài)，確定數(shù)據(jù)塊全部接收完成；或 如果收到的數(shù)據(jù)塊中的狀態(tài)標識為完成表示，確定數(shù)據(jù)塊全部接收完成。 確定模塊220在接收模塊200接收完一個數(shù)據(jù)塊后判斷數(shù)據(jù)塊是否全部接收完
成，如果是，則觸發(fā)處理模塊210進行合并處理；否則，繼續(xù)查看數(shù)據(jù)塊是否全部接收完成。 從上述實施例中可以看出本發(fā)明實施例客戶端在接收到的HTTP請求中包含上
傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊；所述客戶端將所述多個數(shù)據(jù)
塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。由于將大容量文件分成多個數(shù)據(jù)塊，分別上傳，從
而降低了對于服務(wù)器的配置的要求，滿足了用戶上傳文件的需求，提高了用戶體驗以及文
件上傳的可靠性。
顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精 神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍 之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
權(quán)利要求
一種上傳文件的方法，其特征在于，該方法包括客戶端在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊；所述客戶端將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。
2. 如權(quán)利要求1所述的方法，其特征在于，所述客戶端根據(jù)分塊條件將需要上傳數(shù)據(jù)分成多個數(shù)據(jù)塊包括根據(jù)設(shè)定的分塊數(shù)量，將需要上傳的文件分成多個數(shù)據(jù)塊；或根據(jù)設(shè)定的數(shù)據(jù)塊的容量，將需要上傳的文件分成多個數(shù)據(jù)塊。
3. 如權(quán)利要求1或2所述的方法，其特征在于，所述客戶端將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送包括所述客戶端按照文件中的數(shù)據(jù)先后順序，將所述多個數(shù)據(jù)塊順序向服務(wù)器發(fā)送；或所述客戶端為每個數(shù)據(jù)塊分配一個數(shù)字，并將分配的數(shù)據(jù)置于對應(yīng)的數(shù)據(jù)塊中，按照設(shè)定的數(shù)字順序，將所述多個數(shù)據(jù)塊以及所述設(shè)定的數(shù)字順序向服務(wù)器發(fā)送。
4. 一種接收按照權(quán)利要求1的方式上傳的文件的方法，其特征在于，該方法包括服務(wù)器將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置；所述服務(wù)器在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述指定位置中的數(shù)據(jù)塊合并成文件。
5. 如權(quán)利要求4所述的方法，其特征在于，所述服務(wù)器確定數(shù)據(jù)塊全部接收完成包括如果收到的所有數(shù)據(jù)塊的容量等于收到的來自所述客戶端的容量信息，確定數(shù)據(jù)塊全部接收完成；或如果所述客戶端處于斷開狀態(tài)，確定數(shù)據(jù)塊全部接收完成；或如果收到的數(shù)據(jù)塊中的狀態(tài)標識為完成表示，確定數(shù)據(jù)塊全部接收完成。
6. 如權(quán)利要求4或5所述的方法，其特征在于，如果所述客戶端上傳數(shù)據(jù)塊的方式為按照數(shù)據(jù)的先后順序上傳數(shù)據(jù)塊，所述服務(wù)器將所述指定位置中的數(shù)據(jù)塊合并成文件包括按照接收的數(shù)據(jù)塊的順序，將收到的數(shù)據(jù)塊合成文件；如果所述客戶端上傳數(shù)據(jù)塊的方式為按照設(shè)定的數(shù)字順序上傳數(shù)據(jù)塊，所述服務(wù)器將所述指定位置中的數(shù)據(jù)塊合并成文件包括根據(jù)收到的來自所述客戶端的數(shù)字順序和數(shù)據(jù)塊中的數(shù)字，將收到的數(shù)據(jù)塊合成文件。
7. —種傳輸文件的系統(tǒng)，其特征在于，該系統(tǒng)包括客戶端，用于在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊，將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送；服務(wù)器，用于將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置，在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述指定位置中的數(shù)據(jù)塊合并成文件。
8. 如權(quán)利要求7所述的系統(tǒng)，其特征在于，所述客戶端包括劃分模塊，用于在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊條件將需要上傳的文件分成多個數(shù)據(jù)塊；發(fā)送模塊，用于將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送；所述服務(wù)器包括接收模塊，用于將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置；處理模塊，用于在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述 指定位置中的數(shù)據(jù)塊合并成文件。
9. 如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述劃分模塊包括數(shù)量化分模塊，用于根據(jù)設(shè)定的分塊數(shù)量，將需要上傳的文件分成多個數(shù)據(jù)塊；或 容量化分模塊，用于根據(jù)設(shè)定的數(shù)據(jù)塊的容量，將需要上傳的文件分成多個數(shù)據(jù)塊。
10. 如權(quán)利要求8或9所述的系統(tǒng)，其特征在于，所述發(fā)送模塊包括 確定模塊，用于確定按照文件中的數(shù)據(jù)先后順序；第一發(fā)送模塊，用于按照確定的數(shù)據(jù)先后順序，將所述多個數(shù)據(jù)塊順序向服務(wù)器發(fā)送； 或分配模塊，用于為每個數(shù)據(jù)塊分配一個數(shù)字，并將分配的數(shù)據(jù)置于對應(yīng)的數(shù)據(jù)塊中； 第二發(fā)送模塊，用于按照設(shè)定的數(shù)字順序，將所述多個數(shù)據(jù)塊以及所述設(shè)定的數(shù)字順 序向服務(wù)器發(fā)送。
11. 如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述服務(wù)器還包括確定模塊，用于如果收到的所有數(shù)據(jù)塊的容量等于收到的來自所述客戶端的容量信 息，確定數(shù)據(jù)塊全部接收完成；或如果所述客戶端處于斷開狀態(tài)，確定數(shù)據(jù)塊全部接收完 成；或如果收到的數(shù)據(jù)塊中的狀態(tài)標識為完成表示，確定數(shù)據(jù)塊全部接收完成。
12. 如權(quán)利要求8或11所述的系統(tǒng)，其特征在于，所述處理模塊包括 第一合并模塊，用于在數(shù)據(jù)塊全部接收完成后，且所述客戶端上傳數(shù)據(jù)塊的方式為按照數(shù)據(jù)的先后順序上傳數(shù)據(jù)塊時，按照接收的數(shù)據(jù)塊的順序，將收到的數(shù)據(jù)塊合成文件；第二合并模塊，用于在數(shù)據(jù)塊全部接收完成后，且所述客戶端上傳數(shù)據(jù)塊的方式為按 照設(shè)定的數(shù)字順序上傳數(shù)據(jù)塊時，根據(jù)收到的來自所述客戶端的數(shù)字順序和數(shù)據(jù)塊中的數(shù) 字，將收到的數(shù)據(jù)塊合成文件。
13. —種客戶端，其特征在于，該客戶端包括劃分模塊，用于在接收到的超級文本傳送協(xié)議HTTP請求中包含上傳信息時，根據(jù)分塊 條件將需要上傳的文件分成多個數(shù)據(jù)塊；發(fā)送模塊，用于將所述多個數(shù)據(jù)塊按照設(shè)定的發(fā)送順序，向服務(wù)器發(fā)送。
14. 如權(quán)利要求13所述的客戶端，其特征在于，所述劃分模塊包括 數(shù)量化分模塊，用于根據(jù)設(shè)定的分塊數(shù)量，將需要上傳的文件分成多個數(shù)據(jù)塊； 容量化分模塊，用于根據(jù)設(shè)定的數(shù)據(jù)塊的容量，將需要上傳的文件分成多個數(shù)據(jù)塊。
15. 如權(quán)利要求13或14所述的客戶端，其特征在于，所述發(fā)送模塊包括 確定模塊，用于確定按照文件中的數(shù)據(jù)先后順序；第一發(fā)送模塊，用于按照確定的數(shù)據(jù)先后順序，將所述多個數(shù)據(jù)塊順序向服務(wù)器發(fā)送；或分配模塊，用于為每個數(shù)據(jù)塊分配一個數(shù)字，并將分配的數(shù)據(jù)置于對應(yīng)的數(shù)據(jù)塊中； 第二發(fā)送模塊，用于按照設(shè)定的數(shù)字順序，將所述多個數(shù)據(jù)塊以及所述設(shè)定的數(shù)字順 序向服務(wù)器發(fā)送。
16. —種接收按照權(quán)利要求l的方式上傳的文件的服務(wù)器，其特征在于，該服務(wù)器包括接收模塊，用于將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置；處理模塊，用于在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述指定位置中的數(shù)據(jù)塊合并成文件。
17. 如權(quán)利要求16所述的服務(wù)器，其特征在于，所述服務(wù)器還包括確定模塊，用于如果收到的所有數(shù)據(jù)塊的容量等于收到的來自所述客戶端的容量信息，確定數(shù)據(jù)塊全部接收完成；或如果所述客戶端處于斷開狀態(tài)，確定數(shù)據(jù)塊全部接收完成；或如果收到的數(shù)據(jù)塊中的狀態(tài)標識為完成表示，確定數(shù)據(jù)塊全部接收完成。
18. 如權(quán)利要求16或17所述的服務(wù)器，其特征在于，所述處理模塊包括第一合并模塊，用于在數(shù)據(jù)塊全部接收完成后，且所述客戶端上傳數(shù)據(jù)塊的方式為按照數(shù)據(jù)的先后順序上傳數(shù)據(jù)塊時，按照接收的數(shù)據(jù)塊的順序，將收到的數(shù)據(jù)塊合成文件；第二合并模塊，用于在數(shù)據(jù)塊全部接收完成后，且所述客戶端上傳數(shù)據(jù)塊的方式為按照設(shè)定的數(shù)字順序上傳數(shù)據(jù)塊時，根據(jù)收到的來自所述客戶端的數(shù)字順序和數(shù)據(jù)塊中的數(shù)字，將收到的數(shù)據(jù)塊合成文件。
全文摘要
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)，特別涉及一種上傳和接收文件的方法、系統(tǒng)及裝置，用以解決現(xiàn)有技術(shù)中存在的通過Web網(wǎng)頁上傳大容量的文件，對于服務(wù)器的配置要求比較高的問題。本發(fā)明實施例上傳文件的方法包括服務(wù)器將接收的來自客戶端的數(shù)據(jù)塊存儲到指定位置；所述服務(wù)器在數(shù)據(jù)塊全部接收完成后，根據(jù)所述客戶端上傳數(shù)據(jù)塊的方式，將所述指定位置中的數(shù)據(jù)塊合并成文件。采用本發(fā)明實施例的方法能夠降低上傳文件時對于服務(wù)器的配置的要求，滿足用戶上傳文件的需求，提高用戶體驗以及文件上傳的可靠性。
文檔編號H04L29/06GK101729593SQ200810225488
公開日2010年6月9日 申請日期2008年11月3日 優(yōu)先權(quán)日2008年11月3日
發(fā)明者李明珠, 王永強 申請人:北大方正集團有限公司;北京北大方正電子有限公司