TXT文件是最常见的文件格式，互联网上的图书，TXT格式的也是最常见、最多的，因为它的通用性高，基本上大多数的设备都能支持TXT格式。有人认为TXT格式的处理很简单，其实TXT格式文件的处理并不简单。手持电子阅读器由于受到CPU频率和内存本身的限制，在处理文件时不可能和电脑一样，哪怕同样是200MHZ的CPU，手持设备上的嵌入式CPU和电脑上的通用CPU也是不一样的，它比不上电脑CPU的性能。本文和大家一起分析一下几款主流产品对TXT图书分页的处理。
经常有人说，我用博朗EV960、博朗EV880、翰林V3、翰林V5等产品看TXT时，发现页数不正确，明明显示是500页，可以500页看完了，后面还能翻上10几页。而且越大的TXT图书，这种问题越严重。
TXT文件不像WORD、PDF文件一样带格式，TXT文件本身并没有任何格式，形象的说，它就是记流水账。如果我们要取得某个TXT文件的总页数，那么就需要先将该文打开，计算文件的总字数，然后根据一屏显示多少字，然后用总字数去除以一屏显示的字数，得到总页数。看起来很简单，是不是？问题是电子阅读器的CPU及内存都不大，如果每个TXT文件都这么处理，小的文件当然没有问题，但是碰到超2M以上的TXT文件，全部计算一次，就需要花费大量的时间。如果我们打开一本2M的TXT图书，你要等待5秒的时间才能打开，你能接受吗？难以接受。所以精确计算的方法行不通。就算你第一次能接受，OK，我们在看书经常用到放大字体功能，我们一按放大键，字体变大了，每一屏显示的字数变少了，豪无疑问题，总页数就会变多，如果你放字或者缩小一下字体，系统再重新计算一次，你再等待5秒，你还能接受吗？
如果你理解了TXT文件分页处理的难度，你就很容易理解现在的电子阅读器进行分页处理的难处。一起来看看各厂商都怎么来解决这个问题的。(注意：以下的分析仅为一路书香网的猜测与分析，并非各厂商提供，可能与实际有所区别)。
博朗EV880：我们之前用博朗EV880打开大超过2M的TXT测试，发现TXT文件越大，翻页也就越慢。EV880就是采用预估总页数来处理的，我们使用EV880看小说，文件越大，最后多出来的页数就越多。比如显示2000页，实际翻到最后，可能出来2030页来。文件越大，这个误差越大。
博朗EV960：用EV960看TXT图书时，可以注意观察一下，打开一本大一些的TXT图书时，最下面的页码显示并没有，而过一会儿计算完毕以后，那个页码才显示出来。将书翻到中间的页码，退出，再打开这本书，同样发现页码并没有出现，但是你向后翻一页，并没有影响。这时向前翻，就会提示“处理中，请稍侯...”，页数计算完就会正常。实际上，博朗EV960在你打开TXT时，从打开的位置往后读若干页内容供你先阅读，而不是全部计算，让你先有内容可看，等你这几页看完了，在后台计算的页数，也就显示出来了。但是EV960没有预读前几页的内容，可能开发人员认为你不会向前翻页，也就没有处理。所以这时你向前翻，就穿帮了。
再来看翰林V2和翰林V3，同样的问题，如何处理的呢？翰林V2在TXT分页了，改正了多次：
在翰林V2上市时，对于TXT的处理就是采用不分页的方式，当你打开TXT图书时，先按一屏显示的字数，程序从原文头开发始读出两页的内容以节省时间，以前用V2的朋友可能还记得，看TXT时，下面显示的总是1/3，你翻一页以后，就显示2/4，很明显示，这个总页数是不对的。
后来大家都反应没有总页数不方便，津科就在翰林V2的菜单里增加了一个跳到最后一页，你操作翻到最后一页时，程序就全部计算一下总页数，当然这个时间长一些，你会认为是页数多，觉得正常，如果一打开TXT时要这么长时间计算，你就要开骂了。然后你再回到第一页，总页数就有了。这样的操作从程序处时时间上说，还是比较合理的，但是用户觉得还是要多两次操作，不方便。
最后软件升级时，就将总页码改成了预估式的。根据文件的大小，预估出总页码来。所以预估会导致总页数多多少少有些不准。翰林V3基本上敢是同样的处理方式。
翰林V5：目前翰林V5在处理TXT图书时，还是采用预估总页数的方式，同样存在误差。在你按放大或者缩小时，也会重新预估计算总页数，但总体上不会是百分之百准确的。
这次为大家简单的分析了几款产品的TXT分页处理方式，最简单的格式也往往是最难处理的，我们不能用电脑和手持阅读设备相比。大家也会发现，打开大一些的TXT文件往往比打开同样大小的PDF还要慢上一点点，就是因为TXT需要计算。而PDF这类格式本身就是带页码的，读出来就可以了。作为厂商，需要在用户操作和CPU性能、速度之间找一个平衡点。