專利名稱:彩信的傳輸方法、系統(tǒng)、以及終端的制作方法
技術領域:
本發(fā)明涉及通信領域,尤其涉及一種彩信的傳輸方法、系統(tǒng)、以及終端。 彩信又稱為多媒體信息業(yè)務(Multimedia Messaging Service,簡稱為匪S),該業(yè) 務是移動運營商推出的以無線應用協(xié)議(Wireless ApplicationProtocol,簡稱為WAP)為 載體傳送多媒體的短信業(yè)務。 與傳統(tǒng)的短信息業(yè)務相比,彩信除了可以傳輸基本的文字信息以外,能夠支持多 媒體功能,可以傳輸內(nèi)容豐富的彩色圖像、聲音、動畫、振動、視頻等各種格式的多媒體內(nèi) 容,隨著彩信業(yè)務的不斷發(fā)展,傳輸?shù)膬?nèi)容還可以包括配有現(xiàn)場圖片的體育新聞、卡通漫 畫、內(nèi)容豐富的賀卡、動畫游戲等應用內(nèi)容,并且能夠實現(xiàn)即時的手機端到端、手機終端到 互聯(lián)網(wǎng)、或互聯(lián)網(wǎng)到手機終端的多媒體信息傳送。 目前,用戶使用的大多數(shù)手機終端都帶有支持彩信業(yè)務的應用,該應用主要可以 分為以下功能模塊彩信編輯模塊、彩信收發(fā)模塊、彩信消息管理模塊、彩信播放模塊等。其 中,彩信編輯模塊是手機用戶能隨意編輯或插入期望的多媒體文件,多媒體文件的格式可 以包括圖片、音頻、視頻等,在根據(jù)一定的協(xié)議對多媒體文件編碼后,即可發(fā)送給另一手機 終端;彩信播放模塊是對手機用戶下載后保存在本機上的彩信消息文件進行解碼播放,即 將包含在彩信消息中的諸如文字、圖像、聲音、視頻等多媒體單元呈現(xiàn)給手機用戶。
在目前的彩信協(xié)議中,在編輯一條彩信時,運營商會對編輯或附加的多媒體文件 的總大小進行限制,通常將多媒體文件的大小限制在幾百K以內(nèi)(例如,限制在300K以 內(nèi)),也就是說用戶在加入多媒體文件時,對要加入的多媒體是有限制的,不是任意大小的 文件都可以加入彩信進行傳輸。 目前,隨著手機產(chǎn)業(yè)的快速發(fā)展,手機硬件中各個模塊都有了很大的進步,例如, 手機中的攝像頭的分辨率從以前的幾十萬像素發(fā)展到幾百萬甚至更高的像素。而像素較多 的攝像頭拍攝的一幅圖像經(jīng)過中等壓縮后存儲到手機終端里的Jpg圖像大小會達到1M或 更多左右。因此,現(xiàn)有的手機終端中通常不能夠支持對這種大容量的文件進行彩信發(fā)送,而 是會將附件過大的信息直接提示給用戶。 為了避免這種因為文件過大而不能通過彩信傳輸?shù)膯栴},一些終端能夠對大容量 圖片進行壓縮,之后再進行彩信發(fā)送。圖1示出了相關技術中在彩信大小限制為300K的情 況下進行圖片插入的過程。如圖l所示,在彩信編輯過程中,如果用戶插入已有圖片文件 或插入通過拍攝得到的1M左右的圖片文件,終端會首先判斷插入的圖片是否超過要求的 300K,如果判斷結果為否,則直接插入該圖片文件,如果判斷結果為是,則對圖片進行壓縮 到300K以內(nèi)再進行插入。 但是,這種壓縮過程會明顯降低圖片的分辨率,影響圖片的效果,這樣在接收方收 到的圖片效果就大打折扣。 而對于大小超過運營商要求視頻文件和音頻文件,目前還沒有提出如何通過彩信
背景技術:
傳輸?shù)姆桨浮?因此,由于彩信傳輸過程中對附加文件的大小存在限制,從而影響彩信業(yè)務的應
用,降低用戶的體驗,針對該問題,目前尚未提出有效的解決方案。
發(fā)明內(nèi)容
針對相關技術中由于彩信傳輸受到附加文件大小的限制而影響彩信業(yè)務應用的
問題,本發(fā)明提出一種彩信的傳輸方法、系統(tǒng)、以及終端,能夠在保證彩信大小不超過限制 的前提下實現(xiàn)大容量文件的彩信傳輸。 本發(fā)明的技術方案是這樣實現(xiàn)的 根據(jù)本發(fā)明的一個方面,提供了一種彩信的傳輸方法。 根據(jù)本發(fā)明的彩信的傳輸方法包括判斷待發(fā)送的彩信的大小是否超過預定值; 在判斷彩信的大小超過預定值的情況下,對彩信進行分解,得到多個子彩信,其中,多個子 彩信中每個子彩信的大小均小于或等于預定值;將每個子彩信所對應的分解規(guī)則信息加入 到相應的子彩信中,并將加入分解規(guī)則信息后的多個子彩信發(fā)送至接收方,其中,分解規(guī)則 信息用于拼接多個子彩信。 其中,判斷待發(fā)送的彩信的大小是否超過預定值具體包括在判斷彩信中插入的 打包后的一個或多個多媒體文件的總大小超過預定值的情況下,判斷彩信的大小超過預定值。 并且,對彩信進行分解得到多個子彩信具體包括對打包后的一個或多個多媒體 文件作為整體進行分解,得到多個多媒體子文件;對于多個多媒體子文件中的每個多媒體 子文件,將多媒體子文件進行打包得到一個子彩信;并且,每個子彩信的大小均小于預定值 是指每個多媒體子文件的大小均小于預定值。 并且,該方法可進一步包括接收方接收發(fā)送的多個子彩信,并在多個子彩信接收 完畢之后根據(jù)多個子彩信的分解規(guī)則信息對多個子彩信進行拼接。 具體地,根據(jù)多個子彩信的分解規(guī)則信息對多個子彩信進行拼接具體包括對多 個子彩信的打包后的多媒體子文件進行解碼,并對解碼后的多個多媒體子文件進行拼接, 得到打包后的多媒體文件。 優(yōu)選地,每個子彩信所對應的分解規(guī)則信息包括該子彩信所屬的彩信的標識、對
彩信進行分解時該子彩信在多個子彩信中的排序和多個子彩信的總數(shù)。
并且,對于每個子彩信,其對應的分解規(guī)則信息被加入在該子彩信的文本部分。 此外,對彩信進行分解的處理可以包括將彩信平均分解為大小相等多個的子彩
信、或者以預定值為單位對彩信進行分解。 根據(jù)本發(fā)明的另一方面,提供了一種終端,該終端包括判斷模塊,用于判斷待發(fā)
送的彩信的大小是否超過預定值;分解模塊,用于在判斷模塊的判斷結果為是的情況下,對
彩信進行分解,得到多個子彩信,其中,多個子彩信中每個子彩信的大小均小于或等于預定
值;發(fā)送模塊,用于將每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并將加入
分解規(guī)則信息后的多個子彩信發(fā)送至接收方,其中,分解規(guī)則信息用于拼接多個子彩信。
根據(jù)本發(fā)明的再一方面,提供了一種終端,該終端包括接收模塊,用于接收彩信;
拼接模塊,用于接收模塊接收到屬于彩信的全部子彩信之后根據(jù)接收的每個子彩信的分解規(guī)則信息對子彩信進行拼接。 根據(jù)本發(fā)明的另一方面,還提供了一種彩信的傳輸系統(tǒng),包括發(fā)送方終端和接收 方終端。 在該系統(tǒng)中,發(fā)送方終端包括判斷模塊,用于判斷待發(fā)送的彩信的大小是否超過
預定值;分解模塊,用于在判斷模塊的判斷結果為是的情況下,對彩信進行分解,得到多個
子彩信,其中,多個子彩信中每個子彩信的大小均小于或等于預定值;發(fā)送模塊,用于將每
個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并將加入分解規(guī)則信息后的多個
子彩信經(jīng)由網(wǎng)絡發(fā)送至接收方終端,其中,分解規(guī)則信息用于拼接多個子彩信; 接收方終端包括接收模塊,用于接收彩信;拼接模塊,用于接收模塊接收到屬于
彩信的全部子彩信之后根據(jù)接收的每個子彩信的分解規(guī)則信息對多個子彩信進行拼接。 本發(fā)明通過對大容量彩信(即,大小超過要求的彩信)進行分解,得到大小滿足要
求多個彩信并發(fā)送到接收方,由接收方對多個彩信進行拼接,還原大容量的多媒體文件,能
夠避免傳輸大容量圖像文件時對文件進行壓縮;并且能夠在保證彩信大小不超過限制的前
提下實現(xiàn)大容量視頻文件、大容量音頻文件、以及大容量應用程序等各種文件的彩信傳輸,
有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶體驗。
圖1是相關技術中通過彩信以壓縮的方式發(fā)送大容量圖片的處理流程圖;
圖2是根據(jù)本發(fā)明實施例的彩信的傳輸方法流程圖; 圖3是根據(jù)本發(fā)明實施例的彩信的傳輸方法中彩信分解和發(fā)送的詳細處理流程 圖; 圖4是根據(jù)本發(fā)明實施例的彩信的傳輸方法中彩信接收和拼接的詳細處理流程 圖。
具體實施例方式
針對相關技術中由于彩信傳輸受到附加文件大小的限制而影響彩信業(yè)務應用的 問題,本發(fā)明提出,對大容量彩信(即,大小超過要求的彩信)進行分解,得到大小滿足要求 多個彩信(下文中將分解后得到的彩信稱為子彩信)并發(fā)送到接收方,由接收方對多個彩 信進行拼接,還原大容量的多媒體文件,能夠避免傳輸大容量圖像文件時對文件進行壓縮, 并且能夠實現(xiàn)大容量視頻文件、大容量音頻文件、以及大容量應用程序等各種文件的彩信 傳輸,有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶體驗。
下面將詳細描述本發(fā)明的實施例。
方法實施例 在本實施例中,提供了 一種彩信的傳輸方法。 如圖2所示,根據(jù)本實施例的彩信的傳輸方法包括 步驟S201,判斷待發(fā)送的彩信的大小是否超過預定值(該預定值可以由運營商自 行定義,例如,可以定義為300K、200K等); 步驟S203,在判斷結果為是的情況下,對彩信進行分解,得到多個子彩信,其中,多 個子彩信中每個子彩信的大小均小于或等于預定值;另外,如果判斷結果為否,則可以按照正常的發(fā)送方式發(fā)送彩信; 步驟S205,將每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并將加 入分解規(guī)則信息后的多個子彩信發(fā)送至接收方,其中,分解規(guī)則信息用于拼接多個子彩信。
通過上述處理,能夠對大容量彩信(即,大小超過要求的彩信)進行分解得到大小 滿足要求多個彩信并發(fā)送到接收方,以便接收方對多個彩信進行拼接,還原大容量的多媒 體文件,能夠避免傳輸大容量圖像文件時對文件進行壓縮,并且能夠實現(xiàn)大容量視頻文件、 大容量音頻文件、以及大容量應用程序等各種文件的彩信傳輸,保證圖像、音頻、視頻等文 件傳輸后質量不會降低,有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶 體驗。 由于彩信中所占容量空間最大的部分是多媒體文件,其余部分所占的空間很小, 因此,在步驟S201中判斷待發(fā)送的彩信的大小是否超過預定值時,可以將多媒體文件以外 的其他部分忽略,僅判斷彩信中插入的打包后的一個或多個多媒體文件的總大小是否超過 預定值,在判斷結果為是的情況下確定彩信的大小超過預定值。 在步驟S203中對彩信進行分解得到多個子彩信時,可以對打包后的一個或多個 多媒體文件作為整體進行分解,得到多個多媒體子文件(可以將多媒體子文件作為內(nèi)存塊 Buff);之后,對于多個多媒體子文件中的每個多媒體子文件,將多媒體子文件進行打包得 到一個子彩信,每個多媒體子文件作為一個子彩信發(fā)送;同樣,對于子彩信大小判斷,同樣 可以僅考慮多媒體子文件的大小,也就是說,在每個多媒體子文件的大小均小于預定值的 情況下,就認為每個子彩信的大小均符合要求。 在發(fā)送了分解并打包后的多個子彩信之后,接收方可以接收多個子彩信,并在多
個子彩信接收完畢之后根據(jù)多個子彩信的分解規(guī)則信息對多個子彩信進行拼接。 在進行彩信拼接時,可以對多個子彩信的打包后的多媒體子文件進行解碼(將多
媒體子文件還原為打包前的形式),之后對解碼后的多個多媒體子文件進行拼接,得到打包
后的多媒體文件,通過解碼后即可還原多媒體文件。 本發(fā)明采用的分解規(guī)則信息可以有多種形式,也就是說,可以通過多種方式進行 彩信的拼接。 例如,每個子彩信所對應的分解規(guī)則信息包括該子彩信所屬的彩信的標識、對彩 信進行分解時該子彩信在多個子彩信中的排序和多個子彩信的總數(shù)。這樣,接收方就能夠 根據(jù)彩信的標識區(qū)分屬于彩信的子彩信,并根據(jù)由彩信分解的子彩信的總數(shù)量確定當前接 收的子彩信是否是該彩信的所有子彩信,在確定所有子彩信均接收完之后,就可以根據(jù)每 個子彩信的排序對多個子彩信進行拼接,之后,接收模塊的彩信瀏覽模塊可以對拼接后的 彩信內(nèi)容進行顯示。 在上述處理中,對于每個子彩信,其對應的分解規(guī)則信息被加入在該子彩信的文 本部分,多媒體文件可以附加在該子彩信的文件區(qū)域。 并且,可選地,對彩信進行分解時,可以將彩信作為整體(其中可能包含多個文 件)平均分解為大小相等多個的子彩信、或者以預定值為單位對彩信進行分解,也就是說, 假設對彩信大小的限制為300K,此時,對于1個1M大小的彩信,則可以將該彩信平均分為4 個256K的彩信,或者,也可以分為3個300K的彩信以及1個124K的彩信。此外,在多媒體 文件包含多個文件的情況下,可以判斷這多個文件中的每一個的大小是否小于要求值,如果判斷為否,則可以將多媒體文件作為整體,并采用上述分解方式進行分解,如果每個文件的大小均小于要求值,則還可以將每個文件均通過一個單獨的彩信發(fā)送。此外,還可以采用其他的方式對彩信進行分解,例如,將該1M大小的彩信分為5個或更多彩信,本文不再一一列舉。 圖3是根據(jù)本實施例的彩信傳輸方法中彩信發(fā)送的詳細處理過程的流程圖。如圖3所示,具體可以包括以下步驟 步驟31 :用戶在編輯彩信過程中加入多媒體文件(即,加入上述的一個或多個多媒體文件); 步驟32,判斷加入的一個或多個多媒體文件的大小,先判斷加入的這個文件和現(xiàn)有的文件大小是否大于運營商限制的300K,如果總大小小于或等于300K,則直接加入此文件,執(zhí)行步驟37,將插入的文件的內(nèi)容打包成一條彩信加入彩信發(fā)送隊列;如果加入的一個或多個多媒體文件的大小大于300K,則執(zhí)行步驟33 ; 步驟33,如果加入的文件中包括多個文件,則判斷單個文件的大小是否小于或等于300K,如果每個多媒體文件的大小均小于或等于300K,則執(zhí)行步驟37,將單個文件打包成一條彩信加入彩信發(fā)送隊列,以便后續(xù)進行發(fā)送,否則執(zhí)行步驟34 ;
步驟34,如果單個文件的大小大于300K,則需要對用戶插入的多媒體文件作為整體進行打包; 步驟35,分析打包后的內(nèi)容大小和運營商對文件的限制大小,并對打包后的多媒體文件進行分解操作,分解后得到小于300K的小塊內(nèi)容(即,得到多個多媒體子文件);
之后,需要對這些小塊內(nèi)容進行打包,S卩,得到上述的多個子彩信。其中,在打包時,由于需要考慮接收方合成文件的操作,所以可以將小塊的分解規(guī)則信息加入到每個子彩信的文本信息里,以便接收方對多個子彩信中的多媒體文件進行拼接;
步驟36-1至步驟36-n,對分解后的內(nèi)容1至內(nèi)容n ( S卩,分解后的第一個多媒體子文件至第n個多媒體子文件)增加分解規(guī)則B_XX_N_1并重新打包,其中,B表示該內(nèi)容為分解后的內(nèi)存塊Buff, XX為分解前打包后得到的多媒體文件所屬的彩信的唯一標識,N為彩信的多媒體文件分解得到的多媒體子文件的數(shù)量(該數(shù)量等于子彩信的數(shù)量),n標識1表示該內(nèi)容(多媒體子文件)在多個多媒體子文件中的排序為第一個;對于分解后的內(nèi)容2 (即,分解后的第二個多媒體子文件),其分解規(guī)則信息為B_XX_N_2,依此類推,分解后的內(nèi)容n的分解規(guī)則信息為B_XX_N_n。 步驟37,將打包后符合彩信大小限制要求的彩信加入發(fā)送隊列。 在上述處理中,對一個或多個多媒體文件進行打包時,對于打包后得到彩信,可以
將其視為內(nèi)存塊Buff,其大小可以設為S,這個內(nèi)存塊將是接收方收到后的小彩信合成后
的內(nèi)存,并可以顯示出來。 下面將以運營商規(guī)定的預定值為單位對彩信進行分解為例,詳細描述本發(fā)明的彩信傳輸方法中彩信接收的處理過程。 在上述處理中,在對彩信中打包后的多媒體文件的內(nèi)容進行分解時,可以首先計算出將要分解的彩信數(shù)量(N= S/300K),之后再分配N塊小內(nèi)存(Buffl-Buffn),每塊內(nèi)存大小為300K,將Buff里的內(nèi)容分解到這N塊小內(nèi)存中,對這N個小內(nèi)存,可以將其以附件的形式加入到子彩信中,并將分解規(guī)則附到子彩信的文本區(qū)域。其中,分解規(guī)則信息的格式可
8以為B_XX_N_n。 如圖4所示,在本實例中,彩信傳輸過程中接收彩信的處理過程如下
步驟41,接收彩信; 步驟42,對接收到的彩信進行解碼,其中,可以先解碼彩信的Text區(qū)域(該區(qū)域可以是彩信的第一頁內(nèi)容),判斷該區(qū)域中是否包括B_XX_N_n格式,如果判斷結果為是,則確定該彩信是屬于某個彩信的子彩信,并執(zhí)行步驟43 ;否則直接顯示該彩信的內(nèi)容;
步驟43,提取子彩信的XX區(qū)域,該區(qū)域中包括該子彩信所屬的彩信的唯一標識,如果接收方已經(jīng)創(chuàng)建有File—XX文件(做拼接用),則執(zhí)行步驟46 ;如果沒有該文件,則執(zhí)行步驟45,創(chuàng)建File_XX文件,在創(chuàng)建之后執(zhí)行步驟46 ; 步驟46,提取子彩信的N—n區(qū)域,然后對該子彩信中的附件(即,多媒體子文件)進行解碼,得到一個Buffn ; 步驟47,根據(jù)N和n的大小將子彩信的附件寫到File_XX中相應的拼接文件中;
步驟48,判斷當前接收到的子彩信的總數(shù)量是否等于N,如果判斷結果為是,則表示所有的子彩信都已經(jīng)寫入到File_XX文件中,并執(zhí)行步驟49 ;如果判斷結果為否,則表示此時還沒有接收到該彩信分解的所有子彩信,需要返回步驟41繼續(xù)接收;
步驟49,將File_XX文件中的內(nèi)容提取出來保存為一個彩信(即,還原分解前的彩信),通過彩信瀏覽模塊顯示,即,將原彩信的內(nèi)容顯示出來,同時刪除File_XX文件和N個小彩信的文件,以節(jié)省存儲空間。 下面將舉例說明根據(jù)本實施例的彩信傳輸方法進行彩信發(fā)送和接收的處理過程。
以彩信限制大小為300K為例,在進行彩信傳輸?shù)倪^程中,具體包括以下步驟
(1)在手機待機情況下,用戶調(diào)用消息模塊,再進入彩信編輯界面;
(2)在編輯彩信過程中選擇插入一幅大小為1M的Jpg圖片(S卩,多媒體文件),并輸入收件人地址和主題,選擇發(fā)送彩信; (3)對現(xiàn)有的彩信編輯過程中加入的內(nèi)容進行打包(得到彩信),并得到打包后的Buff長度,此時,如果發(fā)現(xiàn)此彩信中的圖片長度大于300K,則需要將這個內(nèi)存分解再打包成多條子彩信進行發(fā)送; (4)需要分解成1024/300+1 = 4條彩信發(fā)送出去,并將Buff按300K大小進行分解; (5)對第一個小Buff (第一個多媒體子文件)進行打包以附件的形式加入到小彩信中,并將分解規(guī)則信息附到子彩信的文本區(qū)域。該子彩信的分解規(guī)則信息為B_XX_4_0 ;
(6)對第二、三、四個小Buff(第二、三、四個多媒體子文件)進行打包以附件的形式加入到子彩信中,并將分解規(guī)則信息附到子彩信的文本區(qū)域。類似地,加入的分解規(guī)則信息分別為B—XX—4j、B—XX—4—2、B—XX—4—3,打包完4條彩信后,可以將打包的4條子彩信分別發(fā)送出去; (7)接收端接收到新彩信時,先解碼出第一頁內(nèi)容的Text區(qū)域,發(fā)現(xiàn)是B—XX—4J),為B_XX_N_n格式,則為分解后的彩信,解碼出附件后將附件以File_XX文件保存;
(8)繼續(xù)接收第二條彩信,提取文本區(qū)域B_XX_4_1,發(fā)現(xiàn)有File_XX文件,則將這條彩信的附件提取出來追加到File_XX文件末尾; (9)繼續(xù)接收第三、四條彩信,并進行解碼,根據(jù)N和n的大小對應的寫到File—XX拼接文件中; (10)在拼接結束后,將File_XX文件中的內(nèi)容提取出來保存成一個大彩信(還原彩信)并進行顯示,同時刪除File_XX文件和N個小彩信的文件。 類似地,對于攝像機和錄音機生成的大文件或其他應用程序文件均能夠按一定的規(guī)則進行自動分解,然后分別將分解后的內(nèi)容加到獨立的彩信中進行發(fā)送后,接收方收到這一組彩信后按一定的規(guī)則拼接起來,實現(xiàn)了大彩信的傳輸方案。 通過上述處理,能夠對大容量彩信(即,大小超過要求的彩信)進行分解,得到大小滿足要求多個彩信并發(fā)送到接收方,由接收方對多個彩信進行拼接,還原大容量的多媒體文件,能夠避免傳輸大容量圖像文件時對文件進行壓縮;并且能夠實現(xiàn)大容量視頻文件、大容量音頻文件、以及大容量應用程序等各種文件的彩信傳輸,有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶體驗。
系統(tǒng)實施例 在本實施例中,提供了一種彩信的傳輸系統(tǒng),包括發(fā)送方終端和接收方終端。
其中,發(fā)送方終端包括判斷模塊,用于判斷待發(fā)送的彩信的大小是否超過預定值;分解模塊,用于在判斷模塊的判斷結果為是的情況下,對彩信進行分解,得到多個子彩信,其中,多個子彩信中每個子彩信的大小均小于或等于預定值;發(fā)送模塊,用于將每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并將加入分解規(guī)則信息后的多個子彩信經(jīng)由網(wǎng)絡發(fā)送至接收方終端,其中,分解規(guī)則信息用于拼接多個子彩信;
接收方終端包括接收模塊,用于接收彩信;拼接模塊,用于接收模塊接收到屬于彩信的全部子彩信之后根據(jù)接收的每個子彩信的分解規(guī)則信息對多個子彩信進行拼接。
借助上述系統(tǒng)以及其中的終端,能夠對大容量彩信(即,大小超過要求的彩信)進行分解,得到大小滿足要求多個子彩信并發(fā)送到接收方,由接收方對多個彩信進行拼接,還原大容量的多媒體文件,能夠避免傳輸大容量圖像文件時對文件進行壓縮;并且能夠實現(xiàn)大容量視頻文件、大容量音頻文件、以及大容量應用程序等各種文件的彩信傳輸,有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶體驗。 其中,發(fā)送方終端和接收方終端只是相對概念,在實際應用當中,每個終端均可以具備上述發(fā)送方終端與接收方終端的功能,從而借助本發(fā)明提出的彩信傳輸方案實現(xiàn)終端之間彩信的相互發(fā)送。 根據(jù)本實施例的系統(tǒng)以及其中的終端均能夠實現(xiàn)上述圖2至圖4所示的處理,其中,彩信大小判斷、分解規(guī)則信息的加入與使用、彩信分解、彩信拼接等處理均可以參照之前的描述實現(xiàn),具體過程這里不再重復 綜上所述,借助于本發(fā)明的上述技術方案,通過對大容量彩信(即,大小超過要求的彩信)進行分解,得到大小滿足要求多個彩信并發(fā)送到接收方,由接收方對多個彩信進行拼接,還原大容量的多媒體文件,能夠避免傳輸大容量圖像文件時對文件進行壓縮;并且能夠實現(xiàn)大容量視頻文件、大容量音頻文件、以及大容量應用程序等各種文件的彩信傳輸,有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶體驗。 以上所述僅為本發(fā)明的較佳實施例而已,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內(nèi),所作的任何修改、等同替換、改進等,均應包含在本發(fā)明的保護范圍之內(nèi)。
10
權利要求
一種彩信的傳輸方法,其特征在于,包括判斷待發(fā)送的彩信的大小是否超過預定值;在判斷所述彩信的大小超過所述預定值的情況下,對所述彩信進行分解,得到多個子彩信,其中,所述多個子彩信中每個子彩信的大小均小于或等于所述預定值;將所述每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并將加入分解規(guī)則信息后的所述多個子彩信發(fā)送至接收方,其中,所述分解規(guī)則信息用于拼接所述多個子彩信。
2. 根據(jù)權利要求1所述的傳輸方法,其特征在于,判斷待發(fā)送的所述彩信的大小是否 超過所述預定值具體包括在判斷所述彩信中插入的打包后的一個或多個多媒體文件的總大小超過所述預定值 的情況下,判斷所述彩信的大小超過所述預定值。
3. 根據(jù)權利要求2所述的傳輸方法,其特征在于,對所述彩信進行分解得到所述多個子彩信具體包括對打包后的所述一個或多個多媒體文件作為整體進行分解,得到多個多媒體子文件; 對于所述多個多媒體子文件中的每個多媒體子文件,將所述多媒體子文件進行打包得 到一個子彩信;并且,所述每個子彩信的大小均小于所述預定值是指每個多媒體子文件的大小均小 于所述預定值。
4. 根據(jù)權利要求3所述的傳輸方法,其特征在于,進一步包括所述接收方接收發(fā)送的所述多個子彩信,并在所述多個子彩信接收完畢之后根據(jù)所述 多個子彩信的分解規(guī)則信息對所述多個子彩信進行拼接。
5. 根據(jù)權利要求4所述的傳輸方法,其特征在于,根據(jù)所述多個子彩信的分解規(guī)則信 息對所述多個子彩信進行拼接具體包括對所述多個子彩信的打包后的多媒體子文件進行解碼,并對解碼后的所述多個多媒體 子文件進行拼接,得到打包后的所述多媒體文件。
6. 根據(jù)權利要求1至5中任一項所述的傳輸方法,其特征在于,所述每個子彩信所對應 的分解規(guī)則信息包括該子彩信所屬的所述彩信的標識、對所述彩信進行分解時該子彩信 在所述多個子彩信中的排序和所述多個子彩信的總數(shù)。
7. 根據(jù)權利要求1至5中任一項所述的傳輸方法,其特征在于,對于所述每個子彩信, 其對應的分解規(guī)則信息被加入在該子彩信的文本部分。
8. 根據(jù)權利要求1至5中任一項所述的傳輸方法,其特征在于,對所述彩信進行分解包括將所述彩信平均分解為大小相等多個的子彩信、或者以所述預定值為單位對所述彩信 進行分解。
9. 一種終端,其特征在于,包括判斷模塊,用于判斷待發(fā)送的彩信的大小是否超過預定值;分解模塊,用于在所述判斷模塊的判斷結果為是的情況下,對所述彩信進行分解,得到 多個子彩信,其中,所述多個子彩信中每個子彩信的大小均小于或等于所述預定值;發(fā)送模塊,用于將所述每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并 將加入分解規(guī)則信息后的所述多個子彩信發(fā)送至接收方,其中,所述分解規(guī)則信息用于拼接所述多個子彩信。
10. —種終端,其特征在于,包括 接收模塊,用于接收彩信;拼接模塊,用于所述接收模塊接收到屬于彩信的全部子彩信之后根據(jù)接收的每個子彩 信的分解規(guī)則信息對所述子彩信進行拼接。
11. 一種彩信的傳輸系統(tǒng),其特征在于,包括發(fā)送方終端和接收方終端,其中, 所述發(fā)送方終端,包括判斷模塊,用于判斷待發(fā)送的彩信的大小是否超過預定值;分解模塊,用于在所述判斷模塊的判斷結果為是的情況下,對所述彩信進行分解,得到 多個子彩信,其中,所述多個子彩信中每個子彩信的大小均小于或等于所述預定值;發(fā)送模塊,用于將所述每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并 將加入分解規(guī)則信息后的所述多個子彩信經(jīng)由網(wǎng)絡發(fā)送至所述接收方終端,其中,所述分 解規(guī)則信息用于拼接所述多個子彩信;所述接收方終端包括接收模塊,用于接收彩信;拼接模塊,用于所述接收模塊接收到屬于所述彩信的全部子彩信之后根據(jù)接收的每個 子彩信的分解規(guī)則信息對所述多個子彩信進行拼接。
全文摘要
本發(fā)明公開了一種彩信的傳輸方法、系統(tǒng)、以及終端,該方法包括判斷待發(fā)送的彩信的大小是否超過預定值;在判斷彩信的大小超過預定值的情況下,對彩信進行分解,得到多個子彩信,其中,多個子彩信中每個子彩信的大小均小于或等于預定值;將每個子彩信所對應的分解規(guī)則信息加入到相應的子彩信中,并將加入分解規(guī)則信息后的多個子彩信發(fā)送至接收方,其中,分解規(guī)則信息用于拼接多個子彩信。借助于本發(fā)明,能夠避免傳輸大容量圖像文件時對文件進行壓縮,并且能夠實現(xiàn)大容量視頻文件、大容量音頻文件、以及大容量應用程序等各種文件的彩信傳輸,有效提高了彩信業(yè)務的性能,方便用戶使用彩信業(yè)務,提高了用戶體驗。
文檔編號H04W88/02GK101711015SQ20091026568
公開日2010年5月19日 申請日期2009年12月30日 優(yōu)先權日2009年12月30日
發(fā)明者趙文彬 申請人:中興通訊股份有限公司