CHM格式解析


CHM格式有一個初始化頭，占38H字節，后面是header section和到正文 段的偏移量。加在一起，這些被稱為文件頭。
header section一共有兩個section，一個是文件目錄，另一個包含著文件長度和一些未知信息。
初始化頭：
前 四個字節為ITSF,第二個雙字為版本信息，第三雙字是文件頭的總長度，第四雙字值為1，第五雙字是一個時間記錄，(第一個字節是MSB，第二個字節是 fractional seconds(second byte),第三個字節可并不確定，第四個字節僅能知道其符號位是確定的。)第六雙字是windows語言ID標識，后面16個字節是兩個連續的組ID， 分別為{7C01FD10-7BAA-11D0-9E0C-00A0-C922-E6EC}
和{7C01FD11-7BAA-11D0-9E0C-00A0-C922-E6EC}
后面是header section的表，其中有兩項，每項占16個字節，記錄著從文件頭開始的偏移量和section的長度，各占8個字節。
后面還有8個字節的信息，這些在版本2里是沒有的。
header section 0:
第一雙字：0x01fe
第三雙字為文件大小
共占5個雙字，其余雙字均為0
header section 1(directory header)
開始的四個字節為ITSP，
后面的雙字為版本號，
第三雙字為本section長度，
第四雙字信息未知，
第五雙字值為0x1000，是目錄塊的大小，
第六雙字是quickref section的“密度”，一般是2
第七雙字是索引樹的深度，1表示沒有索引，2表示有一層的PMGI數據塊。
第八雙字表示根索引的塊號，如果沒有索引為-1
第九雙字是第一個PMGL(listing)的塊號
第十雙字是最后一個PMGL的塊號
第十一雙字是-1
第十二雙字是目錄塊的塊數
第十三雙字是windows語言ID標識
從這里開始有16個字節的GUID{5D02926A-212E-11D0-9DF9-00A0C922E6EC}
然后四個雙字不知道是什么東西
本段共84個字節
從這里開始往后都是數據塊，分為兩種，一種是列表塊(listing chunks),一種是索引塊(index chunks)其中列表塊的格式如下：
開始是四個字節PMGL
然后的四個字節是目錄塊尾部的空白區的長度或是quickref區域的長度
第三雙字恒為0
第四雙字是前一個列表塊的塊號，如果這是第一個塊，該值為-1
第五雙字是后一個列表塊的塊號，如果這是最后一塊，該值為-1
從這里開始是目錄列表項，按文件名排序，并且大小寫不分
quickref區是從數據塊的后面向前寫，每隔n個項出現一個quickref，且n的值為1+(1<<“密度”)，其格式從后至前為
第一個字：整個數據塊中的項數
第二個字：從第0項到第n項之間的偏移量
第三個字：從第0項到第2n項之間的偏移量
以此類推
目錄列表的每一項的格式如下：
encint型名字長度，后面是UTF-8編碼的名稱，encint型正文段，encint型偏移量，encint型長度，其中偏移量是從解壓縮之后的正文段的開始來計算的，同樣長度也是表示解壓縮之后的長度。
在目錄中存在兩種文件，用戶數據文件和格式信息文件，格式信息文件以兩個連續的冒號“：：”開頭，用戶數據文件以“/”開頭。
索引塊：
前四個字節為PMGI
后面四個字節是塊尾部的quickref或是空白區的長度。
從這里開始是目錄索引項的開始，每一個目錄索引項的結構如下：
encint型的名稱長度，UFT-8編碼的名稱，以此名稱開始的列表塊的塊號。
quickref的格式和排列與列表塊中相同
當有索引塊的層次較多時，將不再存儲數據塊號而是存儲下一層的索引號。
解釋一下encint型變量的編碼規則：
一種可變長度的整型變量，第一個字節只使用低7位，最高位為1表示該字節之后的下一字節的低7位要接在這7位的尾部組成一個數，這樣通過移位相加的運算，直到遇到最高位為0的字節，可以組和成一個長度可調節的整數。
正文：在版本3中，正文一般緊跟著文件頭，而且在文件頭表之后有一個雙字用來指定其位置。在版本2中，正文部分緊跟著文件頭，而且所有此文件夾中的正文部分的第0段放在都放在這個益上，其它的正文段都within content section 0
名稱列表文件：
放在content section 0中，文件名為"::DataSpace/NameList"，其中包含著所有正文段的名稱，其格式如下：
第一個字：以字計數的文件長度
第二個字：文件中的entry數
對于每一個entry格式為：
第一個字：以字計數的名字長度，不包括最后的NULL結尾符
以word 0表示所有entry的結束。
名稱的編碼類似于UFT-16。
段的名稱目前為止只有兩種，Uncompressed和MSCompressed,分別表示自解釋文件和Microsoft LZX壓縮算法壓縮的文件。
section data:
對 于段號不為0的段，還有一個文件為::DataSpace/Storage/<Section Name>/Content，里面存放著該段的壓縮信息，所以，當解析非0段時，需要兩步工作，第一步，取得第0段并將其解圧，取得段名，第二步才 能利用段名找到相應的段
其余與格式相關的文件：
::DataSpace/Storage/<SectionName>/ControlData
共0x20個字節，存儲關于壓縮的信息
第一個雙字為在“LZXC”串后的雙字個數，在版本2中，此值必為6
第二個雙字為“LZXC”
第三個雙字為版本信息，必須大于2
第四個雙字為LZX reset interval
第五個雙字為窗口大小
第六個雙字為緩存大小
第七個雙字為0，未知信息。
::DataSpace/Storage/<SectionName>/SpanInfo
存放著未解壓的段的長度信息。
::DataSpace/Storage/<SectionName>/Transform/List
存放GUID列表用于解壓縮
壓縮段：
這 一段用LZX壓縮，要進行解壓縮，先要讀取::DataSpace/Storage/<SectionName>/Transform/ {7FC28940-9D31-11D0-9B27-00A0C91E9C7C}/InstanceData/ResetTable，其格式如下：
第一個雙字為2，估計是版本信息
第二個雙字是reset table中的entry數
第三個雙字是8，每一個entry的大小
第四個雙字是表頭長度
16個字節的壓縮前長度
16個字節的壓縮后長度
16個字節的0x8000 block size for locations below
16個字節的0
16個字節的第一個非壓縮數據塊的邊界在壓縮數據塊中的位置信息
注意:
There is one change from LZX as defined by Microsoft: After each LZX reset interval (defined in the ControlData file, but in practice equal to the window size) of compressed data is processed, the LZX state is fully reset, as if an entirely new file was being encoded. This allows semi-random access to the compressed data; you can start reading on any reset interval boundary using the reset interval size and the reset table.