專利名稱：一種文件上傳的方法和服務(wù)器的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及互聯(lián)網(wǎng)信息領(lǐng)域，并且更具體地，涉及一種文件上傳的方法和服務(wù)器。
背景技術(shù)：
隨著互聯(lián)網(wǎng)技術(shù)的普及和應(yīng)用，各類型的互聯(lián)網(wǎng)產(chǎn)品不斷滲透到人們生活、工作和學(xué)習(xí)的方方面面，人們也不可避免地會使用文件上傳功能，如上傳照片、視頻、發(fā)送郵件附件、向網(wǎng)盤上傳文件等。目前，現(xiàn)有文件上傳的方法流程圖如圖1所述，具體流程包括:SlOl客戶端先發(fā)送待上傳文件的文件散列到服務(wù)器；S102服務(wù)器在自己的存儲平臺或記錄文件散列的數(shù)據(jù)庫上做查詢和比對；S103如果服務(wù)器存在與待上傳文件的文件散列相同的文件散列的文件，則告知客戶端文件上傳成功，不需要客戶端再上傳該文件；S104如果查詢或比對失敗，則告知客戶端發(fā)送待上傳文件?，F(xiàn)有的文件上傳的方式存在以下缺點(diǎn):當(dāng)前互聯(lián)網(wǎng)時代，越來越多的網(wǎng)站把自己的服務(wù)封裝成一系列計(jì)算機(jī)易識別的數(shù)據(jù)接口開放出去，供第三方開發(fā)者使用。比如，大部分網(wǎng)盤或云存儲系統(tǒng)，都開放文件上傳接口。此時，一些第三方開發(fā)者，由于疏忽或其他原因，計(jì)算文件散列時出現(xiàn)偏差，導(dǎo)致文件上傳時出現(xiàn)問題；更為重要的是，個別第三方開發(fā)者，通過其他手段獲取了某文件的文件散列，然后利用文件上傳接口向服務(wù)器上傳文件散列，服務(wù)器經(jīng)過查詢比對文件散列，認(rèn)為該文件已經(jīng)存在，不需要上傳文件就認(rèn)為上傳成功。這樣，客戶端通過偽造文件散列，將服務(wù)器端已存在的文件， “盜取”為自己的文件，這樣就出現(xiàn)了一個服務(wù)器的文件會被“盜取”的安全問題。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明實(shí)施例提供一種文件上傳的方法和服務(wù)器，以解決文件在上傳過程中存在的資源浪費(fèi)和缺乏安全性的問題。第一方面，提供一種文件上傳的方法，包括:服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列，根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件，對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。在第一方面的第一種可能的實(shí)現(xiàn)方式中，在服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對之前，服務(wù)器接收客戶端發(fā)送的待上傳文件的特定文件內(nèi)容的文件散列。結(jié)合第一方面或第一方面的第一種可能的實(shí)現(xiàn)方式，在第二種可能的實(shí)現(xiàn)方式中，服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件具體為:服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地查找是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件。
在本地查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為與待上傳文件的文件散列相同的服務(wù)器本地文件，服務(wù)器向客戶端發(fā)出指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列到服務(wù)器。結(jié)合第一方面的第二種可能的實(shí)現(xiàn)方式，在第三種可能的實(shí)現(xiàn)方式中，在本地沒有查找到與待上傳文件的文件散列相同的文件散列，則確定為本地沒有與待上傳文件的文件散列相同的文件，指示客戶端發(fā)送待上傳文件到服務(wù)器。結(jié)合第一方面的第一種可能的實(shí)現(xiàn)方式，在第四種可能的實(shí)現(xiàn)方式中，服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列的同時，接收客戶端發(fā)送的至少一個待上傳文件的特定文件內(nèi)容的文件散列。結(jié)合第一方面和上述任一種可能的實(shí)現(xiàn)方式，在第五種可能的實(shí)現(xiàn)方式中，服務(wù)器接收客戶端發(fā)送的客戶端信息，服務(wù)器根據(jù)所述客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件到服務(wù)器需要進(jìn)行的特定文件內(nèi)容的文件散列比對次數(shù)。結(jié)合第一方面和上述任一種可能的實(shí)現(xiàn)方式，在第六種可能的實(shí)現(xiàn)方式中，特定文件內(nèi)容的起始位置為根據(jù)對待上傳文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到，所述特定文件內(nèi)容的終止位置為根據(jù)對待上傳文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到。特定文件內(nèi)容的文件散列為根據(jù)約定算法對特定文件內(nèi)容的起始位置和終止位置進(jìn)行計(jì)算。第二方面，一種用于文件上傳的服務(wù)器，包括客戶端交互單元、比對單元，其中所述客戶端交互單元，接收客戶端發(fā)送的待上傳文件的文件散列；所述比對單元，根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的文件，以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對·。在第二方面的第一種可能的實(shí)現(xiàn)方式中，還包括設(shè)置單元，設(shè)置單元根據(jù)客戶端交互單元接收所述客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)；客戶端交互單元還可以接收客戶端發(fā)送的客戶端信息；比對單元根據(jù)客戶端信息查詢客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)，并根據(jù)比對次數(shù)對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。結(jié)合第二方面或第二方面的第一種可能的實(shí)現(xiàn)方式，在第二種可能的實(shí)現(xiàn)方式中，服務(wù)器還包括處理單元，所述處理單元對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的起始位置，所述處理單元還對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的終止位置；客戶端交互單元還接收客戶端發(fā)送待上傳文件的特定文件內(nèi)容的文件散列；所述處理單元根據(jù)約定算法對服務(wù)器本地文件的特定文件內(nèi)容的起始位置和終止位置進(jìn)行計(jì)算得到服務(wù)器本地文件的特定文件內(nèi)容的文件散列；比對單元對客戶端交互單元接收的客戶端發(fā)送的待上傳文件的特定文件內(nèi)容的文件散列和處理單元計(jì)算得到的服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。結(jié)合第二方面和上述任一種可能的實(shí)現(xiàn)方式，在第三種可能的實(shí)現(xiàn)方式中，比對單元還包括:查找子單元，確定子單元和指令子單元，查找子單元根據(jù)客戶端交互單元接收的所述待上傳文件的文件散列在本地查找是否存在與待上傳文件的文件散列相同的文件散列的文件，確定子單元在本地查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為與待上傳文件的文件散列相同的服務(wù)器本地文件，指令子單元指令所述客戶端交互單元向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列；客戶端交互單元還向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列。在第二方面的第四種可能的實(shí)現(xiàn)方式中，比對單元還在本地沒有查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為沒有與待上傳文件的文件散列相同的服務(wù)器本地文件，指令客戶端交互單元向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件。所述客戶端交互單元還向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件。通過上述技術(shù)方案，對文件散列進(jìn)行多次比對的特征，例如通過對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，以提高文件上傳的高效性、準(zhǔn)確性、安全性的問題。


