專利名稱：txt文件的解碼方法與其裝置及包括該裝置的電子產(chǎn)品的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種解碼方法及其裝置，尤其是一種txt文件的解碼方法及其裝置。
背景技術(shù)：
當(dāng)前用戶對于txt文件解碼要求越來越高，尤其是中低端便攜電子產(chǎn)品由于內(nèi)存 大小等限制往往對操作的txt文件有文件容量限制。 —方面，超過便攜電子產(chǎn)品硬件的限制則無法對txt文件進(jìn)行解碼，需要用戶自 行切割成多個文件才能分別進(jìn)行解碼，這給用戶的使用造成了不便；另一方面，在當(dāng)前信息 量激增的背景下，txt文件的容量越來越大，包含的信息量越來越多，對于這類大容量文件 的解碼要求越來越迫切。因此，傳統(tǒng)的txt文件解碼方法及其解碼裝置已無法滿足當(dāng)前及 今后用戶的基本要求。 另外，不同的系統(tǒng)生成的txt文件也會有差別。當(dāng)前主要以Windows系統(tǒng)、蘋果
Mac系統(tǒng)以及Li皿x系統(tǒng)為主，其生成的文本字符存儲規(guī)則均不相同，這就造成了 txt文件
在不同系統(tǒng)平臺間移植時不能充分識別并解碼的問題。 總的來說，現(xiàn)有txt文件解碼主要存在以下一些問題 1、對目標(biāo)文件的大小存在限制，或?qū)Υ笕萘课募拇蜷_較慢等問題。 2、對各種編碼及不同平臺文本文件格式的不完全解析。 因此，需要一種新的txt文件的解碼方法及其裝置以更好的解決便攜電子產(chǎn)品 txt文件的解碼中存在的上述問題。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明致力于更好的解決便攜電子產(chǎn)品txt文件的解碼中存在的上述
問題，提出了一種txt文件的解碼方法及其裝置及包括該裝置的電子產(chǎn)品。 根據(jù)本發(fā)明的第一方面，提供了一種txt文件的解碼方法。該方法還包括如下步
驟 步驟a :依據(jù)設(shè)定的宏值，對txt文件虛擬劃分為若干個文件塊； 步驟b :按照需要解碼的順序，依次載入文件塊并對所述文件塊的內(nèi)容進(jìn)行解碼。 上述方法在步驟b之后還包括步驟C : 對解碼后的文件塊進(jìn)行分頁處理，并對其頁表信息進(jìn)行保存。 上述步驟C中對解碼后的文件塊進(jìn)行分頁處理前還包括如下步驟 步驟cl :取出解碼后的文件塊，并將文件塊的內(nèi)容轉(zhuǎn)化為Unicode字符； 步驟c2 :在文件塊的Unicode字符中檢測到CR或LF時，均進(jìn)行分行處理。 上述txt文件的編碼類型包括以下幾種中的一種或多種 GB2312/GBK、 unicode、 uincode-BE、 utf-8。 上述文件塊采用線程方式進(jìn)行處理，并在其完成解碼和/或分頁并保存后結(jié)束線 程。
根據(jù)本發(fā)明的第二方面，提供了一種txt文件的解碼裝置。該解碼裝置包括
文件塊處理模塊依據(jù)設(shè)定的宏值，將txt文件虛擬劃分為若干個文件塊；
內(nèi)容解析模塊按照需要解碼的順序，依次載入文件塊處理模塊輸出的文件塊并 對文件塊的內(nèi)容進(jìn)行解碼。 上述解碼裝置還包括內(nèi)容分頁模塊對內(nèi)容解析模塊解碼后的文件塊進(jìn)行分頁處
理并對其頁表信息進(jìn)行保存。
上述內(nèi)容分頁模塊還包括如下處理 取出解碼后的文件塊，并將文件塊的內(nèi)容轉(zhuǎn)化為Unicode字符； 在文件塊的Unicode字符中檢測到CR或LF時，均進(jìn)行分行處理。 根據(jù)本發(fā)明的第三方面，還提供了一種電子產(chǎn)品。該電子產(chǎn)品包括本發(fā)明第二方
面所述的各解碼裝置。 上述電子產(chǎn)品為手機(jī)、電子詞典、PDA、MP3和MP4。
本發(fā)明的有益效果是 本發(fā)明針對已經(jīng)存在的txt文件的解碼，進(jìn)一步解決了文本文件的大小限制，同 時對目標(biāo)文件進(jìn)行了自適應(yīng)編碼解析，不增加任何硬件成本。


