CHM格式分析及优化

HUNAN UNIVERSITY
毕业设计(论文)
CHM 格式分析及优化
摘 要 随着信息技术的发展，个人计算机越来越普及。

人们也越来越多的利用计算机方便自己的生活。

人们在计算机上阅读的需求也日益增长。

其中CHM 就是一种非常普及广泛的电子书籍格式。

另一方面，随着个人掌上电脑，智能手机的发展，人们也花费更多的时间阅读电子书籍。

但移动设备的处理能力离PC 尚有较大的差距，因此如何快速有效的解析CHM 格式电子书籍是移动设备上阅读软件的需求。

本课题研究的目的在于为PC 和移动设备平台提供CHM
电子书籍的解析功
设计论文题目： CHM 格式分析及优化
能。

在充分分析CHM格式规范的基础上，比较各种主流解析CHM方法，在CHM 阅读器性能方面进行优化分析和处理。

难点：该课题主要的难点在于如何分析CHM的格式的各个部分,特别是在无微软官方格式说明的情况下。

如何兼容各种版本的CHM格式文件也是一项艰巨的任务。

同时，对应于手机移动设备的特殊硬件条件，如何使程序占用极少的内存的同时以快速的方式解析文件，为用户提供流畅的阅读体验是本课题的重点。

关键词：CHM，手机移动设备，解析
The analysis and optimization on CHM
Abstract
With the development of information technology, personal computers becoming increasingly popular. More and more people are using computers to facilitate their lives, such as reading books. CHM, which is a very popular format for a wide range of e-books. On the other hand, the number of PC and smart mobile device stepping into human’s lives grows day by day, people will spend more time reading e-books. However, there’s a huge gap between the processing power of mobile devices and PC’s, so the solution about how to resolve CHM quickly and efficiently on mobile devices is the most need.
The system’s purpose is to provide the parsing CHM function for the PC and mobile device platform. Certainly, it’s based on a full analysis on the CHM format specification, comparing numbers of main CHM parsing methods. More work is attached on CHM parser’s performance optimization.
Difficulties: The main difficulty lies in how to analyze all parts of CHM format, especially on the situation of no formal Microsoft CHM specification. How to support various CHM versions is also an uneasy task. At the same time, corresponding to the special mobile hardware condition, how to force the system to use least memory but to run the parsing process most quickly, providing smooth reading experience is this subject’s key point.
Key words: CHM, mobile phone equipment, parse
目录
1.绪论 (1)
1.1.研究背景 (1)
1.2.研究意义 (1)
1.3.研究现状 (2)
1.4.主要思路 (2)
2.微软帮助系统 (3)
2.1.帮助系统说明 (3)
2.2.CHM帮助 (4)
2.3.CHM主要格式 (4)
2.3.1. CHM格式概览 (5)
2.3.2. 初始化头 (6)
2.3.3. 头节记录 (6)
2.3.4. 内容节偏移 (7)
2.3.5. 头节0 (7)
2.3.6. 头节1 (7)
2.4.内容文件格式 (10)
2.4.1. #SYSTEM (11)
2.4.2. #WINDOWS (12)
2.4.3. #STRINGS (13)
2.4.4. #TOCIDX (14)
2.4.5. #TOPICS (14)
2.4.6. #URLSTR (15)
2.4.7. #URLTBL (15)
2.4.8. $FIftiMain (15)
2.5.网站地图格式 (19)
2.5.1. HHC格式 (20)
2.5.2. HHK格式 (21)
3.系统总体设计 (23)
3.1.系统设计原则 (23)
3.2.系统总体要求 (23)
3.3.系统总体框架 (23)
3.4.功能设计 (24)
3.5.接口设计 (25)
3.5.1. CHM解析器接口 (25)
3.5.2. CHM文件读取对象接口 (26)
3.5.3. CHM文件流对象接口 (28)
3.5.4. LZX解压缩接口 (29)
3.6.数据结构设计 (30)
3.6.1. 目录树数据结构 (30)
3.6.2. 关键字搜索结果数据结构 (31)
3.7.辅助功能设计 (32)
3.7.1. 反编译功能 (32)
3.7.2. 书签 (33)
3.7.3. 错误处理 (33)
3.7.4. 解析日志 (33)
3.7.5. 内存测量 (33)
3.7.6. 时间测量 (34)
4.解析流程设计及优化 (35)
4.1.基本解析流程 (35)
4.2.详细解析流程 (36)
4.2.1. CHM打开流程 (36)
4.2.2. CHM读取文件流程 (37)
4.2.3. CHM解析目录树流程 (39)
4.2.4. CHM搜索关键字流程 (40)
4.3.重要算法分析 (40)
4.3.1. 字符串查找算法 (40)
4.3.2. 目录解析算法 (45)
4.4.性能优化策略 (47)
4.4.1. 流式解析 (47)
4.4.2. 文件缓存 (48)
4.4.3. 内容预读 (48)
4.4.4. 多线程解析 (48)
4.4.5. 文件流对象 (48)
4.4.6. 随机解压 (49)
4.4.7. MAP索引目录 (49)
4.4.8. 写入临时文件 (50)
4.4.9. 解析配置 (50)
5.运行环境 (51)
5.1.硬件环境 (51)
5.2.软件环境 (51)
6.结论与展望 (52)
6.1.结论 (52)
6.2.展望 (52)
致谢 ............................................................................................. 错误！未定义书签。

