现在客户又要求支持CHM格式的电子书，没办法又要研究CHM。
CHM格式文件主要由3个部分组成，CHM初始化头、CHM头节点、内容。
The Header（CHM初始化头）
CHM初始化头部分主要提供CHM文件的基本信息、头节点信息等
0000:char[4] TISF
0004:DWORD 版本号
0008:DWORD 文件头的总长度，包括后面的节点表，v3版本是0x60，v2是0x58
000c:DWORD 1
0010:DWORD 时间戳
0014:DWORD windows语言ID
0018:GUID {7C01FD10-7BAA-11D0-9E0C-00A0-C922-E6EC}
0028:GUID {7C01FD11-7BAA-11D0-9E0C-00A0-C922-E6EC}
NOTE:GUID的字节顺序，判断时候容易搞错。
后面跟的是2个节点表，每个节点表的长度是16个字节。
0000:QWORD 节点的offset
0008:QWORD 节点的长度
V3版本在节点表后面还有8个字节
0000：QWORD 内容的偏移量
The Header Sections（头节点）
Header Section 0 （节点0）
节点0主要包含文件大小信息，还有一些其他的信息
0000: DWORD $01FE (unknown)
0004: DWORD 0 (unknown)
0008: QWORD File Size
0010: DWORD 0 (unknown)
0014: DWORD 0 (unknown)
Header Section 1：The Directory Listing（目录列表）
这是整个CHM文件最重要的部分，它包括了文件的目录和信息
Directory Header
目录列表最开始是目录头信息，它的格式如下：
0000: char[4] 'ITSP'
0004: DWORD Version number 1
0008: DWORD Length of the directory header
000C: DWORD $0a (unknown)
0010: DWORD $1000 Directory chunk size
0014: DWORD "Density" of quickref section, usually 2.
0018: DWORD Depth of the index tree 1 there is no index, 2 if there is one level of PMGIchunks.
001C: DWORD Chunk number of root index chunk, -1 if there is none（虽然有的文件没有index chunk，但是这里不是-1而是0，大概是个bug）
0020: DWORD Chunk number of first PMGL (listing) chunk
0024: DWORD Chunk number of last PMGL (listing) chunk
0028: DWORD -1 (unknown)
002C: DWORD Number of directory chunks (total)
0030: DWORD Windows language ID
0034: GUID {5D02926A-212E-11D0-9DF9-00A0C922E6EC}
0044: DWORD $54 (This is the length again)
0048: DWORD -1 (unknown)
004C: DWORD -1 (unknown)
0050: DWORD -1 (unknown)
The Listing Chunks
目录头后面紧跟的就是目录块，有2种目录块，一种是Listing chunks，一种是Index chunks。如果chm文件只有一个Listing chunk，那么Index chunk就被省略掉。每个Listing chunk的结构如下：
0000: char[4] 'PMGL'
0004: DWORD Length of free space and/or quickref area at end of directory chunk（一般chunk的大小是固定的，所以后面还有一些填充和用于快速查找条目的数据）
0008: DWORD Always 0.
000C: DWORD Chunk number of previous listing chunk when readingdirectory in sequence (-1 if this is the first listing chunk)
0010: DWORD Chunk number of next listing chunk when readingdirectory in sequence (-1 if this is the last listing chunk)
0014: Directory listing entries (to quickref area) Sorted by filename; the sort is case-insensitive.（从0×14开始，就是按照文件名顺序排序的目录条目）
Listing chunk最后的是快速定位区域，其中密度的计算方法是n = 1+(1<<Density),这个Density就是Dircetroy Heaer中Density区域的值。
从chunk尾开始读取的数据顺序为：
Chunklen-0002: WORD Number of entries in the chunk
Chunklen-0004: WORD Offset of entry n from entry 0
Chunklen-0006: WORD Offset of entry 2n from entry 0
Chunklen-0008: WORD Offset of entry 3n from entry 0
以此类推
总的个数就是 (entry的总个数)/密度n。
Directory listing entry的结构如下：
ENCINT: length of name
BYTEs: name (UTF-8 encoded)
ENCINT: content section
ENCINT: offset
ENCINT: length
其中偏移量是从解压缩之后的正文段的开始来计算的，同样长度也是表示解压缩之后的长度。
在目录中存在两种文件，用户数据文件和格式信息文件，格式信息文件以两个连续的冒号“：：”开头，用户数据文件以“/”开头。
The Index Chunk（索引块）
索引块的格式如下：
0000: char[4] 'PMGI'
0004: DWORD Length of quickref/free area at end of directory chunk
0008: Directory index entries (to quickref/free area)
quickref的格式和排列与列表块中相同。
每一个目录索引项的结构如下：
ENCINT: length of name
BYTEs: name (UTF-8 encoded)
ENCINT: directory listing chunk which starts with name
当有索引块的层次较多时，将不再存储数据块号而是存储下一层的索引号。
解释一下encint型变量的编码规则：
一种可变长度的整型变量，第一个字节只使用低7位，最高位为1表示该字节之后的下一字节的低7位要接在这7位的尾部组成一个数，这样通过移位相加的运算，直到遇到最高位为0的字节，可以组和成一个长度可调节的整数。
The Content（正文）
在版本3中，正文一般紧跟着文件头，而且在文件头表之后有一个双字用来指定其位置。在版本2中，正文部分紧跟着文件头。所有第0段正文内容在目录中的位置都是相对那点来说的，其它的正文段都在content section 0中。
The Namelist file（名称列表文件）
名称列表文件是在content section 0中，并且在目录块中的文件名为”::DataSpace/NameList”。它其中包含着所有正文段的名称，其格式如下：
0000：WORD 以字（2个字节）计数的文件长度
0002：WORD 文件中的entry数
对于每一个entry格式为：
0000：WORD 以字(2个字节)计数的名字长度，不包括最后的NULL结尾符
0002：WORD 以word 0表示所有entry的结束。
xxxx：WORD 字0
名称的编码类似于UFT-16，小端存放，是以0为结尾。
段的名称目前为止只有两种，Uncompressed和MSCompressed。
Uncompressed段表示自解释文件，一般都没有压缩。
MSCompressed段表示Microsoft LZX压缩算法压缩的文件，这个段是主要的内容。
The Section Data（段数据）
对于段号不为0的段，还有一个文件为::DataSpace/Storage/
/Content，里面存放着该段的压缩信息，所以，当解析
非0段时，需要两步工作，第一步，通过段0的The Namelist file取得段名，才能利用段名找到相应的段，第二步，就是解压段信息，获取到想得到的数据。
Other section format-related files（其余与格式相关的文件）
还有一些与段有关的文件。
::DataSpace/Storage//ControlData
共0×20个字节，存储关于压缩的信息
0000：DWORD 在“LZXC”串后的双字个数，在版本2中，此值必为6
0004：DWORD ASCII第二个双字为“LZXC”
0008：DWORD 版本信息，必须大于2
000C：DWORD 为LZX reset interval
0010：DWORD 为窗口大小.
0014：DWORD 为缓存大小
0018：DWORD 0，未知信息。
001C：DWORD 0，未知信息。
其中在版本1中，reset interval、窗口大小、缓存大小是以字节计数的，在版本2中，是以8000字节为单位计数的。
::DataSpace/Storage//SpanInfo)
由一个QW存放着未解压的段的长度信息。
::DataSpace/Storage//Transform/List
本来是存放GUID列表用于解压缩段数据的，但是只存了每个GUID的一半。似乎是存储GUID字符串的长度是以字符算的，实际存储是以unicode双字来存的。
Appendix: The Compression（压缩说明）
压缩段一般都是用LZX压缩，这个压缩算法是微软经常用的。要确定是否是使用这种压缩方式，可以先读取先要读ControlData文件（就是上面讲的）。要解压数据首先要读取::DataSpace/Storage//Transform/
{7FC28940-9D31-11D0-9B27-00A0C91E9C7C}/InstanceData/ResetTable文件，其格式如下：
0000：DWORD 版本信息
0004：DWORD reset table中的entry数
0008：DWORD 8，每一个entry的大小
000C：DWORD 表头长度
0010：QWORD 压缩前长度
0018：QWORD 压缩后长度
0020：QWORD 块大小，一般是0x8000
0028：QWORD 第0个压缩块在内容中的偏移
0030：QWORD 第一个压缩数据块边界在内容中偏移
...以此内推
CHM文件解析流程和显示设计
通过上面的讲述，我们已经知道了CHM格式的解析，现在我们可以开始进行解析的代码设计了。
- 从文件0偏移开始解析The Header信息，获取The Header Sections位置信息。
- 解析Header Sections头信息，得到The Listing Chunks信息和The Index Chunk信息。
- 通过The Listing Chunks获取到Directory listing entry信息。
- 首先获取到::DataSpace/NameList信息，得到content sections的名字。一般都是Uncompressed和MSCompressed两个content sections。
- 通过::DataSpace/Storage/<SectionName>/SpanInfo、::DataSpace/Storage/<SectionName>/ControlData和::DataSpace/Storage/<SectionName>/Transform/List得到content section的相关信息。
- 通过the listing chunk得到.hhc文件，这个文件是chm格式的TOC文件，可以得到目录信息，通过目录信息，得到各个文件名，再通过文件名和the listing chunk就可以得到各个文件在content section的位置。
- 通过文件在content section中的偏移、reset_lzx_table和LZX control的信息，解压缩conten section得到文件的真正数据。
- 解压缩后得到的信息是HTML格式的，所以最后还要解码HTML信息，显示文件。对了，其中还有一些css文件，这些文件对应着HTML文件的排版，这些也是需要解压缩得到的。
最后还是代码实现了，计划找个时间做个android版的CHM阅读器。