為了更清楚地說明本發(fā)明實(shí)施例的技術(shù)方案，下面將對本發(fā)明實(shí)施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面所描述的附圖僅僅是本發(fā)明的一些實(shí)施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖1為現(xiàn)有文件上傳的方法流程圖。圖2為本發(fā)明實(shí)施例的文件上傳的方法流程示意圖。圖3為本發(fā)明又一實(shí)施例的文件上傳的方法流程示意圖。

圖4為本發(fā)明另一種實(shí)施例的文件上傳的方法流程示意圖。圖5為本發(fā)明實(shí)施例特定文件內(nèi)容的選取示意圖。圖6為本發(fā)明實(shí)施例文件上傳的服務(wù)器的結(jié)構(gòu)示意圖。圖7為本發(fā)明實(shí)施例文件上傳的服務(wù)器的又一結(jié)構(gòu)示意圖。圖8為本發(fā)明實(shí)施例文件上傳的服務(wù)器的另一結(jié)構(gòu)示意圖。圖9為本發(fā)明實(shí)施例文件上傳的服務(wù)器的另一結(jié)構(gòu)示意圖。
具體實(shí)施例方式下面將結(jié)合本發(fā)明實(shí)施例中的附圖，對本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實(shí)施例是本發(fā)明的一部分實(shí)施例，而不是全部實(shí)施例?；诒景l(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動的前提下所獲得的所有其他實(shí)施例，都應(yīng)屬于本發(fā)明保護(hù)的范圍。目前，采用現(xiàn)有的方式上傳文件，存在一些安全隱患，各類存儲平臺和網(wǎng)站開放接口來吸引第三方開發(fā)者，導(dǎo)致對自己客戶端的控制能力嚴(yán)重下降，這種文件快速上傳方法既無法保證存儲文件的安全性和隱私性，又無法保障快速上傳的高效性。針對解決現(xiàn)有文件上傳中存在的資源浪費(fèi)和缺乏安全性的問題，本發(fā)明實(shí)施例提供了一種文件上傳的方法和服務(wù)器，提高文件上傳的高效性、準(zhǔn)確性、安全性。
圖2為本發(fā)明實(shí)施例的文件上傳的方法流程示意圖。如圖2所示，本發(fā)明文件上傳方法實(shí)施例包括步驟:S201，服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列。在本發(fā)明實(shí)施例中，所述客戶端發(fā)送文件散列采用的技術(shù)手段包括但不限于上傳、提交等技術(shù)手段?？蛻舳送ㄟ^計(jì)算得出待上傳文件的文件散列，在上傳時，客戶端暫時不上傳整個文件，而是先采用服務(wù)器與客戶端約定的散列算法對待上傳文件進(jìn)行計(jì)算得出待上傳文件的文件散列，該待上傳文件的文件散列被作為待上傳文件的標(biāo)識字符串，其中散列算法可以包括內(nèi)容摘要算法(Message Digest Algorithm5, MD5),安全散列算法(Secure HashAlgorithml, SHA-1)等?？蛻舳擞?jì)算得出待上傳文件的文件散列后，客戶端將待上傳文件的文件散列發(fā)送到服務(wù)器。S202，服務(wù)器根據(jù)客戶端發(fā)送的待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件。本發(fā)明實(shí)施例中，服務(wù)器可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列，判斷服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。本發(fā)明另一實(shí)施例中，服務(wù)器還可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列，查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。舉例來說，在服務(wù)器本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件時，在具體實(shí)際運(yùn)用中，服務(wù)器將服務(wù)器本地文件和對應(yīng)的文件散列都存儲在服務(wù)器本地?cái)?shù)據(jù)庫中，服務(wù)器可以通過查找存儲有文件散列的數(shù)據(jù)庫找到服務(wù)器本地文件的文件散列，再通過服務(wù)器本地文件與對應(yīng)的文件散列的對應(yīng)關(guān)系查找服務(wù)器本地文件，確定服務(wù)器本地是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件。本發(fā)明實(shí)施例對此不作具體限定。 如果服務(wù)器本地存在與待上傳文件的文件散列相同的文件，則說明服務(wù)器已存在一份與客戶端待上傳文件相同的服務(wù)器本地文件，在本發(fā)明實(shí)施例中，為了提高安全性，月艮務(wù)器需要進(jìn)一步對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行比對，執(zhí)行步驟S203，從而進(jìn)一步確定服務(wù)器本地文件與待上傳文件相同。在本發(fā)明實(shí)施例中，如果服務(wù)器本地不存在與待上傳文件的文件散列相同的文件，服務(wù)器可以向客戶端發(fā)出指令，指示客戶端上傳待上傳文件到服務(wù)器。S203，服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。在本發(fā)明實(shí)施例中，服務(wù)器采用服務(wù)器與客戶端約定的散列算法對服務(wù)器本地文件的特定文件內(nèi)容進(jìn)行計(jì)算得出服務(wù)器本地文件的特定文件內(nèi)容的文件散列，該服務(wù)器本地文件的特定文件內(nèi)容的文件散列被作為服務(wù)器本地文件的特定文件內(nèi)容的文件的標(biāo)識字符串；客戶端采用服務(wù)器與客戶端約定的散列算法對待上傳文件的特定文件內(nèi)容進(jìn)行計(jì)算得出待上傳文件的特定文件內(nèi)容的文件散列，該待上傳文件的特定文件內(nèi)容的文件散列被作為待上傳文件的特定文件內(nèi)容的文件的標(biāo)識字符串；其中散列算法可以包括內(nèi)容摘要算法(Message Digest Algorithm5, MD5),安全散列算法(Secure Hash Algorithml,SHA-1)等。通過對服務(wù)器本地文件的特定文件內(nèi)容的文件散列和待上傳文件的特定文件內(nèi)容的文件散列進(jìn)行比對，判斷服務(wù)器本地文件和待上傳文件是否一致。在本發(fā)明另一實(shí)施例中，在執(zhí)行所述S203之前，服務(wù)器可以根據(jù)客戶端信息，預(yù)先設(shè)置所述客戶端發(fā)送待上傳文件到服務(wù)器需要進(jìn)行的特定文件內(nèi)容的文件散列比對次數(shù)，比對次數(shù)可以設(shè)置為η (η為大于等于I的自然數(shù))。對特定文件內(nèi)容的文件散列進(jìn)行至少一次比對可以多種方式，下面以預(yù)先設(shè)置的特定文件內(nèi)容的文件散列比對次數(shù)η等于3為例舉例說明兩種方式:方式一，服務(wù)器根據(jù)所述客戶端信息查詢到預(yù)先設(shè)置的特定文件內(nèi)容的文件散列比對次數(shù)為3，則向客戶端發(fā)送指令，指示客戶端發(fā)送一個待上傳文件的特定文件內(nèi)容的文件散列到服務(wù)器。接收到客戶端發(fā)送一個待上傳文件的特定文件內(nèi)容的文件散列后，將接收的待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行第一次比對。如果出現(xiàn)比對結(jié)果不同的情況，服務(wù)器則向客戶端發(fā)出指令，指示客戶端發(fā)送待上傳文件到服務(wù)器，并結(jié)束流程。如果比對結(jié)果相同，服務(wù)器則向客戶端發(fā)送指令，指示客戶端再發(fā)送下一個待上傳文件特定文件內(nèi)容的文件散列到服務(wù)器，進(jìn)行下一次的特定文件內(nèi)容的比對。以此類推，直到服務(wù)器執(zhí)行完3次特定文件內(nèi)容的文件散列的比對。當(dāng)服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行3次比對，且比對結(jié)果均為相同時，則確定服務(wù)器本地文件與待上傳文件相同，不需要客戶端上傳待上傳文件，告知客戶端上傳成功。方式二，服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對之前，服務(wù)器接收客戶端發(fā)送的至少一個待上傳文件的特定文件內(nèi)容的文件散列。服務(wù)器接收客戶端發(fā)送的至少一個待上傳文件的特定文件內(nèi)容的文件散列具體可以為:服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列的同時，接收客戶端根據(jù)預(yù)先設(shè)置特定文件內(nèi)容的文件散列的比對次數(shù)3，發(fā)送3個待上傳文件的特定文件內(nèi)容的文件散列。具體地，客戶端根據(jù)服務(wù)器與客戶端采用約定的散列算法順序計(jì)算得到相應(yīng)順序的待上傳文件的特定文件內(nèi)容的文件散列，并上傳到服務(wù)器。服務(wù)器與客戶端采用約定的散列算法順序計(jì)算得到相應(yīng)順序的服務(wù)器本地文件的特定文件內(nèi)容的文件散列，依次按照順序?qū)⒋蟼魑募奶囟ㄎ募?nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行比對。服務(wù)器依次按照順序?qū)⒋蟼魑募奶囟ㄎ募?nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行比對具體為:如果出現(xiàn)比對結(jié)果不同的情況，服務(wù)器則向客戶端發(fā)出指令，指示客戶端發(fā)送待上傳文件到服務(wù)器，并結(jié)束流程。如果出現(xiàn)比對結(jié)果相同的情況，服務(wù)器則進(jìn)行下一次的特定文件內(nèi)容的比對。以此類推，直到服務(wù)器執(zhí)行完3次特定文件內(nèi)容的文件散列的比對，則確定服務(wù)器本地文件與待上傳文件相同，不需要客戶端上傳待上傳文件，告知客戶端上傳成功。

