CN101763407A

CN101763407A - 一种基于Brew平台的txt文件阅读方法及其阅读器

Info

Publication number: CN101763407A
Application number: CN200910230163A
Authority: CN
Inventors: 常熠
Original assignee: Hisense Mobile Communications Technology Co Ltd
Current assignee: Hisense Mobile Communications Technology Co Ltd
Priority date: 2009-11-19
Filing date: 2009-11-19
Publication date: 2010-06-30
Anticipated expiration: 2029-11-19
Also published as: CN101763407B

Abstract

本发明披露了一种基于Brew平台的txt文件阅读方法及其阅读器。该方法包括如下步骤：依据设定的宏值，对txt文件虚拟划分为若干个文件块；按照阅读的顺序，依次载入文件块并对所述文件块的内容进行解码；依据显示需求，对解码后的文件块进行分页处理并对其页表信息进行保存；对需要阅读的页面，调用Brew平台的接口函数并根据保存的页表信息进行显示。本发明对文本文件的大小没有限制，同时对目标文件进行了自适应编码解析及自适应排版功能，可以使用户多样化操作和使用。

Description

一种基于Brew平台的txt文件阅读方法及其阅读器

技术领域

本发明涉及一种文件阅读方法及其阅读器，尤其是一种基于Brew平台的txt文件阅读方法及其阅读器。

背景技术

当前用户对于手持终端的文本阅读功能要求越来越高，尤其是中低端终端由于内存大小等限制往往对操作的txt文件有文件容量限制。

一方面，超过终端硬件的限制则无法阅读，需要用户自行切割成多个文件才能阅读，这给用户的使用造成了不便；另一方面，在当前信息量激增的背景下，txt文件的容量越来越大，包含的信息量越来越多，对于这类大容量文件的阅读要求越来越迫切；同时，由于文件容量的增大，对于用户进行翻页，跳转等操作的多样性也越来越多，所以传统的txt文件阅读方法及其阅读器应用已无法满足当前及今后用户的基本要求和常用操作。

再者，当前终端类电子书应用的第三方软件已有不少，但绝大多数基于java平台的第三方软件；并且，这些软件对文件也有上述的限制和功能缺陷，而针对Brew平台的电子书应用更加匮乏。

另外，不同的系统生成的txt文件也会有差别。当前主要以Windows系统、苹果Mac系统以及Linux系统为主，其生成的文本字符存储规则均不相同，这就造成了txt文件在系统平台间移植时不能充分识别的问题。

总的来说，现有电子书应用主要存在以下一些问题：

1、对目标文件的大小存在限制，或对大容量文件的打开较慢等问题。

2、对各种编码及不同平台文本文件格式的不完全解析。

3、无法调节显示效果，如字体大小、前景及背景颜色、下划线等多样显示模式以及随意的跳转浏览，因此无法对阅读文件进行多样化操作处理。

因此，需要一种新的基于Brew平台的txt文件阅读方法及其阅读器以更好的解决手持终端文本阅读中存在的上述问题。

发明内容

有鉴于此，本发明致力于更好的解决手持终端文本阅读中存在的上述问题，提出了一种基于Brew平台的txt文件阅读方法及其阅读器。

根据本发明的第一方面，提供了一种基于Brew平台的txt文件阅读方法。该方法包括如下步骤：

步骤a：依据设定的宏值，对txt文件虚拟划分为若干个文件块；

步骤b：按照阅读的顺序，依次载入文件块并对所述文件块的内容进行解码；

步骤c：依据显示需求，对解码后的文件块进行分页处理并对其页表信息进行保存；

步骤d：对需要阅读的页面，调用Brew平台的接口函数并根据保存的页表信息进行显示。

上述方法在步骤c之后，在步骤d之前还包括步骤e：

判断需要阅读的页面的起始位置是否超出当前阅读的文件块的内容范围；

若是，则进入步骤d；

若否，返回步骤b并重新执行后续步骤。

上述步骤b开始，对所述文件块采用线程方式进行处理，并在其完成解码及分页并保存后结束线程。

上述步骤c中对解码后的文件块进行分页处理前还包括如下步骤：

步骤c1：取出解码后的文件块，并将文件块的内容转化为Unicode字符；