参考文献 (53)
附：本文所用图表汇总说明 (54)
1.绪论
1.1.研究背景
目前电子书籍的阅读日益增长，而CHM作为一种主流的电子书籍格式，在各个平台将得到充分的支持。

目前主流的电子书籍格式有：TXT,JAR,UMD,CHM,EXE，PDF。

TXT纯文本的方式缺乏良好的阅读体验；JAR需要专门的JA V A支持；UMD主要在手机平台上出现，需要专门的解析器，目前的书籍数量不多；EXE一般在PC平台上使用，但由于可执行性多了一些安全危险；CHM是由微软支持的格式，虽然格式规范不曾公布，但由于Windows操作系统的流行，使得CHM格式的书籍最多，同时也因为CHM良好的兼容支持和优秀的阅读体验使之成为最流行的电子书籍格式。

PDF是由Adobe公司支持的格式，也需要专门的阅读器，对于安全性有了很大提高，但也因制作繁琐和阅读不便，一般在PC上使用。

1.2.研究意义
强大的CHM格式兼容性.CHM文件格式是微软1998年推出的基于HTML 文件特性的帮助文件系统，以替代早先的WinHelp帮助系统，它也是一种超文本标识语言，在Windows 98中把CHM类型文件称作“已编译的HTML帮助文件”。

CHM同样支持被IE浏览器所支持的JavaScript、VBScript、ActiveX、Java Applet、Flash、常见图形文件（GIF、JPEG、PNG）、音频视频文件（MIDI、WA V、A VI）等等，并可以通过URL 与Internet联系在一起。

CHM的广泛普及. 原来的软件大多数采用扩展名为HLP的帮助文件（Win Help ），但随着互联网的发展，这种格式的帮助文件已经难以适应软件在线帮助的需要，以及更加人性化更加简单易于查看的需要，因此一种全新的帮助文件系统HTML Help由微软率先在Windows98中使用了。

由于它是一个经过压缩的网页集合，不但减小了文件的体积，更利于用户从INTERNET上下载，并且还支持HTML的各种特性，因此很快受到广大软件作者和软件用户的欢迎。

随着人们对阅读的需求增长，CHM愈加普及起来。

CHM的优点.CHM利用了ITS文件压缩格式，强大的压缩率大大减小文件
体积，方便Internet的传播。

CHM突破了电子文档打包的文件限制。

CHM格式不仅仅可以包含HTML文件，实际上它可以将任何文件编译到文件中。

另外，CHM强大的界面定制功能和内容包容能力。

我们可以预料到移动设备网络的发展最终将与Internet合并，PC和移动设备平台上的资源也将得以更大的共享互换。

由于CHM的种种优点，即使未来电子刊物得到了巨大发展，CHM也将继续成为主流电子书籍格式。

