阿里大盗的日记

    linux下看chm的文档，我最喜欢的就是kchmviewer。但是kchmviewer版本到了4.0之后我就发现了一个bug：看python的文档时，index显示总是不全（python文档的index特别的长，kchmviewer显示时大概能显示到字母n的样子就没了）。我曾发信给作者报过这个bug，但似乎半年过去也没回音。我曾一度想用python重新实现一遍该程序，昨天终于付之行动。但经过简单的试验之后，很快我就放弃了：只实现简单的阅读还比较容易，但是要把功能做得向kchmviewer一样全一样好，工作量就有点太大了。相比之下还是直接改kchmviewer的源码较为简单，并且这样也比用python写的程序在速度和内存使用上更有优势。
    调试了一夜，终于解决了这个问题。问题出在函数bool LCHMFile::parseIndex( QVector< LCHMParsedEntry > * indexes ) const (在文件libchmfile.cpp中)，问题代码如下：
return m_impl->parseBinaryIndex( indexes )
	|| m_impl->parseFileAndFillArray( m_impl->m_indexFile, indexes, true );
改为：
return m_impl->parseFileAndFillArray( m_impl->m_indexFile, indexes, true )
||m_impl->parseBinaryIndex( indexes );
就好了。
产生这个问题的原因，我认为是这样：
在解析index时，程序总是先试图使用函数parseFileAndFillArray，该函数会试图读取位于/$WWKeywordLinks/BTree的index信息，该处所记录的信息为二进制格式的，与/index.hhk（这里说明一下，去除/$WWKeywordLinks/BTree外，程序首选的index信息读取处也不是/index.hhk，程序会先尝试在/#WINDOWS处找，看有没有记录index信息放在了哪，如果没有才会再去/index.hhk读）等处的index信息相比，后者为类似xml格式的信息，显然程序解析前者速度会更快。但问题正是出在了这里！
我使用pychmlib包（该包是对chm_lib包的一个python封装，kchmviewer解析chm文件也是靠的chm_lib包）写python程序读取了几个chm文件(python254.chm、python261.chm、python30.chm，对我来说用处较大的几个文件)/$WWKeywordLinks/BTree的index信息，发现这些index信息都不完整。这就导致了kchmviewer显示index信息不全。事实上，如果把几个测试用的chm文件放到windows下，用hh.exe(就是windows下默认看chm的程序)打开来看，index显示是正常的。这样看来hh.exe对取index信息也是读取/index.hhk等处的信息，而不是读取/$WWKeywordLinks/BTree处的二进制信息。chm这种格式毕竟是微软搞出来的，还是和它保持一样比较好。并且，改成解析/index.hhk等处的信息也并不会慢多少，至少我没有感觉出来。