有人能告诉我chm文件的格式资料在那里

谢谢答复。我是想了解chm文件的格式，开发相关软件。
我这里有一份资料
不过写的不全Microsoft's HTML Help (.chm) format
Preface
This is documentation on the .chm format used by Microsoft HTML Help. This format has been reverse engineered in the past, but as far as I know this is the first freely available documentation on it. One Usenet message indicates that these .chm files are actually IStorage files documented in the Microsoft Platform SDK. However, I have not been able to locate such documentation.
Note
The word "section" is badly overloaded in this document. Sorry about that.
All numbers are in hexadecimal unless otherwise indicated in the text. Except in tabular listings, this will be indicated by $ or 0x as appropriate. All values within the file are Intel byte order (little endian) unless indicated otherwise.
The overall format of a .chm file
The .chm file begins with a short ($38 byte) initial header. This is followed by the header section table, the offset to the content, and a number of bytes of information of unknown use. Collectively, this is the "header".
The header is followed by the header sections. There are two header sections. One header section is the file directory, the other contains the file length and some unknown data. Immediately following the header sections is the content.
The Header
The header starts with the initial header, which has the following format
0000: char[4]  'ITSF'
0004: DWORD    3 (probably a version number)
0008: DWORD    Total header length, including header section table and
               following data.
000C: DWORD    1 (unknown)
0010: DWORD    unknown; perhaps a checksum or CRC
0014: DWORD    unknown, usually $0409 but sometimes $0407
0018: GUID     {7C01FD10-7BAA-11D0-9E0C-00A0-C922-E6EC}
0028: GUID     {7C01FD11-7BAA-11D0-9E0C-00A0-C922-E6EC}
Note: a GUID is $10 bytes, arranged as 1 DWORD, 2 WORDs, and 8 BYTEs.
It is followed by the header section table, which is 2 entries, where each entry is $10 bytes long and has this format:
0000: DWORD    Offset of section from beginning of file
0004: DWORD    0 (unknown, but possibly high dword of above)
0008: DWORD    Length of section
000C: DWORD    0 (unknown, but possibly high dword of above)
Following the header section table is 8 bytes of additional header data.
0000: DWORD    Offset within file of content section 0
0004: DWORD    0 (unknown, but possibly high dword of above)
The Header Sections
Header Section 0
This section contains the total size of the file, and not much else
0000: DWORD    $01FE (unknown)
0004: DWORD    0 (unknown)
0008: DWORD    File Size
000C: DWORD    0 (possibly high DWORD of file size)
0010: DWORD    0 (unknown)
0014: DWORD    0 (unknown)
Header Section 1: The Directory Listing
The central part of the .chm file: A directory of the files and information it contains.
Directory header
The directory starts with a header; its format is as follows:
0000: char[4]  'ITSP'
0004: DWORD    1 (probably a version number)
0008: DWORD    Length of the directory header
000C: DWORD    $0a (unknown)
0010: DWORD    $1000    Directory chunk size
0014: DWORD    2 (unknown)
0018: DWORD    1 if there is no index, 2 if there is.  Possibly
               indicates number of distinct chunk types.
