CHM格式分析及其优化毕业论文.doc

毕业设计(论文)设计论文题目：CHM格式分析及优化CHM格式分析及优化摘 要随着信息技术的发展，个人计算机越来越普及。人们也越来越多的利用计算机方便自己的生活。人们在计算机上阅读的需求也日益增长。其中CHM就是一种非常普及广泛的电子书籍格式。另一方面，随着个人掌上电脑，智能手机的发展，人们也花费更多的时间阅读电子书籍。但移动设备的处理能力离PC尚有较大的差距，因此如何快速有效的解析CHM格式电子书籍是移动设备上阅读软件的需求。本课题研究的目的在于为PC和移动设备平台提供CHM电子书籍的解析功能。在充分分析CHM格式规范的基础上，比较各种主流解析CHM方法，在CHM阅读器性能方面进行优化分析和处理。难点：该课题主要的难点在于如何分析CHM的格式的各个部分,特别是在无微软官方格式说明的情况下。如何兼容各种版本的CHM格式文件也是一项艰巨的任务。同时，对应于手机移动设备的特殊硬件条件，如何使程序占用极少的内存的同时以快速的方式解析文件，为用户提供流畅的阅读体验是本课题的重点。关键词：CHM，手机移动设备，解析The analysis and optimization on CHMAbstractWith 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 humans lives grows day by day, people will spend more time reading e-books. However, theres a huge gap between the processing power of mobile devices and PCs, so the solution about how to resolve CHM quickly and efficiently on mobile devices is the most need.The systems purpose is to provide the parsing CHM function for the PC and mobile device platform. Certainly, its based on a full analysis on the CHM format specification, comparing numbers of main CHM parsing methods. More work is attached on CHM parsers 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 subjects key point.Key words: CHM, mobile phone equipment, parse目录1.绪论11.1.研究背景11.2.研究意义11.3.研究现状21.4.主要思路22.微软帮助系统32.1.帮助系统说明32.2.CHM帮助42.3.CHM主要格式42.3.1.CHM格式概览52.3.2.初始化头62.3.3.头节记录62.3.4.内容节偏移72.3.5.头节072.3.6.头节172.4.内容文件格式102.4.1.#SYSTEM112.4.2.#WINDOWS122.4.3.#STRINGS132.4.4.#TOCIDX142.4.5.#TOPICS142.4.6.#URLSTR152.4.7.#URLTBL152.4.8.$FIftiMain152.5.网站地图格式192.5.1.HHC格式202.5.2.HHK格式213.系统总体设计233.1.系统设计原则233.2.系统总体要求233.3.系统总体框架233.4.功能设计243.5.接口设计253.5.1.CHM解析器接口253.5.2.CHM文件读取对象接口263.5.3.CHM文件流对象接口283.5.4.LZX解压缩接口293.6.数据结构设计303.6.1.目录树数据结构303.6.2.关键字搜索结果数据结构313.7.辅助功能设计323.7.1.反编译功能323.7.2.书签333.7.3.错误处理333.7.4.解析日志333.7.5.内存测量333.7.6.时间测量344.解析流程设计及优化354.1.基本解析流程354.2.详细解析流程364.2.1.CHM打开流程364.2.2.CHM读取文件流程374.2.3.CHM解析目录树流程394.2.4.CHM搜索关键字流程404.3.重要算法分析404.3.1.字符串查找算法404.3.2.目录解析算法454.4.性能优化策略474.4.1.流式解析474.4.2.文件缓存484.4.3.内容预读484.4.4.多线程解析484.4.5.文件流对象484.4.6.随机解压494.4.7.MAP索引目录494.4.8.写入临时文件504.4.9.解析配置505.运行环境515.1.硬件环境515.2.软件环境516.结论与展望526.1.结论526.2.展望52致谢53参考文献54附：本文所用图表汇总说明551. 绪论1.1. 研究背景目前电子书籍的阅读日益增长，而CHM作为一种主流的电子书籍格式，在各个平台将得到充分的支持。目前主流的电子书籍格式有：TXT,JAR,UMD,CHM,EXE，PDF。TXT纯文本的方式缺乏良好的阅读体验；JAR需要专门的JAVA支持；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、WAV、AVI）等等，并可以通过 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格式的封闭.Microsofthtmlhelpworkshop并未公布CHM具体的格式信息，目前CHM领域的研究者只有微软，相关资料非常稀缺。本课题利用各种方式尝试探究CHM文件中格式各个部分的涵义。解析性能的瓶颈.目前主要的CHM文件阅读器都是利用微软提供的htmlhelp.lib中的接口进行解析，或者利用hh.exe进行命令行反编译。虽然接口简单方便使用，但性能较难得到改善。本课题对CHM解析的各个过程进行分析，使之能在低劣的硬件环境下得到优良的性能。1.4. 主要思路在分析CHM格式的基础上，针对CHM阅读的需要对CHM文件进行解析，并进行性能优化。因为手机设备上的条件比较恶劣和苛刻，所以本课题主要关注于手机平台上的CHM解析器的开发。l 第2章将对CHM格式的各个部分进行全面的论述。l 第3章将对CHM阅读器的接口定义、系统设计原则、功能定义进行详细的分析和定义。l 第4章将对CHM的解析流程进行分析，并针对进行性能优化和平衡。2. 微软帮助系统2.2.1. 帮助系统说明帮助文档，是一个软件的基本部分。我们用简单自然语言描述复杂的软件系统，帮助非开发人员理解程序是如何工作的，它们的兼容性和如何利用该软件达成期望的目标。不同的帮助系统在平台和时间上差异很大。Unix上的”man”说明页、GNU/Linux上的信息文件、MacOS上的帮助系统、针对各种属性软件的各种系统，直接HTML，跨平台帮助，自定义XML(例如DocBook)和微软家族操作系统的各代的帮助系统。下面的表格显示了过去，现在及未来的微软帮助系统。表2.2微软各代帮助系统Quick HelpWin HelpHTML helpMS help 2Longhorn Help帮助支持中心(HSC)扩展名?hlp,cnt,gid,fts,ftg,hpj,ann,bmk, WinHlp32.BMKchm,chi,chq,chs,chw,its,col,hh.dat,hhcolreg.dat, hhp,hhc,hhk,hhs, stpHxS,HxI,HxC,HxF, HxT,HxK, HxE,HxV, HxA?基于?RTFHTMLHTML?操作系统MS DOSWin95Win98,WinXPVS.netNext. Windows Longhorn.Embrace&extend. WinXP反编译器?Helpdeco,winhelpcgi chmdeco,chmlib,chmtools,istorage,HHA/HHC/HHW, HHopen convert lit?编译器?HC30,HC31,HCP,HCRTF,HCW,MVC,MMVC,WMVCHHA/HHC/HHW, hxcomp?阅读器?WinHelp and MultiMedia Viewers, winhelp from wineHH,xCHM, arCHMage, msitskio slave,chmviewer,GnoCHM,chmseedox?格式规范?helpdeco docs, The Windows Help File FormatITSF formatITOLITLS format, convert lit source code?l Quick Help: 在微软的命令行时代使用。l WinHelp:该版本有一些特性不在HTML帮助中出现。注释，奇怪的压缩和搜索，RTF格式和繁琐的UI。l HTML Help: 微软目前的帮助系统，有许多功能在阅读器，编译器，界面工具或三者结合中都尚未实现。l MS Help 2：这本应该是HTML Help的最终版本，不过微软最终决定不发布它，相反集中精力在Longhorn操作系统上的帮助系统。l 帮助和支持中心(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格式信息，所以该论述的信息可能会有所偏差。..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初始化头结构0000char4“ITSF”0004DWORD3（版本号）0008DWORDCHM头长度000CDWORD1（未知）0010DWORD时间戳0014DWORD语言代码，英文：0x0409 简体中文：0x08040018GUID7C01FD10-7BAA-11D0-9E0C-00A0-C922-E6EC0028GUID7C01FD11-7BAA-11D0-9E0C-00A0-C922-E6EC2.3.3. 头节记录紧接着是一个头节记录表，有2个记录，每个记录有0x10个大小。表 2.3.3 头节记录表0000QWROD头节的偏移0008QWORD头节的长度这两个头节记录分别指向头节0和头节1。根据这两个头节记录里的偏移值便可以读取到两个头节。2.3.4. 内容节偏移该值占用8个字节。在版本2的文件中，不存在该值，因为内容节直接紧跟着目录块。表 2.3.4 内容节偏移0000QWORD内容节偏移2.3.5. 头节0这个头节只包含文件大小信息。表2.3.5 头节00000DWORD0x01FE(未知)0004DWORD0(未知)0008QWORD文件大小0010DWORD0(未知)0014DWORD0(未知)2.3.6. 头节1这个头节是CHM文件的一个重要部分。目录头的格式为：表：目录头结构0000char4“ITSP”0004DWORD1(版本号)0008DWORD目录头长度000CDWORD0x0a （未知）0010DWORD0x1000 （目录块大小）0014DWORD快速引用块密度，通常20018DWORD索引树深度，1：无索引，2：1层索引，以此类推。001CDWORD根索引块号。-1表示无所有0020DWORD首列表块号0024DWORD尾列表块号0028DWORD-1（未知）002CDWORD目录块个数0030DWORD语言ID0034GUID5D02926A-212E-11D0-9DF9-00A0C922E6EC0044DWORD0x54 (目录块大小，同0010)0048DWORD-1（未知）004CDWORD-1（未知）0050DWORD-1（未知）在目录头之后紧接着目录块，有两种目录块：列表块和索引块。如果只有一个列表块，那么将没有索引块。列表块的格式为：表 列表块结构0000char4“PMGL”0004DWORD空余空间长度0008DWORD0000CDWORD前一个列表块号0010DWORD后一个列表块号0014从这里开始是目录列表项，按文件名排序，并且大小写不分。quickref区是从数据块的后面向前写，每隔n个项出现一个quickref，且n的值为1+(1“密度”)，其格式从后至前为：第一个字：整个数据块中的项数第二个字：从第0项到第n项之间的偏移量第三个字：从第0项到第2n项之间的偏移量以此类推。目录列表的每一项的格式如下：l ENCINT型名字长度l UTF-8编码的名称l ENCINT型正文段l ENCINT型偏移量ENCINT型长度其中偏移量是从解压缩之后的正文段的开始来计算的，同样长度也是表示解压缩之后的长度。在目录中存在两种文件，用户数据文件和格式信息文件，格式信息文件以两个连续的冒号“：”开头，用户数据文件以“/”开头。索引块的格式为：表 索引块结构0000char4“PMGI”0004DWORD空余空间长度0008从这里开始是目录索引项quickref的格式和排列与列表块中相同，当有索引块的层次较多时，将不再存储数据块号而是存储下一层的索引号。每一个目录索引项的结构如下：l ENCINT型的名称长度l UFT-8编码的名称l 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/Content，里面存放着该段的压缩信息，所以，当解析非0段时，需要两步工作，第一步，取得第0段并将其解圧，取得段名，第二步才能利用段名找到相应的段。其余与格式相关的文件：:DataSpace/Storage/ControlData 共0x20个字节，存储关于压缩的信息：表 压缩控制数据0000DWORD在“LZXC”串后的双字个数，在版本2中，此值必为6。0004ASCII“LZXC”0008DWORD版本信息，必须不大于2000CDWORDLZX重置间隔大小0010DWORD窗口大小0014DWORD缓存大小0018DWORD0（未知）:DataSpace/Storage/SpanInfo 存放着未解压的段的长度信息。:DataSpace/Storage/Transform/List 存放GUID列表用于解压缩压缩段：这一段用LZX压缩，要进行解压缩，先要读取:DataSpace/Storage/Transform/7FC28940-9D31-11D0-9B27-00A0C91E9C7C/InstanceData/ResetTable其格式如下：表 ResetTable结构0000DWORD2（估计是版本信息）0004DWORD记录数0008DWORD8（每个记录大小）000CDWORD0x28（表头长度）0010QWORD压缩前长度0018QWORD压缩后长度0020QWORD0x8000（块大小）0028QWORD00030QWORD第一个非压缩数据块的边界在压缩数据块中的位置信息2.4. 内容文件格式本章节将详细叙述各个内部文件的格式。内容块里面的特殊文件包括：#SYSTEM，#IDXHDR，#WINDOWS，#STRINGS，#TOCIDX，#TOPICS，#URLSTR，#URLTBL，$FIftiMain。这些文件和普通的用户文件（如html文件）混杂在一起。...1. #SYSTEM这个文件以一个版本号开头。它可能是2或者3，其他的值尚未找到。该文件的全部内容为多项纪录。每个记录的格式为：表 #SYSTEM 记录格式0000WORD编码0002WORD数据长度0004BYTEs数据编码涵义表：（注:HHP是HTML 帮助工程文件）表： #SYSTEM编码涵义表0HHP文件中内容文件名1HHP文件中索引文件名2HHP文件中默认主题3HHP文件中标题4是一个结构：0x00DWORDHHP文件语言ID0x04DWORD如果使用DBCS则为10x08DWORD如果支持全文搜索则为10x0CDWORD如果有KLinks则非00x10DWORD如果有ALinks则非00x14QWORD时间戳0x1CDWORD0/1（未知0x20DWORD0（未知5HHP文件中的默认窗口6HHP文件中编译文件名，通常是CHM文件名。7如果二进制索引打开，则有该项，是个DWORD值。80x00DWORD0/4（未知）0x04DWORD#STRINGS文件中的偏移，缩写。0x08DWORD3如果第一个字是0，5如果它是4（未知）0x0CDWORD#STRINGS文件中的偏移，对缩写的解释。9编译器版本号。一般是：HHA Version 4.74.870210时间戳11如果二进制目录打开，则有该项，是个DWORD值。12信息类型的数目13和#IDXHDR包含相同的信息。14未知15信息类型检查和，算法和数据源未知16HHP文件的默认字体。2.4.2. #WINDOWS这个文件包含了CHM文件里的窗口类型的信息。格式如下：表 #WINDOWS 结构0x0000DWORD记录数0x0004DWORD记录大小(188或196)0x0008从这里开始是记录记录的结构是定义在htmlhelp.h里的HH_WINTYPE。第一个字可以用来指定结构的不同版本。所以在解析此文件时需要通过检查第一个字来确定结构的版本。在下面的表中，参数n表示这是一个HHP文件定义好的窗口定义，或者是一个偏移。表 #WINDOWS 记录含义0x00DWORD记录大小0x04DWORD0（未知）0x08DWORD参数0，#STRINGS偏移0x0CDWORD哪个窗口属性合法0x10DWORD参数100x14DWORD参数1，#STRINGS偏移0x18DWORD参数140x1CDWORD参数150x20RECT参数13，左上右下0x30DWORD参数160x34DWORD0（未知）0x38DWORD0（未知）0x3CDWORD0（未知）0x40DWORD0（未知）0x44DWORD0（未知）0x48DWORD0（未知）0x4CDWORD参数110x50BYTE160（未知）0x60DWORD参数2，#STRINGS偏移0x64DWORD参数3，#STRINGS偏移0x68DWORD参数4，#STRINGS偏移0x6CDWORD参数5，#STRINGS偏移0x70DWORD参数120x74DWORD参数170x78DWORD参数180x7CDWORD参数190x80DWORD参数200x84BYTE200（未知）0x98DWORD0（未知）0x9CDWORD参数7，#STRINGS偏移0xA0DWORD参数9，#STRINGS偏移0xA4DWORD参数6，#STRINGS偏移0xA8DWORD参数8，#STRINGS偏移0xACBYTE160（未知）0xBCDWORD0（未知）0xC0DWORD0（未知）窗口属性表：表 #WINDOWS 窗口属性表0x00000002导航栏风格0x00000004窗口风格标志0x00000008窗口扩展风格标志0x00000010初始化窗口位置0x00000020导航栏宽度0x00000040窗口显示状态0x00000080信息类型0x00000100按钮0x00000200导航栏初始化关闭状态0x00000400标签位置0x00000800标签次序0x00001000历史个数0x00002000默认面板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字节的结构表 #TOCIDX 20/28 结构0x00WORD0（未知）0x02WORD（未知）0x04DWORD（未知）0x08DWORD（未知）0x0CDWORD偏移指向上级书0x10DWORD偏移指向下一页0x14DWORD偏移指向第一个子书0x18DWORD0（未知）2. DWORD列表指向#TOPICS文件3. 16字节的结构列表表 #TOCIDX 16 结构0x00DWORD偏移指向第一个结构0x04DWORD一些序列号0x08DWORD偏移指向第二个结构0x0CDWORD#TOPICS里标题的偏移头的格式为：表 # TOCIDX头格式0x00DWORD4096（头长度）0x04DWORD偏移指向第3个结构0x08DWORD第3个结构的数量0x0CDWORD偏移指向第2个结构0x10BYTE40800（未知）2.4.5. #TOPICS指向此文件的偏移地址必须乘以16才是真正的偏移地址。指向此文件里的索引可以转换成#URLTBL里的偏移。如果不想读取#URLTBL文件，也可以直接用公式：offset=(index%341)*12+index/341*4096这个文件包含一些主题的信息，每一个记录的格式为：表2.4.5 #TOPICS 结构0x00DWORD指向#TOCIDX的偏移0x04DWORD指向#STRINGS里标题的偏移0x08DWORD指向#URLTBL的偏移0x0CWORD2：不在内容里 6：在内容里0x0EWORD0，2，4，8，10，12，16，32（未知）2.4.6. #URLSTR这个文件由一个个4096字节大小的块组成，如果最后一个块小于4096，则保持原样，空余的空间以空字符填充。每个块的格式为：l 一个未知的字节。l HHC里的多对“URL，FrameName”值：表2.4.6：#URLSTR 记录格式0x00DWORD该主题URL的偏移0x04DWORD该主题的FrameName0x08ANSI/UTF-8该主题的字符串2.4.7. #URLTBL指向此文件里的索引可以转换成#TOPICS里的偏移。如果不想读取#TOPICS文件，也可以直接用公式：index=(offset%4096+(offset/4096)*4096-4)/12每4096个字节的格式为：表 #URLTBL 块结构0DWORD3 341341个记录，每个12字节0xFFCDWORD4096(未知)每一个记录的格式为：表 #URLTBL 记录格式0x00DWORD(未知)0x04DWORD#TOPICS文件的索引0x08DWORD#URLSTR的偏移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）：表 Scale root 整数编码范例000001000120010701118100009100011010010151011116110000017110000118110001030110111031110111132111000000331110000013411100001062111011110631110111116411110000000CHM阅读器快速找出关键字位于哪个文件，应该遵循以下的流程：1. 读取头部2. 跳转到根索引节点3. 在根索引节点中比较关键字，如果大于关键字，则退出4. 定位到下一级别的索引节点5. 重复3，4步骤6. 在叶子节点中比较关键字7. 读取相应的WLC节点8. 抽取topic文件中的内容9. 确保无重复10. 从#URLTBL，#URLSTR，#TOPICS，#STRINGS中读取标题和路径$ FIftiMain头部结构：表：$ FIftiMain头部结构0x00BYTE40x00 0x00 0x28 0x00 （未知）0x04DWORDHTML文件数目0x08DWORD到叶子节点的偏移0x0CDWORD0（未知）0x10DWORD叶子节点数目0x14DWORD和0x08一样0x18WORD树的深度0x1ADWORD7（未知）0x1EBYTEWLC文档索引容量0x1FBYTEWLC文档索引根大小0x20BYTEWLC编码数量容量0x21BYTEWLC编码数量根大小0x22BYTEWLC位置节点容量0x23BYTEWLC位置节点根大小0x24BYTE100（未知）0x2EDWORD4096（节点大小）0x32DWORD0/1（未知）0x36DWORD最后一个关键字索引0x3ADWORD最后一个字符索引0x3EDWORD最大关键字长度0x42DWORD包含重复的关键字数量0x46DWORD不包含重复的关键字数量0x4ADWORD所有包含重复的关键字总长度0x4EDWORD比前一个值小0x52DWORD所有不包含重复的关键字总长度0x56DWORD尾部空余空间大小0x5ADWORD0（未知）0x5EDWORD比0x04小10x62BYTE240（未知）0x7ADWORDWindows代码页标识符0x7EDWORD语言ID0x82BYTE8940（未知）在每一个索引节点前面都有一个字用来表示节点之后空余空间的长度。索引节点记录格式：表：$ FIftiMain索引节点记录格式0BYTE比关键字长度大11BYTE字符在关键字中开始的位置2BYTEs0位置长度-1个字符+0DWORD偏移向最后一个包含此关键字的叶子节点+4WORD0（未知）在每个叶子节点之前都一个较短的头节。表：$ FIftiMain叶子节点头节格式0DWORD偏移到下一个叶子节点，如果是0则是最后一个节点。4WORD0（未知）6WORD当前叶子节点尾部空余空间长度叶子节点格式：表 $ FIftiMain 叶子节点格式0BYTE关键字长度+1，最大1001BYTE字符在关键字中开始的位置