因此手机平台上的CHM解析就尤为重要。

1.3.研究现状
CHM阅读器的广泛.目前在各种PC主流操作系统平台上，如Linux, Ubuntu，Windows和Mac等都有CHM阅读器。

并且，在日益发展的移动设备操作系统平台上，如Windows Mobile、iPhone、Android和S60上也可以得到CHM的阅读器。

CHM格式的封闭.Microsoft html help workshop并未公布CHM具体的格式信息，目前CHM领域的研究者只有微软，相关资料非常稀缺。

本课题利用各种方式尝试探究CHM文件中格式各个部分的涵义。

解析性能的瓶颈.目前主要的CHM文件阅读器都是利用微软提供的htmlhelp.lib中的接口进行解析，或者利用hh.exe进行命令行反编译。

虽然接口简单方便使用，但性能较难得到改善。

本课题对CHM解析的各个过程进行分析，使之能在低劣的硬件环境下得到优良的性能。

1.4.主要思路
在分析CHM格式的基础上，针对CHM阅读的需要对CHM文件进行解析，并进行性能优化。

因为手机设备上的条件比较恶劣和苛刻，所以本课题主要关注于手机平台上的CHM解析器的开发。

●第2章将对CHM格式的各个部分进行全面的论述。

●第3章将对CHM阅读器的接口定义、系统设计原则、功能定义进行详
细的分析和定义。

●第4章将对CHM的解析流程进行分析，并针对进行性能优化和平衡。

2.微软帮助系统
2.1.帮助系统说明
帮助文档，是一个软件的基本部分。

我们用简单自然语言描述复杂的软件系统，帮助非开发人员理解程序是如何工作的，它们的兼容性和如何利用该软件达成期望的目标。

不同的帮助系统在平台和时间上差异很大。

Unix上的”man”说明页、GNU/Linux上的信息文件、MacOS上的帮助系统、针对各种属性软件的各种系统，直接HTML，跨平台帮助，自定义XML(例如DocBook)和微软家族操作系统的各代的帮助系统。

下面的表格显示了过去，现在及未来的微软帮助系统。

表2.2微软各代帮助系统
●Quick Help: 在微软的命令行时代使用。

●WinHelp:该版本有一些特性不在HTML帮助中出现。

注释，奇怪的压缩和
搜索，RTF格式和繁琐的UI。

●HTML Help: 微软目前的帮助系统，有许多功能在阅读器，编译器，界面工
具或三者结合中都尚未实现。

●MS Help 2：这本应该是HTML Help的最终版本，不过微软最终决定不发布
它，相反集中精力在Longhorn操作系统上的帮助系统。

●帮助和支持中心(HSC):为了整合所有的帮助到一个位置。

2.2.CHM帮助
目前这一代的微软帮助系统被称为HTML帮助，可能是因为它使用HTML 作为内容和其他文件的格式。

它在1997年8月被发布，并且和Win98和Win2000一起分发。

它使用IE浏览器的引擎，带有特别的ActiveX控件来为HTML网页提供额外的能力。

内容自包含的文件称为“编译的HTML帮助文件”（Compiled HTML Help files：CHM）。

HTML帮助阅读器(HTML Help viewer：HH)，编译器（HTML Help Compiler：HHC）和反编译器（例如：istorage）使用IStorage接口来访问虚拟文件系统中的文件。

虚拟文件系统将在后续章节讨论。

值得注意的是，大部分虚拟文件系统中文件被压缩成一个大的LZX（LZ77基础压缩器）。

界面制作工具被称为HTML Help Workshop (HHW)，它调用编译器(HHC)并载入一个dll(HHA)来完成工作。

HTML Help包含不少有用的功能，例如目录、索引、全文本搜索、书签。

2.3.CHM主要格式
本章节主要介绍CHM的主要格式。

当然，这些格式是过去许多人逆向工程所得到的信息。

由于微软并未公布详细的CHM格式信息，所以该论述的信息可能会有所偏差。

2.3.1.CHM格式概览
一个标准的CHM格式文件有CHM头、CHM头节和内容三部分组成。

