本申請涉及多媒體處理技術領域,更具體地說,涉及一種流媒體文件處理方法及裝置。
背景技術:
隨著智能手機等移動終端的普及,越來越多的用戶習慣于通過移動終端來觀看網絡上的多媒體文件,例如在智能手機上觀看視頻網站提供的視頻等。用戶通過移動終端觀看多媒體文件都是基于流媒體協議實現的,所謂流媒體是指采用流式傳輸的方式實現在線播放的媒體格式,通過流媒體協議能夠實現邊下載邊播放的功能。
目前比較常見的流媒體協議主要有HLS協議(HTTP Live Streaming,HTTP流媒體協議)、RTSP協議(Real Time Streaming Protocol,實時傳輸流協議)、RTP協議(Real-time Transport Protocol,實時傳輸協議)、MMS協議(Microsoft Media Server Protocol,微軟媒體服務器協議)等。現有的移動終端上的多媒體播放器大多都支持HLS協議和RTSP/RTP協議,但是卻不支持MMS協議。因此,用戶無法在移動終端上下載或觀看MMS協議的多媒體文件。
技術實現要素:
有鑒于此,本申請提供了一種流媒體文件處理方法及裝置,用于解決現有移動終端上的多媒體播放器不支持MMS協議,造成用戶無法下載或觀看MMS協議的多媒體文件的問題。
為了實現上述目的,現提出的方案如下:
一種流媒體文件處理方法,應用于移動終端,該方法包括:
響應目標流媒體文件下載請求,獲取目標流媒體文件的統一資源定位符URL;
根據所述URL頭部的模式信息,判斷所述目標流媒體文件是否為MMS協議的流媒體文件;
若是,參考預置的模式信息與網絡通信協議間的對應關系,將與所述URL頭部的模式信息相對應的網絡通信協議確定為目標網絡通信協議;
利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
一種流媒體文件處理裝置,應用于移動終端,該裝置包括:
URL獲取單元,用于響應目標流媒體文件下載請求,獲取目標流媒體文件的統一資源定位符URL;
文件判斷單元,用于根據所述URL頭部的模式信息,判斷所述目標流媒體文件是否為MMS協議的流媒體文件;
通信協議確定單元,用于在所述文件判斷單元判斷結果為是時,參考預置的模式信息與網絡通信協議間的對應關系,將與所述URL頭部的模式信息相對應的網絡通信協議確定為目標網絡通信協議;
文件數據拉取單元,用于利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
從上述的技術方案可以看出,本申請實施例提供的流媒體文件處理方法,應用于移動終端,在響應目標流媒體文件下載請求時,獲取目標流媒體文件的URL,并根據URL頭部的模式信息,判斷目標流媒體文件是否為MMS協議的流媒體文件,如果是,則參考預置的模式信息與網絡通信協議間的對應關系,確定與URL的模式信息對應的目標網絡通信協議,進而利用目標網絡通信協議從URL的域名地址指定的服務器中拉取目標流媒體文件數據。本申請通過流媒體文件的URL確定其是否為MMS協議的文件,在確定是的情況下,進一步參考預置的URL模式信息與網絡通信協議間對應關系,確定與目標流媒體文件的URL模式信息對應的網絡通信協議,進而可以按照該協議去拉取目標流媒體文件數據,在移動終端上實現了對MMS協議的流媒體文件的下載,方便了用戶的使用。
附圖說明
為了更清楚地說明本申請實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本申請的實施例,對于本領域普通技術人員來講,在不付出創造性勞動的前提下,還可以根據提供的附圖獲得其他的附圖。
圖1為本申請實施例公開的一種流媒體文件處理方法流程圖;
圖2為本申請實施例公開的另一種流媒體文件處理方法流程圖;
圖3為本申請實施例公開的又一種流媒體文件處理方法流程圖;
圖4為本申請實施例公開的又一種流媒體文件處理方法流程圖;
圖5為本申請實施例公開的又一種流媒體文件處理方法流程圖;
圖6為本申請實施例公開的一種流媒體文件處理裝置結構示意圖;
圖7為本申請實施例公開的一種移動終端硬件結構示意圖。
具體實施方式
下面將結合本申請實施例中的附圖,對本申請實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本申請一部分實施例,而不是全部的實施例。基于本申請中的實施例,本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例,都屬于本申請保護的范圍。
本案發明人通過對現有移動終端上的多媒體播放器的研究,發現其不支持MMS協議的多媒體文件的播放,也即當用戶想要在移動終端上觀看某個MMS協議的多媒體文件時,現有移動終端上的播放器將出錯,無法下載并播放MMS協議的多媒體文件。為此,本申請實施例提供了一種應用于移動終端的流媒體文件處理方法及流媒體文件處理裝置,以解決上述問題。參見圖1,圖1為本申請實施例公開的一種流媒體文件處理方法流程圖。
如圖1所示,該方法包括:
步驟S100、響應目標流媒體文件下載請求,獲取目標流媒體文件的URL;
本申請的方法可以是應用于移動終端的瀏覽器中,也可以是應用于移動終端的多媒體播放器中。以移動終端為手機進行說明,用戶在手機瀏覽器中點擊某個目標流媒體文件時,即可觸發目標流媒體文件下載請求,由本申請 的流媒體文件處理裝置獲取目標流媒體文件的URL(Uniform Resource Locator,統一資源定位符)。
對于URL,互聯網上的每個文件都有一個唯一的URL,它包含的信息指出文件的位置以及瀏覽器應該怎么處理它。URL由模式(或稱協議)部分和域名地址部分組成。模式部分位于頭部,模式信息與域名地址信息之間一般通過“://”間隔,例如常見的百度URL為://www.baidu.com/,其中https為模式信息,www.baidu.com/為域名地址信息。
步驟S110、根據所述URL頭部的模式信息,判斷所述目標流媒體文件是否為MMS協議的流媒體文件,若是,執行步驟S120;
具體地,URL頭部的模式信息為流媒體文件供應商側的服務器所決定,服務器規定了該流媒體文件的流媒體協議,以及該流媒體協議所支持的網絡通信協議。因此,本步驟中可以通過URL頭部的模式信息來判斷目標流媒體文件是否為MMS協議的流媒體文件。如果是移動終端所原本支持的其他類型協議,而非MMS協議,則按照現有流程處理。
步驟S120、參考預置的模式信息與網絡通信協議間的對應關系,將與所述URL頭部的模式信息相對應的網絡通信協議確定為目標網絡通信協議;
MMS協議的流媒體文件所在的服務器規定了該文件所支持的網絡通信協議,移動終端只有以規定的網絡通信協議才能夠從服務器中獲取該文件。而不同的MMS協議的流媒體所支持的網絡通信協議也不盡相同,例如某些MMS協議的流媒體文件支持HTTP網絡通信協議,某些支持TCP網絡通信協議等。為此,可以在流媒體文件URL的模式信息中添加標識,標識出該流媒體文件所支持的網絡通信協議。
本申請預置了模式信息與網絡通信協議間的對應關系,在確定目標流媒體文件為MMS協議的流媒體文件時,查詢與目標流媒體文件的模式信息對應的網絡通信協議,確定為目標網絡通信協議。
步驟S130、利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
具體地,目標流媒體文件URL的域名地址指定了該文件所在的服務器。利用上一步驟確定的目標網絡通信協議,從URL域名地址所指定的服務器中獲取目標流媒體文件數據。
本申請實施例提供的流媒體文件處理方法,應用于移動終端,在響應目標流媒體文件下載請求時,獲取目標流媒體文件的URL,并根據URL頭部的模式信息,判斷目標流媒體文件是否為MMS協議的流媒體文件,如果是,則參考預置的模式信息與網絡通信協議間的對應關系,確定與URL的模式信息對應的目標網絡通信協議,進而利用目標網絡通信協議從URL的域名地址指定的服務器中拉取目標流媒體文件數據。本申請通過流媒體文件的URL確定其是否為MMS協議的文件,在確定是的情況下,進一步參考預置的URL模式信息與網絡通信協議間對應關系,確定與目標流媒體文件的URL模式信息對應的網絡通信協議,進而可以按照該協議去拉取目標流媒體文件數據,在移動終端上實現了對MMS協議的流媒體文件的下載,方便了用戶的使用。
參見圖2,圖2為本申請實施例公開的另一種流媒體文件處理方法流程圖。
如圖2所示,該方法包括:
步驟S200、響應目標流媒體文件下載請求,獲取目標流媒體文件的URL;
步驟S210、解析所述URL,得到表征所述URL頭部的模式信息的字符串;
通過解析URL,可以得到表征URL模式信息的字符串。一般性的,URL由若干個字符串及符號組成,本實施例中可以以“://”作為標識,將“://”前面的字符串提取出來,作為表征URL模式信息的字符串。
步驟S220、判斷所述字符串是否以MMS開頭,若是,則執行步驟S230,若否,則執行步驟S240;
步驟S230、確定所述目標流媒體文件是MMS協議的流媒體文件,進一步執行步驟S250;
步驟S240、確定所述目標流媒體文件不是MMS協議的流媒體文件;
具體地,可以規定MMS協議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣,如果發現目標流媒體文件的模式信息以“MMS”這幾個字符開頭,則確定其為MMS協議的流媒體文件。
步驟S250、參考預置的模式信息與網絡通信協議間的對應關系,將與所述URL頭部的模式信息相對應的網絡通信協議確定為目標網絡通信協議;
本申請預置了模式信息與網絡通信協議間的對應關系,在確定目標流媒體文件為MMS協議的流媒體文件時,查詢與目標流媒體文件的模式信息對應的網絡通信協議,確定為目標網絡通信協議。
步驟S260、利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
相比于上一實施例,本實施例中公開了一種依據URL模式信息判斷文件是否為MMS協議的可實施方案。具體地,通過對URL進行解析,得到表征模式信息的字符串,若確定字符串以MMS開頭,則確定其為MMS協議的流媒體文件。
在本申請的又一個實施例中,公開了又一種流媒體文件處理方法,參見圖3,圖3為本申請實施例公開的又一種流媒體文件處理方法流程圖。
如圖3所示,該方法包括:
步驟S300、響應目標流媒體文件下載請求,獲取目標流媒體文件的URL;
步驟S310、解析所述URL,得到表征所述URL頭部的模式信息的字符串;
通過解析URL,可以得到表征URL模式信息的字符串。一般性的,URL由若干個字符串及符號組成,本實施例中可以以“://”作為標識,將“://”前面的字符串提取出來,作為表征URL模式信息的字符串。
步驟S320、判斷所述字符串是否以MMS開頭,若是,則執行步驟S330,若否,則執行步驟S340;
步驟S330、確定所述目標流媒體文件是MMS協議的流媒體文件,進一步執行步驟S350;
步驟S340、確定所述目標流媒體文件不是MMS協議的流媒體文件;
具體地,可以規定MMS協議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣,如果發現目標流媒體文件的模式信息以“MMS”這幾個字符開頭,則確定其為MMS協議的流媒體文件。
步驟S350、判斷所述字符串是否為MMSU、MMST、MMSH中的某一個,若是,執行步驟S360;
步驟S360、將與所述字符串對應的網絡通信協議確定為目標網絡通信協議;
其中與MMSU對應的網絡通信協議為UDP協議(User Datagram Protocol,用戶數據報協議)、與MMST對應的網絡通信協議為TCP協議(Transmission Control Protocol,傳輸控制協議)、與MMSH對應的網絡通信協議為HTTP協議(Hyper Text Transfer Protocol,超文本傳送協議)。
步驟S370、利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
在本實施例中,規定了與MMSU對應的網絡通信協議為用戶數據報協議UDP協議、與MMST對應的網絡通信協議為傳輸控制協議TCP協議、與MMSH對應的網絡通信協議為超文本傳送協議HTTP協議。因此,如果一個流媒體文件的URL的模式信息為MMSU,則代表該流媒體文件支持UDP網絡通信協議,如果一個流媒體文件的URL的模式信息為MMST,則代表該流媒體文件支持TCP網絡通信協議,以此類推。
當然,上述UDP、TCP和HTTP三種網絡通信協議為現有比較成熟的通信協議,一般MMS協議的流媒體文件也僅僅是從上述三種網絡通信協議中選擇一種支持。因此,本實施例中僅規定了與上述三種通信協議對應的模式信息:MMSU、MMST和MMSH。如果后續出現支持其它網絡通信協議的MMS流媒體文件,則可以設置對應的模式信息,本實施例不再贅述。
在本申請的又一個實施例中,進一步介紹了又一種流媒體文件處理方法,參見圖4,圖4為本申請實施例公開的又一種流媒體文件處理方法流程圖。
如圖4所示,該方法包括:
步驟S400、響應目標流媒體文件下載請求,獲取目標流媒體文件的URL;
步驟S410、解析所述URL,得到表征所述URL頭部的模式信息的字符串;
通過解析URL,可以得到表征URL模式信息的字符串。一般性的,URL由若干個字符串及符號組成,本實施例中可以以“://”作為標識,將“://”前面的字符串提取出來,作為表征URL模式信息的字符串。
步驟S420、判斷所述字符串是否以MMS開頭,若是,則執行步驟S430,若否,則執行步驟S440;
步驟S430、確定所述目標流媒體文件是MMS協議的流媒體文件,進一步執行步驟S450;
步驟S440、確定所述目標流媒體文件不是MMS協議的流媒體文件;
具體地,可以規定MMS協議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣,如果發現目標流媒體文件的模式信息以“MMS”這幾個字符開頭,則確定其為MMS協議的流媒體文件。
步驟S450、判斷所述字符串是否為MMSU、MMST、MMSH中的某一個,若是,執行步驟S460,若否,執行步驟S480;
步驟S460、將與所述字符串對應的網絡通信協議確定為目標網絡通信協議;
其中與MMSU對應的網絡通信協議為UDP協議(User Datagram Protocol,用戶數據報協議)、與MMST對應的網絡通信協議為TCP協議(Transmission Control Protocol,傳輸控制協議)、與MMSH對應的網絡通信協議為HTTP協議(Hyper Text Transfer Protocol,超文本傳送協議)。
步驟S470、利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據;
步驟S480、依次將所述UDP協議、所述TCP協議和所述HTTP協議作為目標網絡通信協議;
步驟S490、依次嘗試各目標網絡通信協議,直至成功拉取目標流媒體文件數據。
具體地,依次利用各所述目標網絡通信協議嘗試從所述URL的域名地址部分所指定的服務器中拉取目標流媒體文件數據,直至成功拉取目標流媒體文件數據。
需要說明的是,某些情況下在制定MMS協議的流媒體文件的URL時,可能由于疏忽等問題,未在模式部分進行標記,而直接以MMS作為URL的模式信息。對于這種情況,本實施例中按照UDP協議、TCP協議、HTTP協議的順序逐個嘗試,直至成功拉取文件數據。
在本申請的又一個實施例中,進一步介紹了又一種流媒體文件處理方法,參見圖5,圖5為本申請實施例公開的又一種流媒體文件處理方法流程圖。
如圖5所示,該方法包括:
步驟S500、響應目標流媒體文件下載請求,獲取目標流媒體文件的URL;
步驟S510、解析所述URL,得到表征所述URL頭部的模式信息的字符串;
通過解析URL,可以得到表征URL模式信息的字符串。一般性的,URL由若干個字符串及符號組成,本實施例中可以以“://”作為標識,將“://”前面的字符串提取出來,作為表征URL模式信息的字符串。
步驟S520、判斷所述字符串是否以MMS開頭,若是,則執行步驟S530,若否,則執行步驟S540;
步驟S530、確定所述目標流媒體文件是MMS協議的流媒體文件,進一步執行步驟S550;
步驟S540、確定所述目標流媒體文件不是MMS協議的流媒體文件;
具體地,可以規定MMS協議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣,如果發現目標流媒體文件的模式信息以“MMS”這幾個字符開頭,則確定其為MMS協議的流媒體文件。
步驟S550、判斷所述字符串是否以MMSU開頭,若是,執行步驟S560,若否,執行步驟S570;
步驟S560、將與所述MMSU對應的用戶數據報協議UDP協議確定為目標網絡通信協議,順序執行步驟S650;
步驟S570、判斷所述字符串是否以MMST開頭,若是,執行步驟S580,若否,執行步驟S590;
步驟S580、將與所述MMST對應的傳輸控制協議TCP協議確定為目標網絡通信協議,順序執行步驟S650;
步驟S590、判斷所述字符串是否以MMSH開頭,若是,執行步驟S600,若否,執行步驟S610;
步驟S600、將與所述MMSH對應的超文本傳送協議HTTP協議確定為目標網絡通信協議,順序執行步驟S650;
步驟S610、嘗試利用UDP協議拉取目標流媒體文件數據,判斷是否成功,若是,結束,若否,執行步驟S620;
具體地,嘗試利用UDP協議從URL的域名地址部分所指定的服務器中拉取目標流媒體文件數據。
步驟S620、嘗試利用TCP協議拉取目標流媒體文件數據,判斷是否成功,若是,結束,若否,執行步驟S630;
具體地,嘗試利用TCP協議從URL的域名地址部分所指定的服務器中拉取目標流媒體文件數據。
步驟S630、嘗試利用HTTP協議拉取目標流媒體文件數據,判斷是否成功,若是,結束,若否,執行步驟S640;
具體地,嘗試利用HTTP協議從URL的域名地址部分所指定的服務器中拉取目標流媒體文件數據。
步驟S640、嘗試失敗,報錯;
步驟S650、利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
本實施例中介紹了一種依據模式信息確定網絡通信協議,在無法確定時,按照一定順序逐個嘗試下載文件的過程。其中,步驟S550、S570和S590的執行順序可以顛倒或者同時執行。同理,步驟S610-S630的執行順序可以顛倒或者同時執行。
進一步可選的,在上述各個實施例的基礎上,本申請在拉取目標流媒體文件數據之后,可以進一步創建并初始化解碼器,然后對解碼器解碼后的目標流媒體文件數據進行播放。
下面對本申請實施例提供的流媒體文件處理裝置進行描述,下文描述的流媒體文件處理裝置與上文描述的流媒體文件處理方法可相互對應參照。
參見圖6,圖6為本申請實施例公開的一種流媒體文件處理裝置結構示意圖。
如圖7所示,該裝置包括:
URL獲取單元61,用于響應目標流媒體文件下載請求,獲取目標流媒體文件的統一資源定位符URL;
文件判斷單元62,用于根據所述URL頭部的模式信息,判斷所述目標流媒體文件是否為MMS協議的流媒體文件;
通信協議確定單元63,用于在所述文件判斷單元62判斷結果為是時,參考預置的模式信息與網絡通信協議間的對應關系,將與所述URL頭部的模式信息相對應的網絡通信協議確定為目標網絡通信協議;
文件數據拉取單元64,用于利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
本申請實施例提供的流媒體文件處理裝置,由文件判斷單元通過流媒體文件的URL判斷其是否為MMS協議的文件,在確定是的情況下,由通信協議確定單元參考預置的URL模式信息與網絡通信協議間對應關系,確定與目標流媒體文件的URL模式信息對應的網絡通信協議,進而由文件數據拉取單元按照該協議去拉取目標流媒體文件數據。使用本申請的流媒體文件處理裝置,在移動終端上實現了對MMS協議的流媒體文件的下載,方便了用戶的使用。
可選的,本申請實施例提供了上述文件判斷單元的一種可選結構,文件判斷單元可以包括:
URL解析單元,用于解析所述URL,得到表征所述URL頭部的模式信息的字符串;
字符串判斷單元,用于判斷所述字符串是否以MMS開頭,若是,則確定所述目標流媒體文件是MMS協議的流媒體文件,若否,則確定所述目標流媒體文件不是MMS協議的流媒體文件。
可選的,本申請實施例提供了上述通信協議確定單元的一種可選結構,通信協議確定單元可以包括:
第一通信協議確定子單元,用于判斷所述字符串是否為MMSU、MMST、MMSH中的某一個;
第二通信協議確定子單元,用于在所述第一通信協議確定子單元判斷結果為是時,將與所述字符串對應的網絡通信協議確定為目標網絡通信協議,其中與MMSU對應的網絡通信協議為用戶數據報協議UDP協議、與MMST對應的網絡通信協議為傳輸控制協議TCP協議、與MMSH對應的網絡通信協議為超文本傳送協議HTTP協議。
可選的,本實施例提供了流媒體文件處理裝置的另一種可選結構,該裝置還可以進一步包括:
第三通信協議確定子單元,用于在所述第一通信協議確定子單元判斷結果為否時,依次將所述UDP協議、所述TCP協議和所述HTTP協議作為目標網絡通信協議;
所述文件數據拉取單元具體用于,依次利用各所述目標網絡通信協議嘗試從所述URL的域名地址部分所指定的服務器中拉取目標流媒體文件數據,直至成功拉取目標流媒體文件數據。
可選的,本實施例提供了流媒體文件處理裝置的又一種可選結構,該裝置還可以進一步包括:
解碼器創建單元,用于利用拉取的目標流媒體文件數據,創建并初始化解碼器;
媒體播放單元,用于對所述解碼器解碼后的目標流媒體文件數據進行播放。
本申請實施例還提供一種移動終端,包括上述所述的流媒體文件處理裝置。對于流媒體文件處理裝置的描述可參照上文對應部分描述,此處不再贅述。
對于移動終端的硬件結構,參見圖7,圖7為本申請實施例提供的移動終端的硬件結構示意圖。如圖7所示,該移動終端可以包括:
處理器1,通信接口2,存儲器3,通信總線4,和顯示屏5;
其中處理器1、通信接口2、存儲器3和顯示屏5通過通信總線4完成相互間的通信;
可選的,通信接口2可以為通信模塊的接口,如GSM模塊的接口;
處理器1,用于執行程序;
存儲器3,用于存放程序;
程序可以包括程序代碼,所述程序代碼包括處理器的操作指令。
處理器1可能是一個中央處理器CPU,或者是特定集成電路ASIC(Application Specific Integrated Circuit),或者是被配置成實施本申請實施例的一個或多個集成電路。
存儲器3可能包含高速RAM存儲器,也可能還包括非易失性存儲器(non-volatile memory),例如至少一個磁盤存儲器。
其中,程序可具體用于:
響應目標流媒體文件下載請求,獲取目標流媒體文件的統一資源定位符URL;
根據所述URL頭部的模式信息,判斷所述目標流媒體文件是否為MMS協議的流媒體文件;
若是,參考預置的模式信息與網絡通信協議間的對應關系,將與所述URL頭部的模式信息相對應的網絡通信協議確定為目標網絡通信協議;
利用所述目標網絡通信協議,從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數據。
最后,還需要說明的是,在本文中,諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來,而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且,術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含,從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素,而且還包括沒有明確列出的其他要素,或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下,由語句“包括一個……”限定的要素,并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。
本說明書中各個實施例采用遞進的方式描述,每個實施例重點說明的都是與其他實施例的不同之處,各個實施例之間相同相似部分互相參見即可。
對所公開的實施例的上述說明,使本領域專業技術人員能夠實現或使用本申請。對這些實施例的多種修改對本領域的專業技術人員來說將是顯而易見的,本文中所定義的一般原理可以在不脫離本申請的精神或范圍的情況下, 在其它實施例中實現。因此,本申請將不會被限制于本文所示的這些實施例,而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。