步骤c2：在文件块的Unicode字符中检测到CR或LF时，均进行分行处理。

根据本发明的第二方面，提供了一种基于Brew平台的txt文件阅读器。该txt文件阅读器包括：

文件块处理模块：依据设定的宏值，将txt文件虚拟划分为若干个文件块；

内容解析模块：按照阅读的顺序，依次载入文件块处理模块输出的文件块并对文件块的内容进行解码；

内容分页模块：依据显示需求，对内容解析模块解码后的文件块进行分页处理并对其页表信息进行保存；

显示模块：对需要阅读的页面，调用Brew平台的接口函数并根据内容分页模块保存的页表信息进行显示。

上述阅读器还包括显示移动处理模块：

当需要阅读的页面的起始位置不超出当前阅读的文件块的内容范围时，同时给显示模块准备需要阅读的页面及相邻页面的页表信息；

当需要阅读的页面的起始位置超出当前阅读的文件块的内容范围时，先由内容解析模块和内容分页模块载入下一个文件块处理后再给显示模块准备要阅读的页面及相邻页面的页表信息。

上述txt文件的类型可为Windows平台或苹果Mac平台或Linux系统类型。

根据本发明的第三方面，提供了一种移动通信终端。该移动通信终端包括本发明第二方面所述的各txt文件阅读器。

本发明的有益效果是：

本发明针对已经存在的电子书应用，进一步解决了文本文件的大小限制，同时对目标文件进行了自适应编码解析及自适应排版功能，可以使用户多样化操作和使用。

附图说明

下面将参照附图对本发明的具体实施方案进行更详细的说明，其中：

图1是本发明的文件块整体处理流程图；

图2是本发明的自适应解码流程图；

图3是本发明的文字排版流程图；

图4是本发明的显示位置移动示意图；

图5是本发明的显示位置移动流程图；

图6是本发明的文本显示流程图；

图7是本发明阅读器的第一实施例结构图；以及

图8是本发明阅读器的第二实施例结构图。

具体实施方式

为了解决手持终端文本阅读中存在的容量限制及阅读速度受限的问题，本发明提供了一种基于Brew平台的txt文件阅读方法及其阅读器。

首先来说明一下本发明的技术术语。

文件块：将文件分成设定大小的片段进行分析的文件片段，也就是只进行虚拟分块，并不改变原文件的大小和结构。

虚拟分页：每次按设定的可以显示的最大行数进行分页，并保存相应的页信息，与实际显示的页不一定相同。

Cache：每次读取文件片段后将该片段内的页表信息存储于事先分配好的空间中，这段程序生命周期始终作为快速读写的存储区定义为Cache。

接下来，结合各附图分多个小部具体说明该阅读方法及其阅读器，其中，具体的函数以及操作均以伪码表示。

图1示出本发明的文件块整体处理流程图，如图1所示，步骤100开始，读取文件大小信息开始，file_size＝Getfilesize()。

步骤102中，根据定义的宏值Fragment_size，分析计算文件块的数量，Frags＝file_size/Fragment_size+1。

步骤104中，创建线程Creat_thread，并初始化线程Init_thread，以开始分析文件块的内容Thread_start。

步骤106中，从预设偏移量开始读取一个文件块，start_position为定义的偏移量参数，则Read_block(start_position)。

步骤108中，分析该文件块内容，即对文本内容进行解码；然后进行分页，由分页处理函数Block_pagescale()进行处理，并记忆页表信息到全局变量，即由Block_offset_recite()进行保存。其中，页表信息包括页始偏移量和页长度。并由Finish_pagingscale()函数最终完成分页。

步骤110中，文件块分析完毕后，并且页表信息也已准备好，发事件通知上层准备显示，SendEvent()。

步骤112中，完成该文件块操作后释放线程，即Release_thread()。

由上可知本发明基于Brew平台的txt文件阅读方法基本包括如下步骤：

步骤a：依据设定的宏值(其大小可以为1K-1M，主要根据硬件的情况而定)，对txt文件虚拟划分为若干个文件块。

步骤b：按照阅读的顺序，依次载入文件块并对所述文件块的内容进行解码。