CHM头部分主要提供CHM文件的基本信息、头节表信息以及内容块的偏移值。

在CHM文件的开始处是一个初始化头结构，该结构大小固定为0x38；紧接着初始化头之后的是头节表，描述头节部分中节的数目、大小和偏移值；在头节表之后，是0x08字节的内容偏移值，在某些CHM格式版本中肯在内容偏移之后会出现一些未知的信息数据，但极少出现，本文不讨论。

在当前CHM格式版本中，CHM头节部分仅有二个节组成，其中，节0提供CHM文件大小以及其他信息，此节一般用处不大；节1也称目录列表节，此节在CHM文件中非常重要，它将CHM文件内容中所包含的文件目录和索引信息进行组织管理，以便CHM浏览器分解内容时形成完整的目录结构，通过索引浏览器可以对内容信息进行检索。

其中索引信息可选择，如无索引信息浏览器将无法提供内容检索功能。

注意到一些CHM文件，有的可以检索，有的却不可以，原因就在于CHM目录节中是否提供索引块。

最后一部分是内容部分，顾名思义，内容部分存储的当然是CHM文件所包含的所有内容数据。

当前的CHM格式版本中，提供了两种内容数据存储方式，一种是未压缩方式，另一种是压缩方式，压缩算法一般采用微软的LZX算法。

内容块里面的特殊含义文件的格式说明将在后续章节“内容文件格式”里面进行阐述。

图2.3.2 CHM整体框架结构图
2.3.2.初始化头
初始化头位于CHM文件的最头部，包含一些CHM的相关信息。

表2.3.2 CHM初始化头结构
2.3.3.头节记录
紧接着是一个头节记录表，有2个记录，每个记录有0x10个大小。

表 2.3.3 头节记录表
这两个头节记录分别指向头节0和头节1。

根据这两个头节记录里的偏移值便可以读取到两个头节。

2.3.4.内容节偏移
该值占用8个字节。

在版本2的文件中，不存在该值，因为内容节直接紧跟着目录块。

2.3.5.头节0
这个头节只包含文件大小信息。

表2.3.5 头节0
2.3.6.头节1
这个头节是CHM文件的一个重要部分。

目录头的格式为：
表2.3.6.1：目录头结构
在目录头之后紧接着目录块，有两种目录块：列表块和索引块。

如果只有一个列表块，那么将没有索引块。

列表块的格式为：
表2.3.6.2 列表块结构
quickref区是从数据块的后面向前写，每隔n个项出现一个quickref，且n的值为1+(1<<“密度”)，其格式从后至前为：
第一个字：整个数据块中的项数
第二个字：从第0项到第n项之间的偏移量
第三个字：从第0项到第2n项之间的偏移量
以此类推。

目录列表的每一项的格式如下：
●ENCINT型名字长度
●UTF-8编码的名称
●ENCINT型正文段
●ENCINT型偏移量
ENCINT型长度
其中偏移量是从解压缩之后的正文段的开始来计算的，同样长度也是表示解压缩之后的长度。

在目录中存在两种文件，用户数据文件和格式信息文件，格式信息文件以两个连续的冒号“：：”开头，用户数据文件以“/”开头。

索引块的格式为：
表2.3.6.3 索引块结构
quickref的格式和排列与列表块中相同，当有索引块的层次较多时，将不再存储数据块号而是存储下一层的索引号。

每一个目录索引项的结构如下：
●ENCINT型的名称长度
●UFT-8编码的名称
●ENCINT型的以此名称开始的列表块的块号
ENCINT型变量的编码规则：
一种可变长度的整型变量，第一个字节只使用低7位，最高位为1表示该字节之后的下一字节的低7位要接在这7位的尾部组成一个数，这样通过移位相加的运算，直到遇到最高位为0的字节，可以组和成一个长度可调节的整数。

正文：
在版本3中，正文一般紧跟着文件头，而且在文件头表之后有一个双字用来指定其位置。

在版本2中，正文部分紧跟着文件头，而且所有此文件夹中的正文部分的第0段放在都放在这个位置上，其它的正文段都在这个正文段里面。

