發(fā)送文件的方法和終端的制作方法
【專利摘要】本發(fā)明提供了一種發(fā)送文件的方法和終端。所述方法包括:接收向接收方發(fā)送文件的指令;接收來自接收方的壓縮待發(fā)送的文件的請求;根據所述請求對待發(fā)送的文件進行壓縮處理;發(fā)送經過所述壓縮處理的文件。所述終端包括:接收模塊,用于接收向接收方發(fā)送文件的指令;所述接收模塊,還用于接收來自接收方的壓縮待發(fā)送的文件的請求;壓縮模塊,用于根據所述接收模塊接收的請求對待發(fā)送的文件進行壓縮處理;發(fā)送模塊,用于發(fā)送經過所述壓縮處理的文件。采用本發(fā)明能提高文件發(fā)送操作上的方便性。
【專利說明】發(fā)送文件的方法和終端
【技術領域】
[0001]本發(fā)明涉及傳輸控制技術,特別是涉及一種發(fā)送文件的方法和終端。
【背景技術】
[0002]隨著互聯網絡的發(fā)展,越來越多的人們利用互聯網絡進行溝通和交流,并利用互聯網絡進行文件的傳輸,例如,使用即時通信工具在用戶之間傳輸文件,以實現文件的分享。
[0003]但是,人們利用互聯網絡進行文件傳輸的過程中,常常由于文件太大而受到制約,在意識到文件太大而導致了傳輸所耗費的時間過多時,將中斷文件的傳輸,進行額外的手動壓縮之后再進行壓縮后的文件的傳輸,操作上非常不方便。
【發(fā)明內容】
[0004]基于此,有必要針對文件太大而導致的文件發(fā)送的操作上的不方便的技術問題,提供一種能提高文件發(fā)送操作上的方便性的發(fā)送文件的方法。
[0005]此外,還有必要提供一種能提高文件發(fā)送操作上的方便性的終端。
[0006]一種發(fā)送文件的方法,其特征在于,所述方法包括:
[0007]接收向接收方發(fā)送文件的指令;
[0008]接收來自接收方的壓縮待發(fā)送的文件的請求;
[0009]根據所述請求對待發(fā)送的文件進行壓縮處理;
[0010]發(fā)送經過所述壓縮處理的文件。
[0011]在其中一個實施例中,所述方法還包括步驟:判斷所述文件的存儲容量是否超出預置的容量閾值;
[0012]則所述根據所述請求對待發(fā)送的文件進行壓縮處理的步驟,具體為:
[0013]當判斷為是時,根據所述請求對待發(fā)送的文件進行壓縮處理。
[0014]在其中一個實施例中,所述當判斷為是時,根據所述請求對待發(fā)送的文件進行壓縮處理的步驟,包括:
[0015]當判斷為是時,獲取待發(fā)送的文件的屬性信息;
[0016]根據獲取的屬性信息確定與所述屬性信息存在預置的對應關系的壓縮算法;
[0017]根據所述請求利用確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
[0018]在其中一個實施例中,所述屬性信息包括第一屬性信息或第二屬性信息;
[0019]所述方法還包括步驟:
[0020]預置第一屬性信息與有損壓縮算法存在第一對應關系;
[0021]預置第二屬性信息與無損壓縮算法存在第二對應關系;
[0022]則所述根據獲取的屬性信息確定與所述屬性信息存在預置的對應關系的壓縮算法的步驟,具體為:
[0023]當獲取的屬性信息為第一屬性信息時,根據所述第一對應關系確定有損壓縮算法;
[0024]或
[0025]當獲取的屬性信息為第二屬性信息時,根據所述第二對應關系確定無損壓縮算法。
[0026]在其中一個實施例中,所述當判斷為是時,根據所述請求對待發(fā)送的文件進行壓縮處理的步驟,包括:
[0027]當判斷為是時,計算待發(fā)送的文件經過壓縮處理后的存儲容量;
[0028]確定計算結果大于或等于容量閾值時,根據所述請求對待發(fā)送的文件進行分卷式壓縮處理。
[0029]本發(fā)明還提出一種終端,所述終端包括:
[0030]接收模塊,用于接收向接收方發(fā)送文件的指令;
[0031]所述接收模塊,還用于接收來自接收方的壓縮待發(fā)送的文件的請求;
[0032]壓縮模塊,用于根據所述接收模塊接收的請求對待發(fā)送的文件進行壓縮處理;
[0033]發(fā)送模塊,用于發(fā)送經過所述壓縮處理的文件。
[0034]在其中一個實施例中,其特征在于,所述終端還包括判斷模塊,用于判斷所述文件的存儲容量是否超出預置的容量閾值;
[0035]所述壓縮模塊,具體用于在所述判斷模塊的判斷結果為是時,根據所述接收模塊接收的請求對待發(fā)送的文件進行壓縮處理。
[0036]在其中一個實施例中,所述壓縮模塊,包括:
[0037]屬性獲取單元,用于當所述判斷模塊的判斷結果為是時,獲取待發(fā)送的文件的屬性信息;
[0038]算法確定單元,用于根據所述屬性獲取單元獲取的屬性信息確定與所述屬性信息存在預置的對應關系的壓縮算法;
[0039]壓縮處理單元,用于根據所述接收模塊接收的請求利用所述算法確定單元確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
[0040]在其中一個實施例中,其特征在于,所述屬性信息包括第一屬性信息或第二屬性信息;
[0041]所述終端還包括預置模塊,用于預置第一屬性信息與有損壓縮算法存在第一對應關系;所述預置模塊,還用于預置第二屬性信息與無損壓縮算法存在第二對應關系;
[0042]所述算法確定單元,具體用于當屬性獲取單元獲取的屬性信息為第一屬性信息時,根據所述預置模塊預置的第一對應關系確定有損壓縮算法;
[0043]或
[0044]當屬性獲取單元獲取的屬性信息為第二屬性信息時,根據所述預置模塊預置的第二對應關系確定無損壓縮算法。
[0045]在其中一個實施例中,其特征在于,所述壓縮模塊,包括:
[0046]容量計算單元,用于當所述判斷模塊的判斷結果為是時,計算待發(fā)送的文件經過壓縮處理后的存儲容量;
[0047]分卷壓縮單元,用于確定所述容量計算單元的計算結果大于或等于容量閾值時,根據所述接收模塊接收的請求對待發(fā)送的文件進行分卷式壓縮處理。[0048]上述發(fā)送文件的方法和終端,通過接收向接收方發(fā)送文件的指令,然后接收來自接收方的壓縮待發(fā)送的文件的請求,根據請求對待發(fā)送的文件進行壓縮處理,發(fā)送經過所述壓縮處理的文件。因此,根據接收方的請求不進行額外的操作而直接對文件進行壓縮,提高了文件發(fā)送的操作上的方便性。
【專利附圖】
【附圖說明】
[0049]圖1為本發(fā)明的實施例中一種發(fā)送文件的方法的流程圖;
[0050]圖2為本發(fā)明的實施例中另一種發(fā)送文件的方法的流程圖;
[0051]圖3為本發(fā)明的實施例中一種終端的結構示意圖;
[0052]圖4為本發(fā)明的實施例中另一種終端的結構示意圖;
[0053]圖5為本發(fā)明的實施例中一種壓縮模塊的結構示意圖;
[0054]圖6為本發(fā)明的實施例中另一種壓縮模塊的結構示意圖。
【具體實施方式】
[0055]如圖1所示,在一個實施例中,本發(fā)明提出了一種發(fā)送文件的方法,該方法由終端來執(zhí)行,具體包括以下內容:
[0056]110、接收向接收方發(fā)送文件的指令。
[0057]用戶通過終端發(fā)送文件,按照傳輸方向來區(qū)分,終端作為發(fā)送方,則接收文件的另一方是步驟110中描述的接收方。用戶要向接收方發(fā)送文件可以在終端的顯示界面上輸入指令,終端則接收向接收方發(fā)送文件的指令。其中,顯示界面可以是終端中文件管理應用的界面,或者是傳輸類應用的界面,或者其他應用程序的界面,在此不做限定。
[0058]120、接收來自接收方的壓縮待發(fā)送的文件的請求。
[0059]為保證文件傳輸的可靠性,接收方會請求對待發(fā)送的文件進行壓縮,終端可以接收該請求進行處理。待發(fā)送的文件,具體指在步驟110中提到的要發(fā)送的文件在未正式發(fā)送之前的狀態(tài)。
[0060]130、根據請求對待發(fā)送的文件進行壓縮處理。
[0061]終端接收到來自接收方的請求后,開始對待發(fā)送的文件進行壓縮處理。壓縮處理的具體過程可以是使用包括有損壓縮算法和/或無損壓縮算法在內的各種壓縮算法對待發(fā)送的文件進行壓縮,最終得到經過壓縮處理的文件。文件的存儲容量在經過壓縮后一般可以大幅減小,即待發(fā)送的文件經過壓縮后存儲容量更小更利于發(fā)送。
[0062]140、發(fā)送經過壓縮處理的文件。
[0063]終端將經過壓縮處理的文件發(fā)送給接收方,完成文件發(fā)送的過程。
[0064]綜上所述,本發(fā)明根據接收方的請求不進行額外的操作而直接對文件進行壓縮,提高了文件發(fā)送的操作上的方便性。
[0065]如圖2所示,在一個實施例中提出了另一種發(fā)送文件的方法,該方法由終端來執(zhí)行,具體包括以下內容:
[0066]210、接收向接收方發(fā)送文件的指令。
[0067]用戶通過終端發(fā)送文件,按照傳輸方向來區(qū)分,終端作為發(fā)送方,則接收文件的另一方是步驟210中描述的接收方。用戶要向接收方發(fā)送文件可以在終端的顯示界面上輸入指令,終端則接收向接收方發(fā)送文件的指令。其中,顯示界面可以是終端中文件管理應用的界面,或者是傳輸類應用的界面,或者其他應用程序的界面,在此不做限定。
[0068]220、接收來自接收方的壓縮待發(fā)送的文件的請求。
[0069]為保證文件傳輸的可靠性,接收方會請求對待發(fā)送的文件進行壓縮,終端可以接收該請求進行處理。待發(fā)送的文件,具體指在步驟110中提到的要發(fā)送的文件在未正式發(fā)送之前的狀態(tài)。
[0070]230、判斷文件的存儲容量是否超出預置的容量閾值。
[0071]理論上對文件壓縮后可以得到比原始文件更小的存儲容量,但在發(fā)送文件的方法的實際運用中,有些文件無論是否經過壓縮,對于傳輸速度以及傳輸的便捷度并沒有改善太多。例如存儲容量為幾十k的小文件,壓縮前后存儲容量變化不大,這直接導致了無論是按照現有技術的方案直接發(fā)送該文件,還是根據本實施例中按接收方的請求對文件進行壓縮處理后再發(fā)送,都沒有帶來傳輸速度和傳輸便捷度的改善。但對于大文件而言,壓縮前后存儲容量變化比較大,根據本實施例中按接收方的請求對文件進行壓縮處理后再發(fā)送會有更好的效果。所以,可以通過預先設置一個容量閾值,然后由終端判斷待發(fā)送的文件的存儲容量是否超出預置的容量閾值,再進行后續(xù)對應的處理。通過對待發(fā)送的文件的存儲容量進行智能判斷,直接提高本實施例處理的效率。
[0072]240、當判斷為是時,根據請求對待發(fā)送的文件進行壓縮處理。
[0073]當步驟230得到的判斷結果為待發(fā)送的文件的存儲容量超出了容量閾值時,即認定待發(fā)送的文件比較大,終端根據接收方的請求對待發(fā)送的文件進行壓縮處理。壓縮處理的具體過程可以是使用包括有損壓縮算法和/或無損壓縮算法在內的各種壓縮算法對待發(fā)送的文件進行壓縮,最終得到經過壓縮處理的文件。
[0074]250、發(fā)送經過壓縮處理的文件。
[0075]終端將經過壓縮處理的文件發(fā)送給接收方,完成文件發(fā)送的過程。
[0076]在其中一個實施例中,步驟240具體可以通過以下步驟241至243來實現。即步驟240具體包括:
[0077]241、當判斷為是時,獲取待發(fā)送的文件的屬性信息。
[0078]當步驟230得到的判斷結果為待發(fā)送的文件的存儲容量超出了容量閾值時,終端開始獲取待發(fā)送的文件的屬性信息。例如,屬性信息中可以是說明文件的類型的信息,通過文件的類型能夠得知該文件是音頻文件、視頻文件、文本文件、圖像文件或者其他類型的文件。屬性信息還可以是描述文件的其他屬性的信息,在此不做限定。
[0079]242、根據獲取的屬性信息確定與屬性信息存在預置的對應關系的壓縮算法。
[0080]待發(fā)送的文件中可以是屬性信息相同的文件的集合,也可以是屬性信息不同的文件的集合。當待發(fā)送的文件的屬性信息不同時,使用同樣的壓縮算法來進行壓縮處理,并不能獲得最佳的效果。所以可以通過預先設置文件的屬性信息和壓縮算法之間存在對應關系的方式,根據待發(fā)送的文件的屬性信息來確定使用哪種壓縮算法。以待發(fā)送的文件包含視頻文件A和文本文件B,文件的屬性信息為文件的類型為例,對A和B使用同樣的壓縮算法不能獲得最好的壓縮效果,所以可以根據A和B的類型不同,確定使用不同的壓縮算法。
[0081]243、根據請求利用確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
[0082]當步驟242確定了壓縮算法后,終端根據接收方的請求,利用確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
[0083]在其中一個實施例中,步驟241中提到的屬性信息包括第一屬性信息或第二屬性信息;
[0084]本實施例方法還包括步驟:
[0085]預置第一屬性信息與有損壓縮算法存在第一對應關系;
[0086]預置第二屬性信息與無損壓縮算法存在第二對應關系。
[0087]則步驟242具體為:
[0088]當獲取的屬性信息為第一屬性信息時,根據第一對應關系確定有損壓縮算法;或當獲取的屬性信息為第二屬性信息時,根據第二對應關系確定無損壓縮算法。
[0089]仍然以待發(fā)送的文件包含視頻文件A和文本文件B,文件的屬性信息為文件的類型為例,其中,文本類型屬于第一屬性信息,視頻類型屬于第二屬性信息;壓縮算法包括有損壓縮算法Cl和無損壓縮算法C2。終端內預先設置了視頻類型與有損壓縮算法存在第一對應關系;文本類型與無損壓縮算法存在第二對應關系。具體地,當獲取到待發(fā)送的文件A是視頻類型時,根據第一對應關系確定有損壓縮算法Cl,相應地,后續(xù)則利用有損壓縮算法Cl對文件A進行壓縮處理;或當獲取待發(fā)送的文件B是文本類型時,根據第二對應關系確定無損壓縮算法C2,相應地,后續(xù)則利用有損壓縮算法C2對文件B進行壓縮處理。通過區(qū)分待發(fā)送文件的不同屬性信息,使用對應的壓縮算法對各個文件進行壓縮處理,能夠獲得較好的壓縮效果。
[0090]當接收方接收文件存在一些限制,例如每次僅能夠接收特定存儲容量的文件,這種情況下即使對待發(fā)送的文件進行壓縮處理后仍可能出現經過壓縮處理后的文件的存儲容量大于接收方的限制,使得發(fā)送文件的過程變得困難。所以,在其中一個實施例中,步驟240具體可以通過以下步驟244至245來實現。即步驟240具體包括:
[0091]244、當判斷為是時,計算待發(fā)送的文件經過壓縮處理后的存儲容量。
[0092]當步驟230得到的判斷結果為待發(fā)送的文件的存儲容量超出了容量閾值時,開始計算待發(fā)送的文件經過壓縮處理后的存儲容量。即此時不進行壓縮,通過計算存儲容量的方式預估待發(fā)送的文件經過壓縮處理后的情況。
[0093]245、確定計算結果大于或等于容量閾值時,根據請求對待發(fā)送的文件進行分卷式壓縮處理。
[0094]根據步驟244中得到的計算結果,確定待發(fā)送的文件經過壓縮處理后的存儲容量大于或等于容量閾值時,終端根據接收方的請求對待發(fā)送的文件進行分卷式壓縮處理。
[0095]可以將容量閾值調整為小于或者等于接收方接收文件限制的數值,然后通過預估的方式進行計算,根據計算結果確定待發(fā)送的文件經過壓縮處理后的存儲容量大于或等于容量閾值,按照分卷式壓縮處理的方法將待發(fā)送的文件壓縮成若干個小文件,每個小文件的存儲容量滿足接收方的限制要求。
[0096]如圖3所示,本發(fā)明還提出一種終端,終端包括:
[0097]接收模塊310,用于接收向接收方發(fā)送文件的指令;
[0098]接收模塊310,還用于接收來自接收方的壓縮待發(fā)送的文件的請求;
[0099]壓縮模塊320,用于根據接收模塊310接收的請求對待發(fā)送的文件進行壓縮處理;
[0100]發(fā)送模塊330,用于發(fā)送經過壓縮模塊320壓縮處理的文件。[0101]接收模塊310接收向接收方發(fā)送文件的指令;接收模塊310接收來自接收方的壓縮待發(fā)送的文件的請求;壓縮模塊320根據接收模塊310接收的請求對待發(fā)送的文件進行壓縮處理;發(fā)送模塊330發(fā)送經過壓縮模塊320壓縮處理的文件。
[0102]用戶通過終端發(fā)送文件,按照傳輸方向來區(qū)分,終端作為發(fā)送方,則接收文件的另一方是接收方。用戶要向接收方發(fā)送文件可以在終端的顯示界面上輸入指令,接收模塊310則接收向接收方發(fā)送文件的指令。其中,顯示界面可以是終端中文件管理應用的界面,或者是傳輸類應用的界面,或者其他應用程序的界面,在此不做限定。
[0103]為保證文件傳輸的可靠性,接收方會請求對待發(fā)送的文件進行壓縮,接收模塊310可以接收該請求進行處理。待發(fā)送的文件,具體指要發(fā)送的文件在未正式發(fā)送之前的狀態(tài)。
[0104]壓縮模塊320根據接收模塊310接收的請求對待發(fā)送的文件進行壓縮處理,其中壓縮處理的具體過程可以是使用包括有損壓縮算法和/或無損壓縮算法在內的各種壓縮算法對待發(fā)送的文件進行壓縮,最終得到經過壓縮處理的文件。文件的存儲容量在經過壓縮后一般可以大幅減小,即待發(fā)送的文件經過壓縮后存儲容量更小更利于發(fā)送。然后由發(fā)送模塊330將經過壓縮模塊320壓縮處理的文件發(fā)送出去。
[0105]從中可以看出,本發(fā)明根據接收方的請求不進行額外的操作而直接對文件進行壓縮,提高了文件發(fā)送的操作上的方便性。
[0106]如圖4所示,在一個實施例中提出了另一種終端,該終端包括:
[0107]接收模塊410,用于接收向接收方發(fā)送文件的指令;
[0108]接收模塊410,還用于接收來自接收方的壓縮待發(fā)送的文件的請求;
[0109]判斷模塊420,用于根據接收模塊410接收的請求判斷文件的存儲容量是否超出預置的容量閾值;
[0110]壓縮模塊430,用于在判斷模塊340的判斷結果為是時,根據接收模塊410接收的請求對待發(fā)送的文件進行壓縮處理;
[0111]發(fā)送模塊440,用于發(fā)送經過壓縮模塊430壓縮處理的文件。
[0112]接收模塊410接收向接收方發(fā)送文件的指令;接收模塊410還接收來自接收方的壓縮待發(fā)送的文件的請求;判斷模塊420根據接收模塊410接收的請求判斷待發(fā)送的文件的存儲容量是否超出預置的容量閾值;壓縮模塊430在判斷模塊340的判斷結果為是時,根據接收模塊410接收的請求對待發(fā)送的文件進行壓縮處理;發(fā)送模塊440發(fā)送經過壓縮模塊430壓縮處理的文件。
[0113]理論上對文件壓縮后可以得到比原始文件更小的存儲容量,但在實際運用中,有些文件無論是否經過壓縮,對于傳輸速度以及傳輸的便捷度并沒有改善太多。例如存儲容量為幾十k的小文件,壓縮前后存儲容量變化不大,這直接導致了無論是按照現有技術的方案直接發(fā)送該文件,還是按接收方的請求對文件進行壓縮處理后再發(fā)送,都沒有帶來傳輸速度和傳輸便捷度的改善。但對于大文件而言,壓縮前后存儲容量變化比較大,壓縮模塊430按接收方的請求對文件進行壓縮處理后再發(fā)送會有更好的效果。所以,可以通過預先設置一個容量閾值,然后由判斷模塊420根據接收模塊410接收的請求判斷待發(fā)送的文件的存儲容量是否超出預置的容量閾值,再進行后續(xù)對應的處理。通過對待發(fā)送的文件的存儲容量進行智能判斷,直接提高本實施例處理的效率。
[0114]當判斷模塊420得到的判斷結果為待發(fā)送的文件的存儲容量超出了容量閾值時,即認定待發(fā)送的文件比較大,壓縮模塊430再對待發(fā)送的文件進行壓縮處理。壓縮處理的具體過程可以是使用包括有損壓縮算法和/或無損壓縮算法在內的各種壓縮算法對待發(fā)送的文件進行壓縮,最終得到經過壓縮處理的文件。
[0115]如圖5所示,在其中一個實施例中,壓縮模塊430包括屬性獲取單元510、算法確定單元520和壓縮處理單元530。
[0116]屬性獲取單元510,用于當判斷模塊420的判斷結果為是時,獲取待發(fā)送的文件的屬性信息;例如,屬性信息中可以是說明文件的類型的信息,通過文件的類型能夠得知該文件是音頻文件、視頻文件、文本文件、圖像文件或者其他類型的文件。屬性信息還可以是描述文件的其他的屬性信息,在此不做限定。
[0117]算法確定單元520,用于根據屬性獲取單元510獲取的屬性信息確定與屬性信息存在預置的對應關系的壓縮算法。待發(fā)送的文件中可以是屬性信息相同的文件的集合,也可以是屬性信息不同的文件的集合。當待發(fā)送的文件的屬性信息不同時,使用同樣的壓縮算法來進行壓縮處理,并不能獲得最佳的效果。所以可以通過預先設置文件的屬性信息和壓縮算法之間存在對應關系的方式,根據待發(fā)送的文件的屬性信息來確定使用哪種壓縮算法。以待發(fā)送的文件包含視頻文件A和文本文件B,文件的屬性信息為文件的類型為例,對A和B使用同樣的壓縮算法不能獲得最好的壓縮效果,所以可以根據A和B的類型不同,確定使用不同的壓縮算法。
[0118]壓縮處理單元530,用于根據接收模塊410接收的請求利用算法確定單元520確定的壓縮算法對待發(fā)送的文件進行壓縮處理。當算法確定單元520確定了壓縮算法后,終端根據接收方的請求,利用確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
[0119]在其中一個實施例中,屬性獲取單元510要獲取的屬性信息包括第一屬性信息或第二屬性信息。終端還包括預置模塊,用于預置第一屬性信息與有損壓縮算法存在第一對應關系;預置模塊,還用于預置第二屬性信息與無損壓縮算法存在第二對應關系。算法確定單元520,具體用于當屬性獲取單元510獲取的屬性信息為第一屬性信息時,根據預置模塊預置的第一對應關系確定有損壓縮算法;或當屬性獲取單元510獲取的屬性信息為第二屬性信息時,根據預置模塊預置的第二對應關系確定無損壓縮算法。
[0120]仍然以待發(fā)送的文件包含視頻文件A和文本文件B,文件的屬性信息為文件的類型為例,其中,文本類型屬于第一屬性信息,視頻類型屬于第二屬性信息;壓縮算法包括有損壓縮算法Cl和無損壓縮算法C2。預置模塊預先設置了視頻類型與有損壓縮算法存在第一對應關系;文本類型與無損壓縮算法存在第二對應關系。具體地,當屬性獲取單元510獲取到待發(fā)送的文件A是視頻類型時,算法確定單元520根據第一對應關系確定有損壓縮算法Cl,相應地,后續(xù)壓縮處理單元530則利用有損壓縮算法Cl對文件A進行壓縮處理;或當屬性獲取單元510獲取待發(fā)送的文件B是文本類型時,算法確定單元520根據第二對應關系確定無損壓縮算法C2,相應地,后續(xù)壓縮處理單元530則利用有損壓縮算法C2對文件B進行壓縮處理。通過區(qū)分待發(fā)送文件的不同屬性信息,使用對應的壓縮算法對各個文件進行壓縮處理,能夠獲得較好的壓縮效果。
[0121]當接收方接收文件存在一些限制,例如每次僅能夠接收特定存儲容量的文件,這種情況下即使對待發(fā)送的文件進行壓縮處理后仍可能出現經過壓縮處理后的文件的存儲容量大于接收方的限制,使得發(fā)送文件的過程變得困難。所以,如圖6所示,在其中一個實施例中,壓縮模塊430包括容量計算單元610和分卷壓縮單元620。
[0122]容量計算單元610,用于當判斷模塊420的判斷結果為是時,計算待發(fā)送的文件經過壓縮處理后的存儲容量;當判斷模塊420得到的判斷結果為待發(fā)送的文件的存儲容量超出了容量閾值時,開始計算待發(fā)送的文件經過壓縮處理后的存儲容量。即此時不進行壓縮,由容量計算單元610計算來預估待發(fā)送的文件經過壓縮處理后的存儲容量。
[0123]分卷壓縮單元620,用于確定容量計算單元610的計算結果大于或等于容量閾值時,根據接收模塊410接收的請求對待發(fā)送的文件進行分卷式壓縮處理。根據容量計算單元610得到的計算結果,確定待發(fā)送的文件經過壓縮處理后的存儲容量大于或等于容量閾值時,分卷壓縮單元620根據接收方的請求對待發(fā)送的文件進行分卷式壓縮處理。具體地,可以將容量閾值調整為小于或者等于接收方接收文件限制的數值,然后容量計算單元610計算來預估;分卷壓縮單元620根據計算結果確定待發(fā)送的文件經過壓縮處理后的存儲容量大于或等于容量閾值,按照分卷式壓縮處理的方法將待發(fā)送的文件壓縮成若干個小文件,每個小文件的存儲容量滿足接收方的限制要求。
[0124]本領域普通技術人員可以理解實現上述實施例方法中的全部或部分流程,是可以通過計算機程序來指令相關的硬件來完成,所述的程序可存儲于一計算機可讀取存儲介質中,該程序在執(zhí)行時,可包括如上述各方法的實施例的流程。其中,所述的存儲介質可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory, ROM)或隨機存儲記憶體(Random AccessMemory, RAM)等。
[0125]以上所述實施例僅表達了本發(fā)明的幾種實施方式,其描述較為具體和詳細,但并不能因此而理解為對本發(fā)明專利范圍的限制。應當指出的是,對于本領域的普通技術人員來說,在不脫離本發(fā)明構思的前提下,還可以做出若干變形和改進,這些都屬于本發(fā)明的保護范圍。因此,本發(fā)明專利的保護范圍應以所附權利要求為準。
【權利要求】
1.一種發(fā)送文件的方法,其特征在于,所述方法包括: 接收向接收方發(fā)送文件的指令; 接收來自接收方的壓縮待發(fā)送的文件的請求; 根據所述請求對待發(fā)送的文件進行壓縮處理; 發(fā)送經過所述壓縮處理的文件。
2.根據權利要求1所述的方法,其特征在于,所述方法還包括步驟:判斷所述文件的存儲容量是否超出預置的容量閾值; 則所述根據所述請求對待發(fā)送的文件進行壓縮處理的步驟,具體為: 當判斷為是時,根據所述請求對待發(fā)送的文件進行壓縮處理。
3.根據權利要求2所述的方法,其特征在于,所述當判斷為是時,根據所述請求對待發(fā)送的文件進行壓縮處理的步驟,包括: 當判斷為是時,獲取待發(fā)送的文件的屬性信息; 根據獲取的屬性信息確定與所述屬性信息存在預置的對應關系的壓縮算法; 根據所述請求利用確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
4.根據權利要求3所述的方法,其特征在于,所述屬性信息包括第一屬性信息或第二屬性信息; 所述方法還包括步驟: 預置第一屬性信息與有損壓縮算法存在第一對應關系; 預置第二屬性信息與無損壓縮算法存在第二對應關系; 則所述根據獲取的屬性信息確定與所述屬性信息存在預置的對應關系的壓縮算法的步驟,具體為: 當獲取的屬性信息為第一屬性信息時,根據所述第一對應關系確定有損壓縮算法; 或 當獲取的屬性信息為第二屬性信息時,根據所述第二對應關系確定無損壓縮算法。
5.根據權利要求2所述的方法,其特征在于,所述當判斷為是時,根據所述請求對待發(fā)送的文件進行壓縮處理的步驟,包括: 當判斷為是時,計算待發(fā)送的文件經過壓縮處理后的存儲容量; 確定計算結果大于或等于容量閾值時,根據所述請求對待發(fā)送的文件進行分卷式壓縮處理。
6.—種終端,其特征在于,所述終端包括: 接收模塊,用于接收向接收方發(fā)送文件的指令; 所述接收模塊,還用于接收來自接收方的壓縮待發(fā)送的文件的請求; 壓縮模塊,用于根據所述接收模塊接收的請求對待發(fā)送的文件進行壓縮處理; 發(fā)送模塊,用于發(fā)送經過所述壓縮處理的文件。
7.根據權利要求6所述的終端,其特征在于,所述終端還包括判斷模塊,用于判斷所述文件的存儲容量是否超出預置的容量閾值; 所述壓縮模塊,具體用于在所述判斷模塊的判斷結果為是時,根據所述接收模塊接收的請求對待發(fā)送的文件進行壓縮處理。
8.根據權利要求7所述的終端,其特征在于,所述壓縮模塊,包括:屬性獲取單元,用于當所述判斷模塊的判斷結果為是時,獲取待發(fā)送的文件的屬性信息; 算法確定單元,用于根據所述屬性獲取單元獲取的屬性信息確定與所述屬性信息存在預置的對應關系的壓縮算法; 壓縮處理單元,用于根據所述接收模塊接收的請求利用所述算法確定單元確定的壓縮算法對待發(fā)送的文件進行壓縮處理。
9.根據權利要求8所述的終端,其特征在于,所述屬性信息包括第一屬性信息或第二屬性信息; 所述終端還包括預置模塊,用于預置第一屬性信息與有損壓縮算法存在第一對應關系;所述預置模塊,還用于預置第二屬性信息與無損壓縮算法存在第二對應關系; 所述算法確定單元,具體用于當屬性獲取單元獲取的屬性信息為第一屬性信息時,根據所述預置模塊預置的第一對應關系確定有損壓縮算法; 或 當屬性獲取單元獲取的屬性信息為第二屬性信息時,根據所述預置模塊預置的第二對應關系確定無損壓縮算法。
10.根據權利要求7所述的終端,其特征在于,所述壓縮模塊,包括: 容量計算單元,用于當所述判斷模塊的判斷結果為是時,計算待發(fā)送的文件經過壓縮處理后的存儲容量; 分卷壓縮單元,用于確定所述 容量計算單元的計算結果大于或等于容量閾值時,根據所述接收模塊接收的請求對待發(fā)送的文件進行分卷式壓縮處理。
【文檔編號】H04L29/08GK103701852SQ201310611437
【公開日】2014年4月2日 申請日期:2013年11月26日 優(yōu)先權日:2013年11月11日
【發(fā)明者】黃樹生 申請人:珠海市魅族科技有限公司