步骤c：依据显示需求(主要包括每页显示的最大行数，其相关到显示屏的可显示像素点数和显示字体的大小等)，对解码后的文件块进行分页处理并对其页表信息进行保存。

针对硬件对文件大小有相应限制的情况，同时又达到读取速度需要与文件容量无关，故根据使用平台的不同，可以定义每次读取文件块的宏值。不同终端可以根据自身的软硬件配置，设置宏值的大小。

每次读取时针对高通平台的特点，可以使用线程进行操作，避免使用较长时间的循环导致底层其他任务超时引起的异常。

每次解析相应文本片段的内容，需要将该段内容进行虚拟分页处理，并将每块的起始绝对位置存储于cache中，以便每次读取时无需再次重新解析，并最小化对终端的cache容量大小需求。

图2示出本发明的自适应解码流程图，如图2所示，步骤200开始，读取文件块内容，并把读到的内容返回给指针。定义指针Pcontent，使Pcontent＝Read_block(start_position)。

步骤202中，从文件块始偏移量开始读取文件块内容，以进行解码。

步骤204中，判断编码格式并根据编码格式进行解码，即判断编码格式函数进行判断Ntype＝Get_codingtype(Pcontent)，然后由解码函数进行解码Ret＝Coding_convention(Ntype，Pcontent)，也即进行转码转换成统一的码型，本发明采用unicode码。

步骤206中，进一步对转换后的码进行字节判断，即Chars_judgement(Ret)，如果在字节判断中遇到断码，则进入步骤208中，返回错误信息error；如果在字节判断中没有遇到断码，则进入步骤212中，返回success信息，说明整段解析成功，继续分页处理。

在步骤208之后，进入步骤210，从解析处向后向前偏移一个字节进行二次解析，也即Pcontent指针自动加1或减1，然后返回步骤204中，重新进行解析，并执行后续步骤。

针对文本文件编码方式的不同，需要对每一片段进行解码时需要进行码转换过程，由于国内常用的编码方式有GB2312/GBK，unicode，uincode-BE，utf-8等，针对含有非ASCII字符的编码格式各有不同。

由于采用unicode，unicode-BE及utf-8编码方式的文件在文件头部(即文件最开始的几个字节)有相应的标志位，所以可以根据文件头读取的相应内容进行编码格式的判断，然后根据需要进行相应的转化。

然而对于以GB2312/GBK编码方式保存的文本文件没有对应的文件头标志位，所以对于读取内容的解析需要加以码值的控制和判断。尤其是对于可以任意跳转的功能很可能导致断码问题，即跳转后的片段起始位置正好位于一个中文字符编码的低位(例如：“中”在GB码通过两个字节表示为“D6D0”(均为16进制表示)，这里所表述的意思为恰好读取为D0，也就是将其前面的一个字节“D6”漏掉)，从而引起后文的码值全部错位，因此导致了断码问题，表现出来均为乱码显示。

针对上述编码问题，本发明在读取任意文本片段后进行了自适应的微调解码。

根据GB码的编码规则可以知道，ASCII码值采用单字节表示，汉字等非ASCII码字符采用双字节标志，而双字节有一定的规则：高位字节范围是80-FE，低位字节范围是40-FE。

另外基于文本中两类编码长度的字符的穿插问题(即普通文本必有标点符号等ASCII字符，如换行符等，或如果没有相应的符号则所有内容均变为了双字节编码文本，紧需要判断偏移量是否为偶数即可)，在解码时完全可以根据读取位置的前后两个字节进行多种可能性判断。如果无法判断，则可以往后读取一定内容直到遇到相应的ASCII字符，即可以确定是否解码错误，如果解码有误，则说明遇到断码。紧需要将起始位置向后或向前移动一个字节即可解决当前断码问题。

本发明为了实现文本的无缝衔接，选择采用向前移动一个字节，然后将所读取内容与前一片段进行无缝衔接。

上述解码过程在读取某一文本块进行分页，采用了线程的设计，所以对于处理中的灵活跳转可以很好的进行控制，避免了分段分时循环造成的变量控制问题。

接下来，就分行处理为主说明本发明技术方案中文字排版的处理过程。