本發(fā)明文件上傳方法的實(shí)施例采用對待上傳文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次的比對的技術(shù)手段，可以準(zhǔn)確地確定服務(wù)器本地文件和待上傳文件是相同的，從而有效地提高文件上傳的上傳效率、節(jié)省了服務(wù)器資源占用和網(wǎng)絡(luò)帶寬資源。同時也可以避免個別第三方開發(fā)者，通過其他手段獲取了某文件的文件散列，利用上傳接口向服務(wù)器提交文件散列，服務(wù)器認(rèn)為該文件已經(jīng)存在，不需要上傳文件就認(rèn)為文件上傳成功，從而出現(xiàn)文件“盜取”的安全問題。圖3是本發(fā)明又一實(shí)施例的文件上傳的方法流程示意圖，文件上傳的方法實(shí)施例包括步驟:S301，服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列。在本發(fā)明實(shí)施例中，所述客戶端發(fā)送文件散列采用的技術(shù)手段包括但不限于上傳、提交等技術(shù)手段?？蛻舳送ㄟ^計(jì)算得出待上傳文件的文件散列，在上傳時，客戶端暫時不上傳整個文件，而是先采用服務(wù)器與客戶端約定的散列算法對待上傳文件進(jìn)行計(jì)算得出待上傳文件的文件散列，該待上傳文件的文件散列被作為待上傳文件的標(biāo)識字符串，其中散列算法可以包括內(nèi)容摘要算法(Message Digest Algorithm5, MD5),安全散列算法(Secure HashAlgorithml, SHA-1)等?？蛻舳擞?jì)算得出待上傳文件的文件散列后，客戶端將待上傳文件的文件散列發(fā)送到服務(wù)器。S302，服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列判斷本地是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件。服務(wù)器判斷本地是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件，如果存在則執(zhí)行S303，否則執(zhí)行 S305。服務(wù)器可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列在本地判斷是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件具體為:如果服務(wù)器本地存在與待上傳文件的文件散列相同的文件，則說明服務(wù)器已存在一份與客戶端待上傳文件相同的文件，執(zhí)行步驟S303，從而進(jìn)一步確定服務(wù)器本地文件與待上傳文件相同。如果服務(wù)器本地不存在與待上傳文件的文件散列相同的文件，則確定為本地沒有與待上傳文件的文件散列相同的文件，則執(zhí)行S305。本發(fā)明另一實(shí)施例中，服務(wù)器也可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列，查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。舉例來說，在服務(wù)器本地判斷與待上傳文件的文件散列相同的服務(wù)器本地文件時，在具體實(shí)際運(yùn)用中，服務(wù)器將服務(wù)器本地文件與對應(yīng)的文件散列都存儲在服務(wù)器本地?cái)?shù)據(jù)庫中，服務(wù)器可以通過查找存儲有文件散列的數(shù)據(jù)庫找到服務(wù)器本地文件的文件散列，再通過服務(wù)器本地文件與對應(yīng)的文件散列的對應(yīng)關(guān)系查找服務(wù)器本地文件，確定服務(wù)器本地是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件。本發(fā)明實(shí)施例對此不作具體限定。S303，服務(wù)器向客戶端發(fā)出指令，指示客戶端發(fā)送一個待上傳文件的特定文件內(nèi)容的文件散列到服務(wù)器。在本發(fā)明實(shí)施例中，在執(zhí)行S303前，服務(wù)器可以根據(jù)客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件到服務(wù)器需要進(jìn)行的特定文件內(nèi)容的文件散列比對次數(shù)，比對次數(shù)可以設(shè)置為η (η為大于等于I的自然數(shù))。
在本發(fā)明另一實(shí)施例中，為了提高安全性，服務(wù)器需要進(jìn)一步對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行比對，所以服務(wù)器向客戶端發(fā)出指令，指示客戶端發(fā)送一個待上傳文件的特定文件內(nèi)容的文件散列到服務(wù)器。在本發(fā)明另一實(shí)施例中，所述的發(fā)送指令的方式包括但不限于上傳、提交等手段。S304，服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行比對。如果服務(wù)器比對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列相同，則執(zhí)行S306 ;如果服務(wù)器比對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列不相同，則執(zhí)行S305。S305，服務(wù)器則向客戶端發(fā)出指令，指示客戶端發(fā)送待上傳文件到服務(wù)器，流程結(jié)束。S306，服務(wù)器根據(jù)預(yù)先設(shè)置所述客戶端發(fā)送待上傳文件到服務(wù)器需要進(jìn)行的特定文件內(nèi)容的文件散列比對次數(shù)，判斷是否·已經(jīng)完成特定文件內(nèi)容的文件散列的比對。服務(wù)器判斷是否完成特定文件內(nèi)容的文件散列的比對次數(shù)的比對，完成則執(zhí)行步驟S303，否則執(zhí)行步驟S307。本發(fā)明實(shí)施例中，以特定文件內(nèi)容的文件散列比對次數(shù)η等于3為例進(jìn)行說明，服務(wù)器對特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，每完成I次比對，進(jìn)行I次計(jì)數(shù)，如果服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列完成了 3次比對，則執(zhí)行步驟S307，否則執(zhí)行步驟S303。S307，當(dāng)比對結(jié)果均相同時，確定服務(wù)器本地文件與待上傳文件相同，不需要客戶端上傳待上傳文件，告知客戶端上傳成功，流程結(jié)束。本發(fā)明文件上傳方法的實(shí)施例中，服務(wù)器對待上傳文件的特定文件內(nèi)容散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對的方法上傳待上傳文件，能夠有效地防止某些文件被重復(fù)上傳，保證了文件上傳的高效，避免了資源的重復(fù)浪費(fèi)，進(jìn)而節(jié)省了服務(wù)器和網(wǎng)絡(luò)帶寬資源，相應(yīng)地也減少用戶的等待時間。與此同時，通過多次文件散列比對，堵截了傳統(tǒng)快速上傳方法的漏洞，有效地解決了安全性和高效性的沖突。圖4是本發(fā)明另一種實(shí)施例的文件上傳的方法流程示意圖，文件上傳的方法實(shí)施例包括步驟:S401，服務(wù)器接收客戶端發(fā)送的客戶端信息，服務(wù)器根據(jù)所述客戶端信息，預(yù)先設(shè)置所述客戶端發(fā)送待上傳文件到服務(wù)器需要進(jìn)行的特定文件內(nèi)容的文件散列比對次數(shù)η(η為大于等于I的自然數(shù))。S402，服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列，并根據(jù)比對次數(shù)順序接收客戶端發(fā)送待上傳文件的特定文件內(nèi)容的文件散列。在本發(fā)明實(shí)施例中，所述客戶端發(fā)送文件散列采用的技術(shù)手段包括但不限于上傳、提交等技術(shù)手段。客戶端通過計(jì)算得出待上傳文件的文件散列的同時，客戶端采用與服務(wù)器約定的散列算法順序計(jì)算得出待上傳文件的特定文件內(nèi)容的文件散列，在上傳時，客戶端暫時不上傳整個文件，而是先采用服務(wù)器與客戶端約定的散列算法計(jì)算得出待上傳文件的文件散列，該待上傳文件的文件散列被作為待上傳文件的標(biāo)識字符串。在計(jì)算得出待上傳文件的文件散列的同時，服務(wù)器與客戶端采用約定的散列算法順序計(jì)算得到相應(yīng)順序的特定文件內(nèi)容的文件散列，其中散列算法可以包括內(nèi)容摘要算法(Message Digest Algorithm5,MD5),安全散列算法(Secure Hash Algorithml, SHA-1)等。客戶端計(jì)算得出待上傳文件的文件散列和相應(yīng)順序的特定文件內(nèi)容的文件散列后，服務(wù)器接收客戶端上傳的待上傳文件的文件散列和順序接收特定文件內(nèi)容的文件散列。S403，服務(wù)器可以根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列判斷本地是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件。服務(wù)器判斷本地存在與待上傳文件的文件散列相同的服務(wù)器本地文件，則執(zhí)行S404，否則執(zhí)行S405。服務(wù)器可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列在本地判斷是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件具體為:如果服務(wù)器本地存在與待上傳文件的文件散列相同的文件，則說明服務(wù)器已存在一份與客戶端待上傳文件相同的文件，執(zhí)行步驟S404，為了提高安全性，服務(wù)器需要進(jìn)一步對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行比對，從而進(jìn)一步確定服務(wù)器本地文件與待上傳文件相同。如果服務(wù)器在本地不存在與待上傳文件的文件散列相同的文件，則確定為本地沒有與待上傳文件的文件散列相同的文件，執(zhí)行S405。在本發(fā)明另一實(shí)施例中，服務(wù)器也可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列，查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。舉例來說，在服務(wù)器本地判斷與待上傳文件的文件散列相同的服務(wù)器本地文件時，在具體實(shí)際運(yùn)用中，服務(wù)器將服務(wù)器本地文件和對應(yīng)的文件散列都存儲在服務(wù)器本地?cái)?shù)據(jù)庫中，服務(wù)器可以通過查找存儲有文件散列的數(shù)據(jù)庫找到服務(wù)器本地文件的文件散列，再通過服務(wù)器本地文件與對應(yīng)的文件散列的對應(yīng)關(guān)系查找服務(wù)器本地文件，確定服務(wù)器本地是否存在與待上傳文件的·文件散列相同的服務(wù)器本地文件。本發(fā)明實(shí)施例對此不作具體限定。S404，服務(wù)器根據(jù)比對次數(shù)對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列依次進(jìn)行比對。服務(wù)器完成比對后，比對結(jié)果均相同時，執(zhí)行則執(zhí)行S406，否則執(zhí)行S405。服務(wù)器對特定文件內(nèi)容的文件散列完成比對次數(shù)的比對后，如果待上傳文件的所有特定文件內(nèi)容的文件散列與服務(wù)器本地文件的所有特定文件內(nèi)容的文件散列均相同，即比對結(jié)果均相同，則執(zhí)行S406 ；在對特定文件內(nèi)容的文件散列進(jìn)行比對過程中，如果出現(xiàn)比對結(jié)果不同的情況，停止比對,并執(zhí)行S405。S405，服務(wù)器向客戶端發(fā)出指令，指示客戶端發(fā)送待上傳文件到服務(wù)器，流程結(jié)束。S406，確定服務(wù)器本地文件與待上傳文件相同，不需要客戶端上傳待上傳文件，告知客戶端上傳成功，流程結(jié)束。本發(fā)明實(shí)施例中，所述的發(fā)送指令的方式包括但不限于上傳、提交等手段。本發(fā)明實(shí)施例中，涉及的特定文件內(nèi)容的選取算法是服務(wù)器與客戶端約定的算法，即客戶端與服務(wù)器端經(jīng)過約定的算法可以得出文件相同的起止位置。本發(fā)明實(shí)施例舉例說明特定文件內(nèi)容的選取算法可以有以下兩種方式:(a)固定選取算法。固定地選取文件中某段內(nèi)容作為特定文件內(nèi)容，特定文件內(nèi)容的文件散列通過約定的散列算法計(jì)算得出文件散列。比如，選取文件頭部、中部、尾部三個1024B內(nèi)容依次拼接起來，并計(jì)算文件散列。如果文件大小為29087994B (大約28M)，那么該文件特定文件內(nèi)容由圖5中三個陰影部分依次拼接起來，頭部(0-1023)、中部(14543997-14545020)、尾部(29086970-29087993)；(b)根據(jù)文件特征選擇特定文件內(nèi)容的選取算法。特定文件內(nèi)容的選取，與文件自身特征(如:文件大小、文件散列、當(dāng)前第幾次比對等)關(guān)聯(lián)起來，進(jìn)而更為隨機(jī)地實(shí)現(xiàn)特定文件內(nèi)容選取，從而提高安全性防止被惡意偽造。下面提供了一種根據(jù)文件特征選取特定文件內(nèi)容起止位置的算法具體為:file_md5是通過內(nèi)容摘要算法(Message DigestAlgorithm5, MD5)計(jì)算得到的待上傳文件的文件散列，cycle為當(dāng)前第幾次比對的次數(shù)，file_size為文件大小(單位:字節(jié))，crc32函數(shù)是計(jì)算一個字符串的crc32多項(xiàng)式；start為計(jì)算得出的特定文件內(nèi)容起始位置，end為計(jì)算得出的特定文件內(nèi)容終止位置；start和end的計(jì)算方法如下面公式列出:start=crc32(file_md5.cycle)%(file_size)end=start+1024*1024or(file_size_l)比如，某文件a.dat,其通過內(nèi)容摘要算法(Message Digest Algorithm5, MD5)計(jì)算得到的文件散列為e2da740280a0d5d739736a75bdb410dc，文件大小為95927304字節(jié)(大約92MB)，當(dāng)前第二次比對則cycle為2。那么該文件特定文件內(nèi)容的起止位置計(jì)算如下:start=crc32C e2da740280a0d5d739736a75bdb410dc’.’ 2’)％95927304=37082959end=start+1024*1024=38131535那么，該文件特定文件內(nèi)容的起止位置是37082959 38131535。本發(fā)明文件上傳方法的實(shí)施例中的散列算法包括但不限于內(nèi)容摘要算法(Message Digest Algorithm5,MD5),安全散列算法(Secure Hash Algorithml, SHA-1)等。計(jì)算字符串的函數(shù)包括但不限于crc32函數(shù)等。本發(fā)明文件上傳方法的實(shí)施例中的特定文件內(nèi)容的選取算法適用于本發(fā)明所有實(shí)施例中。本發(fā)明文件上傳方法的實(shí)施例的特定文件內(nèi)容的選取算法包括但不限于固定選取算法，根據(jù)文件特征選擇特定文件內(nèi)容的選取算法等。特定文件內(nèi)容的選取算法是可以替換、更改、改進(jìn)的，本發(fā)明實(shí)施例對此不作具體限定。本發(fā)明文件上傳方法的實(shí)施例在客戶端發(fā)送的待上傳文件的文件散列的同時，順序發(fā)送需要相應(yīng)比對次數(shù)的待上傳文件的特定文件內(nèi)容的文件散列。服務(wù)器并對待上傳文件的特定文件內(nèi)容散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對來上傳待上傳文件，客戶端一次性提交待上傳文件的文件散列和多個特定文件內(nèi)容的文件散列，至少減少了客戶端與服務(wù)器之間的多次交互，在保證文件上傳的安全性和準(zhǔn)確性的前提下，很大程度上提高了文件上傳效率，同時節(jié)省了網(wǎng)絡(luò)資源。圖6為 本發(fā)明實(shí)施例文件上傳的服務(wù)器的結(jié)構(gòu)示意圖。本發(fā)明實(shí)施例中的服務(wù)器60包括:客戶端交互單元601和比對單元602。
客戶端交互單元601，接收客戶端發(fā)送的待上傳文件的文件散列。比對單元602，根據(jù)客戶端發(fā)送的待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件，以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。本發(fā)明實(shí)施例中，比對單元602根據(jù)客戶端發(fā)送的待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件，具體可以為根據(jù)客戶端發(fā)送的待上傳文件的文件散列，查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。本發(fā)明另一實(shí)施例中，比對單元602根據(jù)客戶端發(fā)送的待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件，具體可以為根據(jù)客戶端發(fā)送的待上傳文件的文件散列，判斷服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。如果服務(wù)器本地存在與待上傳文件的文件散列相同的文件，則說明服務(wù)器已存在一份與客戶端待上傳文件相同的服務(wù)器本地文件，在本發(fā)明實(shí)施例中，為了提高安全性，t匕對單元602需要進(jìn)一步對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，從而進(jìn)一步確定服務(wù)器本地文件與待上傳文件相同。服務(wù)器實(shí)現(xiàn)了文件上傳 過程中，對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，出于簡潔，具體細(xì)節(jié)不再贅述。本發(fā)明實(shí)施例中，服務(wù)器通過在本地確定與待上傳文件的文件散列相同的文件以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，能夠有效的防止文件被重復(fù)上傳，進(jìn)而節(jié)省了網(wǎng)絡(luò)帶寬和服務(wù)器資源，相應(yīng)地減少了用戶的等待時間。同時通過文件散列多次比對，堵截了傳統(tǒng)文件上傳的漏洞，很好地解決了高效性與安全性的沖突。圖7為本發(fā)明實(shí)施例文件上傳的服務(wù)器的又一結(jié)構(gòu)示意圖。如圖7中本發(fā)明實(shí)施例文件上傳的服務(wù)器60還可以包括設(shè)置單元603和處理單元 604?？蛻舳私换卧?01還可以接收客戶端發(fā)送的客戶端信息。設(shè)置單元603根據(jù)客戶端交互單元601接收的所述客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)。比對單元602還可以根據(jù)客戶端信息查詢客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)，并根據(jù)比對次數(shù)對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對?？蛻舳私换卧?01還可以接收客戶端發(fā)送待上傳文件的特定文件內(nèi)容的文件散列。處理單元604對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的起始位置，所述處理單元604還可以對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的終止位置；根據(jù)約定算法對服務(wù)器本地文件的特定文件內(nèi)容的起始位置和終止位置進(jìn)行計(jì)算得到服務(wù)器本地文件的特定文件內(nèi)容的文件散列。比對單元602對所述客戶端交互單元601接收的客戶端發(fā)送的待上傳文件的特定文件內(nèi)容的文件散列和處理單元604計(jì)算得到的服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。本發(fā)明實(shí)施例中，比對單元602可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列，查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。比對單元602查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件具體為:如果服務(wù)器本地存在與待上傳文件的文件散列相同的文件，則說明服務(wù)器已存在一份與客戶端待上傳文件相同的文件，此時，為了提高安全性，比對單元602對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。服務(wù)器實(shí)現(xiàn)了文件上傳過程中，對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，出于簡潔，具體細(xì)節(jié)不再贅述。本發(fā)明文件上傳方法的實(shí)施例服務(wù)器通過在本地確定與待上傳文件的文件散列相同的文件以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，能夠有效的防止文件被重復(fù)上傳，進(jìn)而節(jié)省了網(wǎng)絡(luò)帶寬和服務(wù)器資源，相應(yīng)地減少了用戶的等待時間。同時通過文件散列多次比對，堵截了傳統(tǒng)文件上傳的漏洞，很好地解決了高效性與安全性的沖突。圖8為本發(fā)明實(shí)施例文件上傳的服務(wù)器的另一結(jié)構(gòu)示意圖。在如圖8所示的本發(fā)明實(shí)施例中的服務(wù)器60的比對單元602還可以包括:查找子單元701，確定子單元702和指令子單元703。查找子單元701還可以根據(jù)客戶端交互單元601接收的所述待上傳文件的文件散列在本地查找是否存在與待上傳文件的文件散列相同的文件散列的文件，在本地查找到與待上傳文件的文件散列相同的文件散列的文件，確定子單元702則確定為與待上傳文件的文件散列相同的服務(wù)器本地文件，指令子單元703指令所述客戶端交互單元601向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列?？蛇x的，所述客戶端交互單元601還可以向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列?？蛇x的，所述比對單元602還可以在本地沒有查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為沒有與待上傳文件的文件散列相同的服務(wù)器本地文件，指令客戶端交互單元向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件?？蛇x的，所述客戶端交互單元601還可以向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件。本發(fā)明實(shí)施例中服務(wù)器實(shí)現(xiàn)文件上傳過程中，對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，出于簡潔，具體細(xì)節(jié)不再贅述。本發(fā)明文件上傳方法的實(shí)施例的服務(wù)器通過在本地確定與待上傳文件的文件散列相同的文件以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，能夠有效的防止文件被重復(fù)上傳，進(jìn)而節(jié)省了網(wǎng)絡(luò)帶寬和服務(wù)器資源，相應(yīng)地減少了用戶的等待時間。同時通過文件散列多次比對，堵截了傳統(tǒng)文件上傳的漏洞，很好 地解決了高效性與安全性的沖突。
圖9為本發(fā)明實(shí)施例文件上傳的服務(wù)器的另一結(jié)構(gòu)示意圖。如圖9所示，該服務(wù)器900包括處理器901、用戶接口 902、存儲器903、應(yīng)用程序904以及總線905。處理器901用于執(zhí)行存儲器903存儲的本發(fā)明實(shí)施例的程序，并通過總線與其他
裝置雙向通信。存儲器9O 3可以是包括計(jì)算機(jī)的軟盤、U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機(jī)存取存儲器(RAM, Random Access Memory)、磁碟或者光盤等的一種或多種，用于存儲可以執(zhí)行本發(fā)明實(shí)施例的程序或本發(fā)明實(shí)施例的應(yīng)用數(shù)據(jù)庫，通過總線905接收其他組件的輸入或被其他組件調(diào)用所存儲的信息，例如文件的散列算法。應(yīng)用程序904包括各種系統(tǒng)程序,用于實(shí)現(xiàn)各種應(yīng)用業(yè)務(wù)。 用戶接口 902向用戶開放，用于終端連接，進(jìn)行數(shù)據(jù)交換。處理器901與存儲器903也可以整合成應(yīng)用本發(fā)明實(shí)施例的物理模塊，在該物理模塊上存儲和運(yùn)行實(shí)現(xiàn)本發(fā)明實(shí)施例的程序。服務(wù)器900的各個組件通過總線905耦合在一起，其中，總線905除包括數(shù)據(jù)總線之外，還可以包括電源總線、控制總線和狀態(tài)信號總線等。但是為了清楚說明起見，在圖中將各種總線都標(biāo)為總線905。在本發(fā)明實(shí)施例中，服務(wù)器900的各單元分別執(zhí)行以下內(nèi)容。處理器901根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的文件，以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。存儲器903存儲所述用戶接口 902發(fā)送的所述文件散列或所述處理器901發(fā)送的文件散列算法。用戶接口 902還用于向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件?？蛇x的，所述用戶接口 902還用于接收客戶端發(fā)送的待上傳文件的文件散列。可選的，所述用戶接口 902還用于接收客戶端發(fā)送的客戶端信息?？蛇x的，所述用戶接口 902還用于向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列?？蛇x的，所述用戶接口 902還用于接收客戶端發(fā)送待上傳文件的特定文件內(nèi)容的文件散列。處理器901可以根據(jù)客戶端發(fā)送的待上傳文件的文件散列，查找服務(wù)器本地是否存在與待上傳文件的文件散列相同的文件。具體為:如果服務(wù)器本地存在與待上傳文件的文件散列相同的文件，則說明服務(wù)器已存在一份與客戶端待上傳文件相同的文件，此時，為了提高安全性，處理器901對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對?？蛇x的，處理器901根據(jù)用戶接口 902接收所述客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)?？蛇x的，處理器901還用于根據(jù)客戶端信息查詢客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)，并根據(jù)比對次數(shù)對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。
可選的，處理器901還用于對所述用戶接口 902接收的客戶端發(fā)送的待上傳文件的特定文件內(nèi)容的文件散列和處理器901計(jì)算得到的服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。可選的，所述處理器901還用于對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的起始位置，所述處理器901還用于對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的終止位置；根據(jù)約定算法對服務(wù)器本地文件的特定文件內(nèi)容的起始位置和終止位置進(jìn)行計(jì)算得到服務(wù)器本地文件的特定文件內(nèi)容的文件散列?？蛇x的，所述處理器901還用于在本地沒有查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為沒有與待上傳文件的文件散列相同的服務(wù)器本地文件，指令用戶接口 902向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件。服務(wù)器實(shí)現(xiàn)了文件上傳過程中，對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，出于簡潔，具體細(xì)節(jié)不再贅述。本發(fā)明文件上傳方法的實(shí)施例服務(wù)器通過在本地確定與待上傳文件的文件散列相同的文件以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對，能夠有效的防止文件被重復(fù)上傳，進(jìn)而節(jié)省了網(wǎng)絡(luò)帶寬和服務(wù)器資源，相應(yīng)地減少了用戶的等待時間。同時通過文件散列多次比對，堵截了傳統(tǒng)文件上傳的漏洞，很好地解決了高效性與安全性的沖突。本領(lǐng)域普通技術(shù)人員可以意識到，結(jié)合本文中所公開的實(shí)施例描述的各示例的單元、算法及方法步驟，能夠以計(jì)算機(jī)軟件和電子硬件的結(jié)合來實(shí)現(xiàn)。這些功能究竟以硬件還是軟件方式來執(zhí)行，取決于技術(shù)方案的特定應(yīng)用和設(shè)計(jì)約束條件。專業(yè)技術(shù)人員可以對每個特定的應(yīng)用來使用不同方法來實(shí)現(xiàn)所描述的功能，但是這種實(shí)現(xiàn)不應(yīng)認(rèn)為超出本發(fā)明的范圍。