名称列表文件：
放在content section 0中，文件名为"::DataSpace/NameList"，其中包含着所有正文段的名称，其格式如下：
第一个字：以字计数的文件长度
第二个字：文件中的记录数
对于每一个记录格式为：
第一个字：以字计数的名字长度，不包括最后的NULL结尾符
后续字：双字节的字符。

以0表示所有entry的结束。

名称的编码类似于UFT-16。

段的名称目前为止只有两种，Uncompressed和MSCompressed,分别表示未压缩文件和Microsoft LZX压缩算法压缩的文件。

section data:
对于段号不为0的段，还有一个文件为::DataSpace/Storage/<Section Name>/Content，里面存放着该段的压缩信息，所以，当解析非0段时，需要两步工作，第一步，取得第0段并将其解圧，取得段名，第二步才能利用段名找到相应的段。

其余与格式相关的文件：
::DataSpace/Storage/<SectionName>/ControlData
共0x20个字节，存储关于压缩的信息：
表2.3.6.4 压缩控制数据
::DataSpace/Storage/<SectionName>/SpanInfo
存放着未解压的段的长度信息。

::DataSpace/Storage/<SectionName>/Transform/List
存放GUID列表用于解压缩
压缩段：
这一段用LZX压缩，要进行解压缩，先要读取:
::DataSpace/Storage/<SectionName>/Transform/{7FC28940-9D31-11D0-9B27-00A0
C91E9C7C}/InstanceData/ResetTable
其格式如下：
表2.3.6.5 ResetTable结构
2.4.内容文件格式
本章节将详细叙述各个内部文件的格式。

内容块里面的特殊文件包括：#SYSTEM，#IDXHDR，#WINDOWS，#STRINGS，#TOCIDX，#TOPICS，#URLSTR，#URLTBL，$FIftiMain。

这些文件和普通的用户文件（如html文件）混杂在一起。

2.4.1.#SYSTEM
这个文件以一个版本号开头。

它可能是2或者3，其他的值尚未找到。

该文件的全部内容为多项纪录。

每个记录的格式为：
表2.4.1.1 #SYSTEM 记录格式
编码涵义表：（注:HHP是
2.4.2.#WINDOWS
这个文件包含了CHM文件里的窗口类型的信息。

格式如下：
记录的结构是定义在htmlhelp.h里的HH_WINTYPE。

第一个字可以用来指定结构的不同版本。

所以在解析此文件时需要通过检查第一个字来确定结构的版本。

在下面的表中，参数n表示这是一个HHP文件定义好的窗口定义，或者是一个偏移。

表2.4.2.2 #WINDOWS 记录含义
窗口属性表：
2.4.
3.#STRINGS
这个文件是一个ANSI/UTF-8字符串列表。

每个字符串以一个空字符(‘\0’)结束。

所有字符串被划分成一个个4096字节大小的块。

如果一个字符串跨越块的尾部，则会被放弃并在原位置以0填补，目标字符串在下一个块重新开始。