图3示出本发明的文字排版流程图，如图3所示，步骤300开始，通过页表信息取出页面内容，在明确了页起始位置Page_start和页字符数Page_char_num等页表信息后，就可以通过内容指针取得页面内容，即Pcontent＝Read_content(Page_start，Page_char_num)。

步骤302中，将页面编码转化为Unicode字符统一处理，即由转码函数PUnicode＝code_convertion(Pcontent，Ntype)。

步骤304中，分行处理开始，初始化行链表，Plink＝Init_link()。

步骤306中，对页面字符进行判断，当检测到CR或LF时，进入步骤308中，作为一段进行自动分行，并可根据需要是否在段落开始处进行字符偏移(即通常所说的首行缩进模式)，其具体操作是把该段字符加入到行链表中，其内容包括目标链表、行起始地址和行字节数，即Add_link(Plink，line_start，line_cnt)，然后返回步骤306中重新进行处理并执行后续步骤。

步骤306中，当没有检测到CR或LF时，进入步骤310中，判断是否检测到结尾，并且该判断只会在页面尾部判断一次。

步骤312中，分行结束，即Finish_scale(Plink)，同时把Plink指针传送给全局变量。

步骤314中，该页行链表建立完毕，发事件通知上层进行显示，即SendEvent()。

由于本发明针对灵活的显示设置进行处理，所以对于移动终端经常采用的全屏或非全屏的自由切换及改变字体样式大小等要求，文字的排版问题是比较关键的。

排版时充分考虑到不同pc平台采用的文本字符存储规则不同。针对性的进行了自适应处理，主要是指行切换的表示。Windows平台的文本采用“CR+LF”，苹果Mac系统的仅使用“CR”，而Linux操作系统采用“LF”，所以需要对不同系统生成文本的换行格式在解析文本时进行统一并实现充分自适应。

同时，为了更好的显示，采用了链表对终端需要显示的每一行内容进行了记忆，类似于页表信息的处理，这样显示的相关处理就可以具体到行，方便在阅读过程中对阅读模式自由切换以及进行其他多样化操作。

本发明的技术方案中文字排版处理类似于pc端中文本阅读器中“自动换行”的功能实现，使文本可以针对当前屏幕宽度自动完整显示于屏幕中，免去了段落过长导致的显示不全等问题，或需要滚动条进行拖动的操作。

而针对字体的变换，仅仅需要在字符串测量函数中更改字体大小即可，因此，在分页过程完全做到了对字体大小的去相关化。

图4示出本发明的显示位置移动示意图，如图4所示，黑边窗口为当前显示在屏幕的文本内容，三个显示片段分别为一次载入内存的三个文本信息。

这里只保存着分行后的行偏移量信息，并非将实际的文本块内容载入；每次上下行滚动或翻页时将当前阴影窗口向前后移动。

上述的移动包括两种移动方式：

其一，文件块内的页面之间的显示移动；

其二，文件块之间页面的显示移动。

在此统称为显示片段，也就是说显示片段可以是代表不同文件块，也可以代表一个文件块内的不同页面。

接下来从总体上说明显示片段的切换过程：

当阴影窗口移动到上图状态时，即阴影窗口的起始位置已不在中间文本显示片段的内时，需要进行显示片段切换。

具体来说，需要将头片段信息释放，并在尾片段后补充下一片段的信息链，并将原尾片段置为中间片段，原中间片段置为头片段，而新添加的片尾置为尾片段。这样就保证了每次显示内容均处与中间片段有交叠信息，即整个过程始终处于上下文非空的状态。

上述处理实际是为了保证每次的翻页或翻行动作执行时，可以直接读取下一页需要显示内容的行信息。

这样也避免了传统操作中对于片段解码后向前翻滚即向前翻页或向前翻行时容易出现乱码的问题。因为对于非ASCII码字符的众多编码方式大多是与ASCII的编码长度不一致，因此向前读取文本内容时容易出现编码判断失误导致的断码问题，从而引起相应的乱码问题。

图5示出本发明的显示位置移动流程图，如图5所示，较完整的示意该处理过程。

首先，定义三个buffer，分别为：

m_pPrev(代表Part I中的文本)；

m_pMiddle(代表Part II中的文本)；

m_pNext(代表Part III中的文本)；

及行链表：Link*m_LineLink，m_pCurrentNode。