所屬領(lǐng)域的技術(shù)人員可以清楚地了解到，為描述的方便和簡潔，上述描述的服務(wù)器和單元的具體工作過程，可以參考前述方法實(shí)施例中的對應(yīng)過程，在此不再贅述。在本申請所提供的幾個實(shí)施例中，所揭露的服務(wù)器和方法，可以通過其它的方式實(shí)現(xiàn)。例如，以上所描述的服務(wù)器實(shí)施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實(shí)際實(shí)現(xiàn)時可以有另外的劃分方式，例如多個單元或組件可以結(jié)合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點(diǎn)，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性，機(jī)械或其它的形式。所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上?？梢愿鶕?jù)實(shí)際的需要選擇其中的部分或者全部單元來實(shí)現(xiàn)本發(fā)明實(shí)施例方案的目的。另外，在本發(fā)明各個實(shí)施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨(dú)物理存在，也可以兩個或兩個以上單元集成在一個單元中。本領(lǐng)域普通技術(shù)人員可以理解:實(shí)現(xiàn)上述方法實(shí)施例的全部或部分步驟可以通過程序指令相關(guān)的硬件來完成，前述的程序可以存儲于一計(jì)算機(jī)可讀取存儲介質(zhì)中，該程序在執(zhí)行時，執(zhí)行包括上述方法實(shí)施例的步驟；而前述的存儲介質(zhì)包括:ROM、RAM、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。以上所述，僅為本發(fā)明的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范 圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)以所述權(quán)利要求的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1.一種文件上傳的方法，其特征在于，包括: 服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列； 服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件； 服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對之前，服務(wù)器接收客戶端發(fā)送的待上傳文件的特定文件內(nèi)容的文件散列。
3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件具體為:服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地查找是否存在與待上傳文件的文件散列相同的服務(wù)器本地文件； 在本地查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為與待上傳文件的文件散列相同的服務(wù)器本地文件，服務(wù)器向客戶端發(fā)出指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列到服務(wù)器。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，還包括:在本地沒有查找到與待上傳文件的文件散列相同的文件散列，則確定為本地沒有與待上傳文件的文件散列相同的文件，指示客戶端發(fā)送待上傳文件到服務(wù)器。
5.根據(jù)權(quán)利要求2所述的方法，其特征在于，服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列的同時，接收客戶端發(fā)送的至少一個待上傳文件的特定文件內(nèi)容的文件散列?！?br> 6.根據(jù)權(quán)利要求1-5任一所述的方法，其特征在于，服務(wù)器接收客戶端發(fā)送的客戶端信息，服務(wù)器根據(jù)所述客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件到服務(wù)器需要進(jìn)行的特定文件內(nèi)容的文件散列比對次數(shù)。
7.根據(jù)權(quán)利要求1-6任一所述的方法，其特征在于，所述特定文件內(nèi)容的起始位置為根據(jù)對待上傳文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到，所述特定文件內(nèi)容的終止位置為根據(jù)對待上傳文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到； 所述特定文件內(nèi)容的文件散列為根據(jù)約定算法對特定文件內(nèi)容的起始位置和終止位置進(jìn)行計(jì)算。
8.一種用于文件上傳的服務(wù)器，其特征在于，包括客戶端交互單元、比對單元: 所述客戶端交互單元，用于接收客戶端發(fā)送的待上傳文件的文件散列； 所述比對單元，用于根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的文件，以及對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。
9.根據(jù)權(quán)利要求8所述的服務(wù)器，其特征在于，所述服務(wù)器還包括設(shè)置單元: 所述客戶端交互單元還用于接收客戶端發(fā)送的客戶端信息； 所述設(shè)置單元用于根據(jù)客戶端交互單元接收的所述客戶端信息，設(shè)置所述客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)； 所述比對單元還用于根據(jù)客戶端信息查詢客戶端發(fā)送待上傳文件需要進(jìn)行的特定內(nèi)容文件散列比對次數(shù)，并根據(jù)比對次數(shù)對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。
10.根據(jù)權(quán)利要求8或9所述的服務(wù)器，其特征在于，所述服務(wù)器還包括處理單元: 所述客戶端交互單元還用于接收客戶端發(fā)送待上傳文件的特定文件內(nèi)容的文件散列； 所述處理單元用于對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的起始位置，所述處理單元還用于對服務(wù)器本地文件的文件散列和文件大小進(jìn)行函數(shù)運(yùn)算得到服務(wù)器本地文件的特定文件內(nèi)容的終止位置； 根據(jù)約定算法對服務(wù)器本地文件的特定文件內(nèi)容的起始位置和終止位置進(jìn)行計(jì)算得到服務(wù)器本地文件的特定文件內(nèi)容的文件散列； 所述比對單元對所述客戶端交互單元接收的客戶端發(fā)送的待上傳文件的特定文件內(nèi)容的文件散列和處理單元計(jì)算得到的服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。
11.根據(jù)權(quán)利要求8-10任一所述的服務(wù)器，其特征在于，所述比對單元還包括:查找子單元，確定子單元和指令子單元； 所述查找子單元用于根據(jù)所述客戶端交互單元接收的所述待上傳文件的文件散列在本地查找是否存在與待上傳文件的文件散列相同的文件散列的文件； 所述確定子單元用于在本地查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為與待上傳文件的文 件散列相同的服務(wù)器本地文件； 所述指令子單元用于指令所述客戶端交互單元向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列； 所述客戶端交互單元還用于向客戶端發(fā)送指令，指示客戶端發(fā)送至少一個待上傳文件的特定文件內(nèi)容的文件散列。
12.根據(jù)權(quán)利要求8所述的服務(wù)器，其特征在于，所述比對單元還用于在本地沒有查找到與待上傳文件的文件散列相同的文件散列的文件，則確定為沒有與待上傳文件的文件散列相同的服務(wù)器本地文件，指令客戶端交互單元向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件； 所述客戶端交互單元還用于向客戶端發(fā)送指令，指示客戶端發(fā)送待上傳文件。
全文摘要
本發(fā)明實(shí)施例公開了一種文件上傳的方法和服務(wù)器，以實(shí)現(xiàn)文件上傳。所述文件上傳的方法包括服務(wù)器接收客戶端發(fā)送的待上傳文件的文件散列；服務(wù)器根據(jù)客戶端發(fā)送的所述待上傳文件的文件散列在本地確定與待上傳文件的文件散列相同的服務(wù)器本地文件；服務(wù)器對待上傳文件的特定文件內(nèi)容的文件散列與服務(wù)器本地文件的特定文件內(nèi)容的文件散列進(jìn)行至少一次比對。通過上述技術(shù)方案，比對特定文件內(nèi)容的文件散列的特征，能夠有效地防止文件被重復(fù)上傳，進(jìn)而節(jié)省了服務(wù)器和網(wǎng)絡(luò)帶寬資源，相應(yīng)地減少了用戶的等待時間。同時通過文件散列多次比對，堵截了傳統(tǒng)文件上傳的漏洞，有效地解決了高效性與安全性的沖突。
文檔編號H04L29/08GK103248711SQ201310196170
公開日2013年8月14日 申請日期2013年5月23日 優(yōu)先權(quán)日2013年5月23日
發(fā)明者李曉明, 謝青冬 申請人:華為技術(shù)有限公司