字符串的顺序大概是："", [#WINDOWS] (参数0, 参数1, 参数7, 参数9, 参数2, 参数3, 参数4, 参数5, 参数6, 参数8),Contents_0_Entry_title, Index_0_Keyword, Contents_Image_file, Contents_Font, Contents_Default_frame, Contents_Default_window, [MERGE FILES](各个参数)。

2.4.4.#TOCIDX
如果CHM有一个非空的内容文件，且“二进制目录”打开，则会出现该文件。

该文件由一个个4096个字节的块组成，第一个块是头，头之后是以特定顺序排列的各种结构。

1.20/28字节的结构
2.DWORD
3.16字节的结构列表
头的格式为：
2.4.5.#TOPICS
指向此文件的偏移地址必须乘以16才是真正的偏移地址。

指向此文件里的索引可以转换成#URLTBL里的偏移。

如果不想读取#URLTBL文件，也可以直接用公式：
offset=(index%341)*12+index/341*4096
这个文件包含一些主题的信息，每一个记录的格式为：
2.4.6.#URLSTR
这个文件由一个个4096字节大小的块组成，如果最后一个块小于4096，则保持原样，空余的空间以空字符填充。

每个块的格式为：
●一个未知的字节。

●HHC里的多对“URL，FrameName”值：
2.4.7.#URLTBL
指向此文件里的索引可以转换成#TOPICS里的偏移。

如果不想读取#TOPICS 文件，也可以直接用公式：
index=(offset%4096+(offset/4096)*4096-4)/12
每4096个字节的格式为：
2.4.8.$FIftiMain
该文件保存了HTML帮助的全文本搜索信息，它避免了在搜索时再次深入到CHM内部文件去搜索关键字和短语。

显然，它加速了性能，因为保存的索引，
含有可以告诉我们关键字在哪个文件哪个位置的数据。

如果“全文本搜索”被关闭或者没有文件被索引，则该文件是空的。

CHM 编译器只会索引那些文件名里包含“.h”的文件。

关键字的储存和处理都是大小写不敏感的。

值得注意的是，关键字的最大长度为99个字符，否则会被跳过。

全文本搜索的数据以树状的形式组织。

首先开始是一个头部，大小是1024字节。

接着是索引节点，叶子节点和关键字位置节点(WLC)。

索引和叶子节点的大小是固定的，WLC的节点是可变的（在叶子节点里有该大小数据）。

WLC总是位于叶子节点的前面，叶子节点和索引节点交叉分布。

索引节点只指向子级的索引节点或者叶子节点。

一般来说，子级索引节点位于上级索引节点的直接前部。

该树状格式如下：
图2.4.8 $ FIftiMain结构
该文件使用两种不同的整数编码方式：“ENCINT”和“Scale and root method”。

Scale and root method:
该编码方式需要两个参数：s(scale)和r(root size)，在$ FIftiMain中，s通常是2，但是一般的值也是合法的。

一个整数被编码成两个部分，p（前缀）和q（实际位），p决定有多少个位需要存储，就像隐式地决定整数的高位一样。

开始编码时，p开始是一个0。

如果整数结束在r位，编码结束。

如果整数结束在r+1位，则向p扩展一个1然后
把整数的低r位保存在q里。

如果整数需要更多的位，则向q扩展一个位。

下面是一个例子（s=2，r=3）：
表2.4.8.1 Scale root 整数编码范例
CHM阅读器快速找出关键字位于哪个文件，应该遵循以下的流程：
1.读取头部
2.跳转到根索引节点
3.在根索引节点中比较关键字，如果大于关键字，则退出
4.定位到下一级别的索引节点
5.重复3，4步骤
6.在叶子节点中比较关键字
7.读取相应的WLC节点
8.抽取topic文件中的内容
9.确保无重复
10.从#URLTBL，#URLSTR，#TOPICS，#STRINGS中读取标题和路径
$ FIftiMain头部结构：
在每一个索引节点前面都有一个字用来表示节点之后空余空间的长度。

索引节点记录格式：
表2.4.8..3：$ FIftiMain索引节点记录格式
在每个叶子节点之前都一个较短的头节。

叶子节点格式：
WLC块的格式为：
表
2.5.网站地图格式
该文件的格式基于HTML：
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HEAD>标签包含一个<meta>标签指定了产生文件的名称：
<meta name="GENERATOR"content="Microsoft&reg; HTML Help Workshop 4.1">
<!-- Sitemap 1.0 -->
<BODY>标签包含一个<OBJECT>对象在<param>标签里储存文件的属性，后面是<UL>标签，里面的<LI>表面有个<OBJECT>标签储存内容和索引项。

<BODY>
<OBJECT type="text/site properties">
<param name="Property Name" value="Property Value">
…
</OBJECT>
<UL>
<LI> <OBJECT type="text/sitemap">
<param name="Property Name" value="Property Value">
…
</OBJECT>
…
</UL>
</BODY>
注意到属性名称和属性值是不区分大小写的，但一般HHW都是以大写来写入值的。

同时，里面的大部分标签也是大写的。

然而，<LI>标签是不关闭的，这为文档的解析增加了复杂性。

2.5.1.HHC格式
该文件保存目录栏的相关信息。

全局HHC属性：
全局属性里的信息类型：
HHC项属性：
2.5.2.HHK格式
这个文件保存索引栏的信息。

全局HHK属性：
全局属性里的信息类型：
HHC项属性：
3.系统总体设计
3.1.系统设计原则
该系统的最终目的是生成一个CHM解析器，为用户提供良好的CHM阅读体验，同时为其他需要CHM解析功能的软件提供高效的CHM解析内核。

目标平台：PC和手机移动设备
目标客户：普通用户和第三方软件
目标需求：提供阅读功能抽象，性能上可配置优化
核心功能：文件块式流式读取+性能优化
性能要求：在PC上流畅打开，在手机等小内存设备上占用尽量少的内存，同时阅读流畅。

3.2.系统总体要求
●简便性：解析功能和配置功能必须满足简便性，即解析的接口和配置的选项
必须简洁明了，不互相耦合依赖。

●独立性：CHM的解析过程中，针对各个模块的解析必须独立，即当解析某一
个模块时，不必必须解析另一个不必要的模块。

●快速性：操作响应的快速性，保证每项操作的相应时间是一定的，在忍受范
围之内的；对于一些常用的功能，必须保证响应的迅速；
●选择性：针对两种平台，应在提供同样接口的基础上，提供不同类型的实现。

3.3.系统总体框架
整个系统的前台和后台通过接口层层调用。

首先是底层对CHM文件以二进制读取的方式，其上是针对CHM文件读取特点进行封装的读取对象。

再上层是CHM解析器接口，同样的接口下面有两种实现方式：块式和流式分别针对PC 和手机平台的应用。

用户可以选择性能优化方式，平衡内存占用和算法效率指向的比率，达到最适合的阅读体验。

外部调用CHM解析器可以直接调用CHM解析器接口来获取一些基本信息，也可以让接口返回一个文件流对象来读取特定文
件的内容。

图3.3 CHM解析器框架
3.4.功能设计
以该内核在手机平台上阅读软件“熊猫看书”为例，项目主要为外层的调用提供以下功能：
1.打开关闭CHM文件，判断CHM文件的版本或格式是否符合规范。

用户也
可以传进一个解析配置对象来选择解析模式，是否支持索引等。

2.读取CHM的一些基本信息，如主页，标题，文件大小等。

3.得到一棵解析完整的目录树。

里面包含标题路径等信息。

当用户点击目录上
任一项时，可以得到该目录项的路径信息，把该路径传给CHM解析器接口即可以读取出相应的文件，从而显示出来。

4.读取文件，有两种方式。

一是接口直接返回一块大内存，里面存放该文件的
信息。

二是接口返回一个文件流对象，提供文件读取抽象。

当外部需要读取数据时，可以向读取普通文件一样读取，文件流对象内部采用“PULL”模式从CHM解析器中抽取所需的数据。

5.搜索关键字，用户可配置是否只支持搜索标题，或全字匹配。

搜索的结果是
得到一个列表，包含标题，关键字，文档偏移，路径等信息。

6.判定一个文件是否在CHM中存在。

3.5.接口设计
3.5.1.CHM解析器接口
图 3.5.1 CHM解析器接口
CHM解析器提供得到CHM基本信息、判断文件是否存在、读取文件、得到目录树、搜索关键字等功能。

3.5.2.CHM文件读取对象接口
图3.5.2 CHM文件读取对象接口
CHM文件读取对象提供读取文件记录、读取文件缓冲区到内存和字符串、读取一个字节、读取长整型、短整型、设定读取当前文件读取位置。

3.5.3.CHM文件流对象接口
图3.5.3 CHM文件流对象接口
CHM文件流对象提供读取文件记录、读取文件缓冲区到内存和字符串、读取一个字节、读取长整型、短整型、编码整型、判断是否到文件末尾和设定读取当前文件读取位置。

3.5.
4.LZX解压缩接口
struct LZXstate *LZXinit(int window);
void LZXteardown(struct LZXstate *pState);
int LZXreset(struct LZXstate *pState);。