Link节点中存有：

1、该行文本内容的指针起始位置-pText；

2、该行的行字节数---nLength。

假定当前终端每页可以显示的行数为LINE_PER_PAGE；以及

Link相关的操作函数统一以Link_开头。

该部分的几个重要处理过程为：

A、

nCurrentCnt＝Link_GetCount(&m_LineLink)；

得到当前链表中的行数；

B、

如果当前链表中的内容不够现实三页(假定当前处于文本中段，没有显示到尾部)，需要补充内容。

If(nCurrentCnt＜2*LINE_PER_PAGE)

{

Uint16 nPageOffset，nPageCnt；

//定义临时变量以便取得页的起始偏移位置及字符数

Link*pNewPageLink；

//新载入页面的行信息指针

GetNextPageInfo(&nPageOffset，&nPageCnt)；

//取得下一页内容的起始偏移位置及该页所含字符数

pNewPageLink＝PageLoad(m_pNext，nPageOffset，nPageCnt)；

//将下一页内容载入，并将该页行信息内容形成链表返回

Link_Add(&m_LineLink，pNewPageLink)；

//将当前取得的新页的行链表添加到全局链表尾部

}

C、

将设当前页显示的起始位置如图4a所示，且该起始位置所在行节点为m_pCurrentNode。

假如现向后翻页，则页面位置状态会变成图4b：

可以看到，下一页内容暂时无法显示完全，故需要在翻页前将PartI部分释放掉，并将Part II及Part III顺次前移为Part I及Part II，最后在载入下一页，将其添加到链表中，并将相关变量内容设置到适当的当前位置。

具体流程如下：

If(FALSE＝＝JudgeLinkLeft(&m_LineLink，m_pCurrentNode))

{

FreeHeadPart(&m_LineLink，LINE_PER_PAGE)

//将链表中part I部分的节点释放掉

Free_Buffer(m_pPrev)

//将Part I部分的内容指针释放

MoveBuffer_To_Left(m_pPrev，m_pMiddle，m_pNext)

//左移缓存区指针

//载入下一页具体过程见B部分

}

m_pCurrentNode＝LinkGetNext(&m_LineLink，LINE_PER_PAGE)

//从当前节点往后移动一页行数的节点数，得到下一页开始显示的节点位置

Display(&m_LineLink，m_pCurrentNode)

//从pCurrentNode所指位置开始显示下一页内容，具体Display函数实现已分析过。

图6示出本发明的文本显示流程图，如图6所示，步骤600开始，取出页链表指针，即Plink＝Get_page-link()，从头节点读链表。

步骤602中，读取链表节点，即Pnode＝Get-link_start(Plink)。

步骤604中，画布指向位置移动到该行位置，

Idisplay_setclip(Pdisplay，position)，其中，position初始化值为0；

Idisplay_drawtext(Pdisplay，Pnode_text)。

步骤606中，加字高后，Position＝position+Font-Height，画布指向位置移动到字体底部，即Idisplay_moveto(Pdisplay，position)。

步骤608中，根据要求显示下划线等内容，即Idisplay_Drawline(Pdisplay)。

步骤610中，判断是否读取到链表下一节点，即Pnode＝Get_next(Plink，Pnode)，如果是，则返回步骤604中，重新移动并执行后续步骤；如果不是，则进入步骤612中，该页显示完毕，结束上述过程。

在本发明中，由于字体显示等调用高通BREW平台的功用接口函数，使得该应用完全可以将文字主题的显示功能全部实现，并可采用多样化的显示设置，可以显示用户自定义的字体颜色及背景颜色，同时支持下划线、虚线等附加格式的显示要求。

由于在对文件块解析时已经将内容解码并储存行链表中，所以需要从哪一行的位置开始显示仅仅需要将起始位置置于对应链表的节点处，然后根据显示区域大小对每一行调用Brew显示字体的公共接口函数画于屏幕的对应位置即可，在对每一行进行绘制时，可以根据当前设置的附件显示内容进行额外的处理，如当前行需要显示下划线，则在显示字体后将对应位置下方通过Brew公共接口函数绘制直线。

图7示出本发明阅读器的第一实施例结构图，如图7所示，该阅读器包括：文件块处理模块、内容解析模块、内容分页模块和显示模块。