下面將參照附圖對本發(fā)明的具體實施方案進(jìn)行更詳細(xì)的說明，其中 圖1是本發(fā)明的文件塊整體處理流程圖； 圖2是本發(fā)明的自適應(yīng)解碼流程圖； 圖3是本發(fā)明的文字排版流程圖； 圖4是本發(fā)明的顯示位置移動示意圖； 圖5是本發(fā)明的顯示位置移動流程圖； 圖6是本發(fā)明解碼裝置的第一實施例結(jié)構(gòu)圖；以及 圖7是本發(fā)明解碼裝置的第二實施例結(jié)構(gòu)圖。
具體實施例方式
為了解決txt文件的解碼中的容量及解碼速度的問題，本發(fā)明提供了一種txt文
件的解碼方法及其裝置及包括該裝置的電子產(chǎn)品。 首先來說明一下本發(fā)明的技術(shù)術(shù)語。 文件塊將文件分成設(shè)定大小的片段進(jìn)行分析的文件片段，也就是只進(jìn)行虛擬分 塊，并不改變原文件的大小和結(jié)構(gòu)。 虛擬分頁每次按設(shè)定的可以顯示的最大行數(shù)進(jìn)行分頁，并保存相應(yīng)的頁信息，與 實際顯示的頁不一定相同。 Cache :每次讀取文件片段后將該片段內(nèi)的頁表信息存儲于事先分配好的空間中， 這段程序生命周期始終作為快速讀寫的存儲區(qū)定義為Cache。 接下來，結(jié)合各附圖分多個小部具體說明txt文件的解碼方法及其裝置，其中，具 體的函數(shù)以及操作均以偽碼表示。 圖1示出本發(fā)明的文件塊整體處理流程圖，如圖1所示，步驟100開始，讀取文件
4大小信息開始，file_size = Getf ilesize ()。 步驟102中，根據(jù)定義的宏值Fragment—size，分析計算文件塊的數(shù)量，F(xiàn)rags = f ile_size/Fragment_size+l。 步驟104中，創(chuàng)建線程Creat_thread，并初始化線程Init_thread，以開始分析文 件塊的內(nèi)容Thread_start。 步驟106中，從預(yù)設(shè)偏移量開始讀取一個文件塊，start—position為定義的偏移 量參數(shù)，貝U Read—block (start—position)。 步驟108中，分析該文件塊內(nèi)容，即對文本內(nèi)容進(jìn)行解碼；然后進(jìn)行分頁，由分頁 處理函數(shù)Block_pagescale ()進(jìn)行處理，并記憶頁表信息到全局變量，即由Block-offset_ recite ()進(jìn)行保存。其中，頁表信息包括頁始偏移量和頁長度。并由Finish_ pagingscale()函數(shù)最終完成分頁。 步驟110中，文件塊分析完畢后，并且頁表信息也已準(zhǔn)備好，發(fā)事件通知上層準(zhǔn)備 顯不，SendEvent ()。 步驟112中，完成該文件塊操作后釋放線程，即Release—thread ()。
由上可知本發(fā)明txt文件的解碼方法基本包括如下步驟 步驟a:依據(jù)設(shè)定的宏值(其大小可以為IK-IM，主要根據(jù)硬件的情況而定)，對 txt文件虛擬劃分為若干個文件塊。 步驟b :按照需要解碼的順序，依次載入文件塊并對所述文件塊的內(nèi)容進(jìn)行解碼。
針對硬件對文件大小有相應(yīng)限制的情況，同時又達(dá)到解碼速度需要與文件容量無 關(guān)，故根據(jù)使用平臺的不同，可以定義每次讀取文件塊的宏值。不同便攜電子產(chǎn)品可以根據(jù) 自身的軟硬件配置，設(shè)置宏值的大小。 每次讀取時針對不同平臺的特點，可以使用線程進(jìn)行操作，避免使用較長時間的 循環(huán)導(dǎo)致底層其他任務(wù)超時引起的異常。 每次解析相應(yīng)文本片段的內(nèi)容，需要將該段內(nèi)容進(jìn)行虛擬分頁處理，并將每塊的 起始絕對位置存儲于cache中，以便每次讀取時無需再次重新解析，并最小化對便攜電子 產(chǎn)品的cache容量大小需求。 圖2示出本發(fā)明的自適應(yīng)解碼流程圖，如圖2所示，步驟200開始，讀取文件塊內(nèi) 容，并把讀到的內(nèi)容返回給指針。定義指針Pcontent，使Pcontent = Read_block(start_ position)。 步驟202中，從文件塊始偏移量開始讀取文件塊內(nèi)容，以進(jìn)行解碼。
步驟204中，判斷編碼格式并根據(jù)編碼格式進(jìn)行解碼，即判斷編碼格式函數(shù)進(jìn) 行判斷Ntype = Get_codingtype(Pcontent)，然后由解碼函數(shù)進(jìn)行解碼Ret = Coding— convention (Ntype， Pcontent)，也即進(jìn)行轉(zhuǎn)碼轉(zhuǎn)換成統(tǒng)一的碼型，本發(fā)明采用Unicode碼。
步驟206中，進(jìn)一步對轉(zhuǎn)換后的碼進(jìn)行字節(jié)判斷，即Charsjudgement (Ret)，如果 在字節(jié)判斷中遇到斷碼，則進(jìn)入步驟208中，返回錯誤信息error ;如果在字節(jié)判斷中沒有 遇到斷碼，則進(jìn)入步驟212中，返回success信息，說明整段解析成功，繼續(xù)分頁處理。
在步驟208之后，進(jìn)入步驟210，從解析處向后向前偏移一個字節(jié)進(jìn)行二次解析， 也即Pcontent指針自動加1或減1，然后返回步驟204中，重新進(jìn)行解析，并執(zhí)行后續(xù)步驟。
針對文本文件編碼方式的不同，需要對每一片段進(jìn)行解碼時需要進(jìn)行碼轉(zhuǎn)換過
5程，由于國內(nèi)常用的編碼方式有GB2312/GBK， unicode， uincode-BE， utf-8等，針對含有非 ASCII字符的編碼格式各有不同。 由于采用Unicode, unicode-BE及utf_8編碼方式的文件在文件頭部(即文件最 開始的幾個字節(jié))有相應(yīng)的標(biāo)志位，所以可以根據(jù)文件頭讀取的相應(yīng)內(nèi)容進(jìn)行編碼格式的 判斷，然后根據(jù)需要進(jìn)行相應(yīng)的轉(zhuǎn)化。 然而對于以GB2312/GBK編碼方式保存的文本文件沒有對應(yīng)的文件頭標(biāo)志位，所 以對于讀取內(nèi)容的解析需要加以碼值的控制和判斷。尤其是對于可以任意跳轉(zhuǎn)的功能很 可能導(dǎo)致斷碼問題，即跳轉(zhuǎn)后的片段起始位置正好位于一個中文字符編碼的低位(例如 "中"在GB碼通過兩個字節(jié)表示為"D6D0"(均為16進(jìn)制表示)，這里所表述的意思為恰好 讀取為D0，也就是將其前面的一個字節(jié)"D6"漏掉)，從而引起后文的碼值全部錯位，因此導(dǎo) 致了斷碼問題，表現(xiàn)出來均為亂碼顯示。 針對上述編碼問題，本發(fā)明在讀取任意文本片段后進(jìn)行了自適應(yīng)的微調(diào)解碼。
根據(jù)GB碼的編碼規(guī)則可以知道，ASCII碼值采用單字節(jié)表示，漢字等非ASCII碼 字符采用雙字節(jié)標(biāo)志，而雙字節(jié)有一定的規(guī)則高位字節(jié)范圍是80-FE，低位字節(jié)范圍是 40-FE。 另外基于文本中兩類編碼長度的字符的穿插問題(即普通文本必有標(biāo)點符號等 ASCII字符，如換行符等，或如果沒有相應(yīng)的符號則所有內(nèi)容均變?yōu)榱穗p字節(jié)編碼文本，緊 需要判斷偏移量是否為偶數(shù)即可)，在解碼時完全可以根據(jù)讀取位置的前后兩個字節(jié)進(jìn)行 多種可能性判斷。如果無法判斷，則可以往后讀取一定內(nèi)容直到遇到相應(yīng)的ASCII字符，即 可以確定是否解碼錯誤，如果解碼有誤，則說明遇到斷碼。緊需要將起始位置向后或向前移 動一個字節(jié)即可解決當(dāng)前斷碼問題。 本發(fā)明為了實現(xiàn)文本的無縫銜接，選擇采用向前移動一個字節(jié)，然后將所讀取內(nèi) 容與前一片段進(jìn)行無縫銜接。 上述解碼過程在讀取某一文件塊進(jìn)行分頁，采用了線程的設(shè)計，所以對于處理中
的靈活跳轉(zhuǎn)可以很好的進(jìn)行控制，避免了分段分時循環(huán)造成的變量控制問題。 接下來，就分行處理為主說明本發(fā)明技術(shù)方案中文字排版的處理過程。 圖3示出本發(fā)明的文字排版流程圖，如圖3所示，步驟300開始，通過頁表信息
取出頁面內(nèi)容，在明確了頁起始位置Page—start和頁字符數(shù)Page_Char_num等頁表信息
后，就可以通過內(nèi)容指針取得頁面內(nèi)容，艮P Pcontent = Read_content (Page_start， Page_
char—皿m)。 步驟302中，將頁面編碼轉(zhuǎn)化為Unicode字符統(tǒng)一處理，即由轉(zhuǎn)碼函數(shù)PUnicode =code—convertion(Pcontent， Ntype)。 步驟304中，分行處理開始，初始化行鏈表，Plink = Init-link()。 步驟306中，對頁面字符進(jìn)行判斷，當(dāng)檢測到CR或LF時，進(jìn)入步驟308中，作為一
段進(jìn)行自動分行，并可根據(jù)需要是否在段落開始處進(jìn)行字符偏移(即通常所說的首行縮進(jìn)
模式)，其具體操作是把該段字符加入到行鏈表中，其內(nèi)容包括目標(biāo)鏈表、行起始地址和行
字節(jié)數(shù)，即Add_link(Plink， line_start， line_cnt)，然后返回步驟306中重新進(jìn)行處理并
執(zhí)行后續(xù)步驟。 步驟3Q6中，當(dāng)沒有檢測到CR或LF時，進(jìn)入步驟310中，判斷是否檢測到結(jié)尾，并且該判斷只會在頁面尾部判斷一次。 步驟312中，分行結(jié)束，即Finish—scale(Plink)，同時把Plink指針傳送給全局變 步驟314中，該頁行鏈表建立完畢，發(fā)事件通知上層進(jìn)行顯示，即SendEvent ()。
由于本發(fā)明針對靈活的顯示設(shè)置進(jìn)行處理，所以對于移動便攜電子產(chǎn)品經(jīng)常采用 的全屏或非全屏的自由切換及改變字體樣式大小等要求，文字的排版問題是比較關(guān)鍵的。
排版時充分考慮到不同pc平臺采用的文本字符存儲規(guī)則不同。針對性的進(jìn)行了 自適應(yīng)處理，主要是指行切換的表示。Windows平臺的文本采用"CR+LF"，蘋果Mac系統(tǒng)的 僅使用"CR"，而Li皿x操作系統(tǒng)采用"LF"，所以需要對不同系統(tǒng)生成文本的換行格式在解 析文本時進(jìn)行統(tǒng)一并實現(xiàn)充分自適應(yīng)。 同時，為了更好的顯示，采用了鏈表對便攜電子產(chǎn)品需要顯示的每一行內(nèi)容進(jìn)行 了記憶，類似于頁表信息的處理，這樣顯示的相關(guān)處理就可以具體到行，方便在閱讀過程中 對閱讀模式自由切換以及進(jìn)行其他多樣化操作。 本發(fā)明的技術(shù)方案中文字排版處理類似于pc端中文本閱讀器中"自動換行"的功 能實現(xiàn)，使文本可以針對當(dāng)前屏幕寬度自動完整顯示于屏幕中，免去了段落過長導(dǎo)致的顯 示不全等問題，或需要滾動條進(jìn)行拖動的操作。 而針對字體的變換，僅僅需要在字符串測量函數(shù)中更改字體大小即可，因此，在分 頁過程完全做到了對字體大小的去相關(guān)化。 圖4示出本發(fā)明的顯示位置移動示意圖，如圖4所示，黑邊窗口為當(dāng)前顯示在屏幕 的文本內(nèi)容，三個顯示片段分別為一次載入內(nèi)存的三個文本信息。 這里只保存著分行后的行偏移量信息，并非將實際的文件塊內(nèi)容載入；每次上下
行滾動或翻頁時將當(dāng)前陰影窗口向前后移動。
上述的移動包括兩種移動方式 其一，文件塊內(nèi)的頁面之間的顯示移動； 其二，文件塊之間頁面的顯示移動。 在此統(tǒng)稱為顯示片段，也就是說顯示片段可以是代表不同文件塊，也可以代表一 個文件塊內(nèi)的不同頁面。 接下來從總體上說明顯示片段的切換過程 當(dāng)陰影窗口移動到上圖狀態(tài)時，即陰影窗口的起始位置已不在中間文本顯示片段 的內(nèi)時，需要進(jìn)行顯示片段切換。 具體來說，需要將頭片段信息釋放，并在尾片段后補(bǔ)充下一片段的信息鏈，并將原 尾片段置為中間片段，原中間片段置為頭片段，而新添加的片尾置為尾片段。這樣就保證了 每次顯示內(nèi)容均處與中間片段有交疊信息，即整個過程始終處于上下文非空的狀態(tài)。
上述處理實際是為了保證每次的翻頁或翻行動作執(zhí)行時，可以直接讀取下一頁需 要顯示內(nèi)容的行信息。 這樣也避免了傳統(tǒng)操作中對于片段解碼后向前翻滾即向前翻頁或向前翻行時容 易出現(xiàn)亂碼的問題。因為對于非ASCII碼字符的眾多編碼方式大多是與ASCII的編碼長度 不一致，因此向前讀取文本內(nèi)容時容易出現(xiàn)編碼判斷失誤導(dǎo)致的斷碼問題，從而引起相應(yīng) 的亂碼問題。
圖5示出本發(fā)明的顯示位置移動流程圖，如圖5所示，較完整的示意該處理過程。 首先，定義三個buffer,分別為 m_pPrev (代表Part I中的文本)； m_pMiddle (代表Part II中的文本)； m_pNext (代表Part 111中的文本)； 及行鏈表丄ink氺m—LineLink， m_pCurrentNode。 Link節(jié)點中存有 1、該行文本內(nèi)容的指針起始位置-pText ; 2 、該行的行字節(jié)數(shù)一nLength 。 假定當(dāng)前便攜電子產(chǎn)品每頁可以顯示的行數(shù)為LINE_PER_PAGE ;以及 Link相關(guān)的操作函數(shù)統(tǒng)一以Link—開頭。 該部分的幾個重要處理過程為 A、 nCurrentCnt = Link—GetCo皿t (&m—LineLink); 得到當(dāng)前鏈表中的行數(shù)； B、 如果當(dāng)前鏈表中的內(nèi)容不夠現(xiàn)實三頁(假定當(dāng)前處于文本中段，沒有顯示到尾 部)，需要補(bǔ)充內(nèi)容。 If (nCurrentCnt < 2*LINE_PER_PAGE) {Uintl6 nPageOffset，nPageCnt ; 〃定義臨時變量以便取得頁的起始偏移位置及字符數(shù)Link^pNewPageLink ; 〃新載入頁面的行信息指針 GetNextPagelnfo(&nPageOffset，&nPageCnt); 〃取得下一頁內(nèi)容的起始偏移位置及該頁所含字符數(shù) pNewPageLink = PageLoad(m_pNext， nPageOffset, nPageCnt); 〃將下一頁內(nèi)容載入，并將該頁行信息內(nèi)容形成鏈表返回Link—Add(&m_LineLink，pNewPageLink); 〃將當(dāng)前取得的新頁的行鏈表添加到全局鏈表尾部 } C、 將設(shè)當(dāng)前頁顯示的起始位置如圖4a所示，且該起始位置所在行節(jié)點為m— pCurrentNode。 假如現(xiàn)向后翻頁，則頁面位置狀態(tài)會變成圖4b : 可以看到，下一頁內(nèi)容暫時無法顯示完全，故需要在翻頁前將Parti部分釋放掉， 并將Part II及Part III順次前移為Part I及Part II，最后在載入下一頁，將其添加到
鏈表中，并將相關(guān)變量內(nèi)容設(shè)置到適當(dāng)?shù)漠?dāng)前位置。 具體流程如下
If (FALSE = = JudgeLinkLef t (&m_LineLink， m_pCurrentNode))
{FreeHeadPart(&m_LineLink， LINE_PER_PAGE) 〃將鏈表中part I部分的節(jié)點釋放掉Free—Buffer(m_pPrev) 〃將Part I部分的內(nèi)容指針釋放MoveBuffer—To—Left (m_pPrev， m_pMiddle， m_pNext) 〃左移緩存區(qū)指針 〃載入下一頁具體過程見B部分 }m_pCurrentNode = LinkGetNext (&m_LineLink， LINE_PER_PAGE) 〃從當(dāng)前節(jié)點往后移動一頁行數(shù)的節(jié)點數(shù)，得到下一頁開始顯示的節(jié)點位置 Display(&m—LineLink， m_pCurrentNode) 〃從pCurrentNode所指位置開始顯示下一頁內(nèi)容，具體Display函數(shù)實現(xiàn)已分析 過。 圖6示出本發(fā)明解碼裝置的第一實施例結(jié)構(gòu)圖，如圖6所示，該閱讀器包括文件 塊處理模塊、內(nèi)容解析模塊。 文件塊處理模塊依據(jù)設(shè)定的宏值，將txt文件虛擬劃分為若干個文件塊。 內(nèi)容解析模塊按照需要解碼的順序，依次載入文件塊處理模塊輸出的文件塊并對
文件塊的內(nèi)容進(jìn)行解碼。 圖7示出本發(fā)明解碼裝置的第二實施例結(jié)構(gòu)圖，如圖7所示，該閱讀器包括文件 塊處理模塊、內(nèi)容解析模塊和內(nèi)容分頁模塊。 文件塊處理模塊依據(jù)設(shè)定的宏值，將txt文件虛擬劃分為若干個文件塊。 內(nèi)容解析模塊按照需要解碼的順序，依次載入文件塊處理模塊輸出的文件塊并對
文件塊的內(nèi)容進(jìn)行解碼。 內(nèi)容分頁模塊對內(nèi)容解析模塊解碼后的文件塊進(jìn)行分頁處理并對其頁表信息進(jìn) 行保存。 上述內(nèi)容分頁模塊還包括如下處理 取出解碼后的文件塊，并將文件塊的內(nèi)容轉(zhuǎn)化為Unicode字符； 在文件塊的Unicode字符中檢測到CR或LF時，均進(jìn)行分行處理。 以上兩個實施例的內(nèi)容解析模塊對文件塊的解碼，通過首先判定其編碼規(guī)則，然
后針對性的進(jìn)行解碼，其處理方法同上述解碼方法的處理過程。 針對當(dāng)前便攜電子產(chǎn)品(包括手機(jī)、電子詞典、PDA、 MP3和MP4等)中txt文本 應(yīng)用越來越頻繁，及當(dāng)前信息量的不斷增加，對于目前基于不同平臺的便攜電子產(chǎn)品中，尤 其是中低端手機(jī)對于文本文件解碼限制較多，并且功能不夠完善；傳統(tǒng)的直接載入并解碼 排版的方式已經(jīng)不適應(yīng)當(dāng)前的應(yīng)用需求，并且對用戶的多樣化操作支持不夠完善。該技術(shù) 將解決便攜電子產(chǎn)品對文本文件解碼中的容量大小限制，并支持如對各種編碼格式的自適 應(yīng)、自動優(yōu)化排版以及任意跳轉(zhuǎn)、翻頁等操作。 針對上述問題，該技術(shù)設(shè)計基于不限制目標(biāo)文件大小，同時打開速度對與文件大小無關(guān)，并支持對多樣式的顯示及排版等要求，進(jìn)行了處理結(jié)構(gòu)的創(chuàng)新，實現(xiàn)了諸如對任意 txt文本文件的解析和排版功能，根據(jù)中斷支持字庫切換字體大小，更改字體顏色及背景顏 色等基本功能，同時也支持用戶對文件瀏覽的多樣化操作。 以上對本發(fā)明的具體描述旨在說明具體實施方案的實現(xiàn)方式，不能理解為是對本 發(fā)明的限制。本領(lǐng)域普通技術(shù)人員在本發(fā)明的教導(dǎo)下，可以在詳述的實施方案的基礎(chǔ)上做 出各種變體，這些變體均應(yīng)包含在本發(fā)明的構(gòu)思之內(nèi)。本發(fā)明所要求保護(hù)的范圍僅由所述 的權(quán)利要求書進(jìn)行限制。
權(quán)利要求
一種txt文件的解碼方法，包括如下步驟步驟a依據(jù)設(shè)定的宏值，對txt文件虛擬劃分為若干個文件塊；步驟b按照需要解碼的順序，依次載入文件塊并對所述文件塊的內(nèi)容進(jìn)行解碼。
2. 如權(quán)利要求1所述的txt文件的解碼方法，其特征在于，在步驟b之后還包括步驟C :對解碼后的文件塊進(jìn)行分頁處理，并對其頁表信息進(jìn)行保存。
3. 如權(quán)利要求1或2所述的txt文件的解碼方法，其特征在于，所述步驟c中對解碼后的文件塊進(jìn)行分頁處理前還包括如下步驟步驟cl :取出解碼后的文件塊，并將文件塊的內(nèi)容轉(zhuǎn)化為Unicode字符； 步驟c2 :在文件塊的Unicode字符中檢測到CR或LF時，均進(jìn)行分行處理。
4. 如權(quán)利要求3所述的txt文件的解碼方法，其特征在于，所述txt文件的編碼類型包 括以下幾種中的一種或多種GB2312/GBK、 unicode、 uincode-BE、 utf-8。
5. 如權(quán)利要求4所述的txt文件的解碼方法，其特征在于所述文件塊采用線程方式進(jìn)行處理，并在其完成解碼和/或分頁并保存后結(jié)束線程。
6. —種txt文件的解碼裝置，包括文件塊處理模塊依據(jù)設(shè)定的宏值，將txt文件虛擬劃分為若干個文件塊； 內(nèi)容解析模塊按照需要解碼的順序，依次載入文件塊處理模塊輸出的文件塊并對文 件塊的內(nèi)容進(jìn)行解碼。
7. 如權(quán)利要求6所述的txt文件的解碼裝置，其特征在于，還包括內(nèi)容分頁模塊對內(nèi)容解析模塊解碼后的文件塊進(jìn)行分頁處理并對其頁表信息進(jìn)行保存。
8. 如權(quán)利要求7所述的txt文件的解碼裝置，其特征在于，所述內(nèi)容分頁模塊還包括如下處理取出解碼后的文件塊，并將文件塊的內(nèi)容轉(zhuǎn)化為Unicode字符； 在文件塊的Unicode字符中檢測到CR或LF時，均進(jìn)行分行處理。
9. 一種電子產(chǎn)品，其特征在于 包括權(quán)利要求6或7或8所述的解碼裝置。
10. 如權(quán)利要求9所述的電子產(chǎn)品，其特征在于 所述電子產(chǎn)品為手機(jī)、電子詞典、PDA、 MP3和MP4。
全文摘要
本發(fā)明披露了一種txt文件的解碼方法及其裝置及包括該裝置的電子產(chǎn)品。該方法包括如下步驟依據(jù)設(shè)定的宏值，對txt文件虛擬劃分為若干個文件塊；按照需要解碼的順序，依次載入文件塊并對所述文件塊的內(nèi)容進(jìn)行解碼。本發(fā)明解決了解碼中文本文件的大小限制，同時對目標(biāo)文件進(jìn)行了自適應(yīng)編碼解析及自適應(yīng)排版功能，不增加任何硬件成本。
文檔編號H04M1/72GK101763408SQ20091023016
公開日2010年6月30日 申請日期2009年11月19日 優(yōu)先權(quán)日2009年11月19日
發(fā)明者常熠 申請人:青島海信移動通信技術(shù)股份有限公司