001C: DWORD    Chunk number of index chunk, -1 if there is none
               (though at least one file has 0 despite there being no
       index chunk, probably a 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    $0409 (unknown)
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
The header is directly followed by the directory chunks. There are two types of directory chunks -- index chunks, and listing chunks. The index chunk will be omitted if there is only one listing chunk. A listing chunk has the following format:
0000: char[4]  'PMGL'
0004: DWORD    Length of quickref area at end of directory chunk
0008: DWORD    Always 0.
000C: DWORD    Chunk number of previous listing chunk when reading
               directory in sequence (-1 if this is the first listing chunk)
0010: DWORD    Chunk number of next listing chunk when reading
               directory 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.
The quickref area is written backwards from the end of the chunk:
Chunklen-0002: WORD     Number of entries in the chunk
Chunklen-0004: WORD     Offset of entry 5 from entry 0
Chunklen-0008: WORD     Offset of entry 10 (decimal) from entry 0
Chunklen-000C: WORD     Offset of entry 15 (decimal) from entry 0
...
The format of a directory listing entry is as follows
      BYTE: length of name
      BYTEs: name  (possibly UTF-8)
      ENCINT: content section
      ENCINT: offset
      ENCINT: length
The offset is from the beginning of the content section the file is in, after the section has been decompressed (if appropriate). The length also refers to length of the file in the section after decompression.
There are two kinds of file represented in the directory: user data and format related files. The files which are format-related have names which begin with '::', the user data files have names which begin with "/".
The Index Chunk
An index chunk has the following format
0000: char[4]  'PMGI'
0004: DWORD    Length of quickref area at end of directory chunk
0008: Directory index entries (to quickref area)
The quickref area in an PMGI is the same as in an PMGL
The format of a directory index entry is as follows
      BYTE: length of name
      BYTEs: name  (possibly UTF-8)
      ENCINT: directory listing chunk which starts with name
Encoded Integers
An ENCINT is a variable-length integer. The high bit of each byte indicates "continued to the next byte". Bytes are stored most significant to least significant. So, for example, $EA $15 is (((0xEA&0x7F)<<7)|0x15) = 0x3515.
The Content
The content typically immediately follows the header sections, and is at the location indicated by the DWORD following the header section table. All content section 0 locations in the directory are relative to that point. The other content sections are stored WITHIN content section 0.
The Namelist file
There exists in content section 0 and in the directory a file called "::DataSpace/NameList". This file contains the names of all the content sections. The format is as follows:
0000: WORD     Length of file, in words
0002: WORD     Number of entries in fileEach entry:
0000: WORD     Length of name in words, excluding terminating null
0002: WORD     Double-byte characters
xxxx: WORD     0
Yes, the names have a length word AND are null terminated; sort of a belt-and-suspenders approach. The coding system is likely UTF-16 (little endian).
The section names seen so far are
· Uncompressed
· MSCompressed
"Uncompressed" is self-explanatory. The section "MSCompressed" is compressed with Microsoft's LZX algorithm.
The Section Data
For each section other than 0, there exists a file called '::DataSpace/Storage/<Section Name>/Content'. This file contains the compressed and/or encrypted data for the section. So, conceptually, getting a file from a nonzero section is a multi-step process. First you must get the content file from section 0. Then you decompress (if appropriate) the section. Then you get the desired file from your decompressed section.
Other section format-related files
There are several other files associated with the sections
· ::DataSpace/Storage/<SectionName>/ControlData
This file contains $20 bytes of information on the compression. The information is partially known:
0000: DWORD    6 (unknown)
0004: ASCII    'LZXC'  Compression type identifier
0008: DWORD    2 (Possibly numeric code for LZX)
000C: DWORD    The Huffman reset interval in $8000-byte blocks
0010: DWORD    The window size in $8000-byte blocks
0014: DWORD    unknown  (sometimes 2, sometimes 1, sometimes 0)
0018: DWORD    0 (unknown)
001C: DWORD    0 (unknown)
· ::DataSpace/Storage/<SectionName>/SpanInfo
This file contains a quadword containing the uncompressed length of the section.
· ::DataSpace/Storage/<SectionName>/Transform/List
It appears this file was intended to contain a list of GUIDs belonging to methods of decompressing (or otherwise transforming) the section. However, it actually contains only half of the string representation of a GUID, apparently because it was sized for characters but contains wide characters.
Appendix: The Compression
The compressed sections are compressed using LZX, a compression method Microsoft also uses for its cabinet files. To ensure this, check the second DWORD of compression info in the ControlData file for the section — it should be 'LZXC'. To decompress, first read the file "::DataSpace/Storage/<SectionName>/Transform/{7FC28940-9D31-11D0-9B27-00A0C91E9C7C}/InstanceData/ResetTable". This reset table has the following format
0000: DWORD    2     unknown (possibly a version number)
0004: DWORD    Number of entries in reset table
0008: DWORD    8     unknown
000C: DWORD    $28   Length of table header (area before table entries)
0010: DWORD    Uncompressed Length
0014: DWORD    0 (probably high DWORD of uncompressed length)
0018: DWORD    Compressed Length
001C: DWORD    0 (probably high DWORD of compressed length)
0020: DWORD    0x8000 block size for locations below
0024: DWORD    0 (possibly high DWORD of block size)
0028: DWORD    0 (zeroth entry of table)
002C: DWORD    0 (possibly high DWORD of zeroth entry of table)
0030: DWORD    location in compressed data of 1st block boundary in
               uncompressed data0034: DWORD    0 (probably high DWORD of above)Repeat to end of file
Now you can finally obtain the section (from its Content file). The window size for the LZX compression is 16 (decimal) on all the files seen so far. This is specified by the DWORD at $10 in the ControlData file (but note that DWORD gives the window size in 0x8000-byte blocks, not the LZX code for the window size)
There is one change from LZX as defined by Microsoft: After each Huffman reset interval (defined in the ControlData file, but in practice equal to the window size) of compressed data is processed, the decoder state is partially reset: that is, the Huffman length tables are cleared and the one-bit preprocessing header is reread. The LZ window is not cleared.
The rule that the input bit-stream is to be re-aligned to a 16-bit boundary after $8000 output characters have been processed IS in effect, despite this LZX not being part of a CAB file. The reset table tells you when this was done, though there seems to be no need for that during decompression; you can just keep track of the number of output characters. Furthermore, while this does not appear to be documented in the LZX format, the compressed stream is padded to an $8000 (decimal) byte boundary.

Copyright 2001 Matthew T. Russotto
You may freely copy and distribute unmodified copies of this file, or copies where the only modification is a change in line endings, padding after the html end tag, coding system, or any combination thereof. The original is in ASCII with Unix line endings.

调试易

有人能告诉我chm文件的格式资料在那里

解决方案 »