文件块处理模块依据设定的宏值，将txt文件虚拟划分为若干个文件块。

内容解析模块按照阅读的顺序，依次载入文件块处理模块输出的文件块并对文件块的内容进行解码。

内容分页模块依据显示需求，对内容解析模块解码后的文件块进行分页处理并对其页表信息进行保存。

显示模块对需要阅读的页面，调用Brew平台的接口函数并根据内容分页模块保存的页表信息进行显示。

上述内容分页模块还包括如下处理：

取出解码后的文件块，并将文件块的内容转化为Unicode字符；

在文件块的Unicode字符中检测到CR或LF时，均进行分行处理。

上述内容解析模块解码的类型包括以下几种中的一种或多种：

GB2312/GBK、unicode、uincode-BE、utf-8。

图8示出本发明阅读器的第二实施例结构图，如图8所示，该阅读器包括：文件块处理模块、内容解析模块、内容分页模块、显示移动处理模块和显示模块。

显示移动处理模块，当需要阅读的页面的起始位置不超出当前阅读的文件块的内容范围时，同时给显示模块准备需要阅读的页面及相邻页面的页表信息；

上述内容分页模块还包括如下处理：

取出解码后的文件块，并将文件块的内容转化为Unicode字符；

在文件块的Unicode字符中检测到CR或LF时，均进行分行处理。

GB2312/GBK、unicode、uincode-BE、utf-8。

针对当前移动终端中电子书应用的使用越来越频繁，及当前信息量的不断增加，对于目前基于BREW平台的手机终端中，尤其是中低端手机对于文本文件电子书的阅读限制较多，并且功能不够完善；传统的直接载入并解码排版的方式已经不适应当前的应用需求，并且对用户的多样化操作支持不够完善。该技术将解决终端对文本文件阅读的容量大小限制，并支持如对各种编码格式的自适应，自动优化排版，及任意跳转，翻页等操作。

针对上述问题，该技术设计基于不限制目标文件大小，同时打开速度对与文件大小无关，并支持对多样式的显示及排版等要求，进行了处理结构的创新，实现了诸如对任意txt文本文件的解析和排版功能，根据中断支持字库切换字体大小，更改字体颜色及背景颜色等基本功能，同时也支持用户对文件浏览的多样化操作。

以上对本发明的具体描述旨在说明具体实施方案的实现方式，不能理解为是对本发明的限制。本领域普通技术人员在本发明的教导下，可以在详述的实施方案的基础上做出各种变体，这些变体均应包含在本发明的构思之内。本发明所要求保护的范围仅由所述的权利要求书进行限制。

Claims

1.一种基于Brew平台的txt文件阅读方法，包括如下步骤：

2.如权利要求1所述的txt文件阅读方法，其特征在于，在步骤c之后，在步骤d之前还包括步骤e：

若是，则进入步骤d；

若否，返回步骤b并重新执行后续步骤。

3.如权利要求1或2所述的txt文件阅读方法，其特征在于，所述步骤b开始，对所述文件块采用线程方式进行处理，并在其完成解码及分页并保存后结束线程。

4.如权利要求3所述的txt文件阅读方法，其特征在于，所述步骤c中对解码后的文件块进行分页处理前还包括如下步骤：

5.如权利要求4所述的txt文件阅读方法，其特征在于，所述步骤d中调用的Brew平台的接口函数包括以下类别中的一个或多个：

字体颜色、背景颜色、下划线、虚线。

6.一种基于Brew平台的txt文件阅读器，包括：

7.如权利要求6所述的txt文件阅读器，其特征在于，还包括显示移动处理模块：

8.如权利要求6或7所述的txt文件阅读器，其特征在于，所述内容分页模块还包括如下处理：

取出解码后的文件块，并将文件块的内容转化为Unicode字符；

在文件块的Unicode字符中检测到CR或LF时，均进行分行处理。

9.如权利要求6或7所述的txt文件阅读器，其特征在于，所述内容解析模块解码的类型包括以下几种中的一种或两种或多种：

GB2312/GBK、unicode、uincode-BE、utf-8。

10.一种移动通信终端，其特征在于包括权利要求6或7所述的txt文件阅读器。