常见电子书格式及其反编译思路分析第1/3页

声明：本文可能夹杂大量技术术语，如果您对此感到不快，请勿继续阅读。  
本文仅仅讨论一些思路，不会提供相关源代码，最多也只提供源代码网站的链接。如果您对此有所不满，请勿继续阅读。 
本文仅仅从技术角度讨论电子书反编译问题，请勿将之用于侵犯版权等等非法目的，或损害他人利益。如果您对此感到失望，请勿继续阅读。  
本文版权归作者所有，转载前请先征得作者书面同意。  
1. 前言 
2. 常见电子书格式及其反编译思路 
   2.1 PDF格式 
   2.2 基于IE内核的电子书 
       2.2.1 CHM格式 
       2.2.2 EXE格式 
             2.2.2.1 Web Compiler 1.67 
             2.2.2.2 Caislabs eBook Pack Express 1.6 
             2.2.2.3 通用反编译思路 
   2.3 HLP格式 
   2.4 小说网/小说世界（ebx/XReader） 
3. 结论 
附录 基于IE内核电子书的实现方式探讨

1. 前言 
本文所描述的电子书，指的是将原始的、可编辑的HTML、TXT、RTF、图像文件等，打包成一个独立的EXE，或其它只有专用浏览器才能读取的文件，打包后的文件通常不可用常规工具进行编辑、全文检索。

本文所描述的电子书反编译，指的是将电子书中的内容提取出来，还原或转换成标准的、可编辑的HTML、TXT、RTF及图像文件等。

就像世间其它事物一样，电子书编译器和反编译器的出现也都不是偶然的，都有其必然性。

在电子书编译器这一方来说，大概从有电子文档那天开始，就有人琢磨着要对电子文档打包了。我个人认为这主要是从以下几个方面进行考虑：

便于阅读、管理。当年在DOS下阅读文本文件，尤其是中文文件比较麻烦，因此出现了自带中文字库、自带基本浏览（翻页、滚动）功能的DOS电子书；由于需要在不同OS平台上获得相同的阅读效果，因此产生了跨平台的PDF格式电子书；随着互联网络的发展，大量信息以HTML格式出现，但是面对一大堆HTML文件，并不是每个人都知道该去双击index.htm或default.htm的，而且文件太多，管理也成问题，因此出现了CHM格式和各种基于IE内核的EXE格式电子书。  
便于保护知识产权、商业机密。这个问题的重要性相信大家现在都能理解了，不要说那些包含核心商业机密的东西，就算是区区一本小说，都会有些卑鄙小人把原始的HTML、TXT文件拿去加LOGO、打包，然后声称是自己“辛苦扫校的成果”，再堂而皇之地收取所谓“VIP费用”。因此PDF一直将文档安全性作为卖点之一，国内的各种独门格式电子书也以防反编译、防内容复制为首要目标。  
而反对将通用格式打包成独门格式的人，当然也有自己的道理：

便于全文检索。如前所述，电子书一般不可用通常的检索工具进行全文检索，这就为资料的有效利用设置了障碍。我个人认为，藏书量在几十本、上百本的时候，手工建立摘要、索引可能还可以接受；再多以后，我想要的就只是一个快速的全文检索工具，就好像在互联网环境下，对google的依赖一样。  
便于修改。俗话说：“金无足赤，人无完人”，电子书也是人做的，有时难免会出点什么错，或者因为资讯的发展，需要对原有内容加以修正、补充，这个时候如果面对的是一个不可编辑的EXE，您会有什么感想？  
节省时间和耐心。Windows在显示文件列表的时候，需要读取文件信息，EXE文件还要读取ICON等，如果装有反病毒软件，进入文件夹的时候，反病毒软件一般还会自动对文件夹中的EXE文件进行自动检查，而电子书大小一般都在MB级，因此打开包含EXE格式电子书的时候，感觉速度巨慢，比较令人反感。  
节省空间。一般EXE格式电子书的标准架构是：可执行体＋内容＋TOC。可执行体指的是电子书的执行代码部分，包括程序代码、插件代码、界面资源等。内容指的是电子书中真正包含的文本、图像内容，一般使用某种压缩、加密算法进行处理。TOC（Table Of Content）相当于目录索引，作用是加速对内容的访问。因此相对于直接用WinZip、WinRAR对原始内容进行压缩，每一本EXE格式的电子书都会浪费一部分磁盘空间，以存储执行体部分。电子书的软件界面越花哨，这种浪费一般也越大，我见过最夸张的电子书比原始内容足足多出 1 MB多的东西。  
避免垃圾。对于某些基于IE内核的电子书来说，由于实现技术的限制，可能会在注册表和系统目录下留下垃圾。  
安全。如果说如今的网络社会是一个充满恶意、毫无诚信的环境，可能有点夸张了，不过确实有人不知“做人要厚道”为何物。老实说，每次拿到一个来路不明的EXE格式的电子书的时候，我都在怀疑里面有没有什么木马、病毒，实在难受。  
便于平台转换，包括转换到手持设备。EXE格式的电子书看起来可能很爽，但是毕竟只能在Windows下看，如果想在其它系统下看，尤其是在手持设备上看，唯一的出路就是反编译了它。  
当然，在反编译后，也必须寻找合适的替代品，以继续满足原先的需要：

打包工具。建议选择Winzip或WinRAR，不仅使用方便，而且打包后文件也小，进入目录还快。  
阅读工具。现在可以不解包就直接阅读zip/rar文件内容的软件不少，一搜一大把，我自己都做过一个MyReader，不仅可以直接从ZIP/RAR中读取内容，还有自动定位index.htm、书签、现场保护、资源浏览器右键菜单扩展、zip/rar密码自动记忆等功能。  
全文检索工具。可以直接在zip/rar中全文检索的软件也有不少，我自己也做过一个FindStr，支持加密zip/rar，这个工具还可以与MyReader集成，搜索结果可以直接用MyReader直接打开，不需解包。另外它还支持批量文本替换，所以也经常被我用来整理下载到的或反编译出来的小说，包括去除广告链接、绝对URL改成相对URL等。  
对劳动成果的保护。这个直接用zip/rar的密码保护就好。  
2. 常见电子书格式及其反编译思路 
2.1 PDF格式 
PDF格式是Adobe公司推出的一种跨平台电子文档格式，Adobe公司提供专用的文档浏览器，使用户可以在不同平台下获得相同的阅读效果。

其实Adobe公司提供的PDF编辑工具－－Adobe Acrobat本身，就已经支持将PDF文件另存为RTF格式，因此我对PDF的反编译研究不多。不过这个功能似乎受到“文档安全性”的限制，好在我google了一下，破解PDF安全保护的软件似乎不少。如果真的对批量转换有兴趣，在codeproject上也有一篇文章，提供将PDF转换成纯文本的源代码。

从我使用的情况看，Adobe Acrobat本身输出的RTF格式，对英文文档来说应该没有什么太大的问题，顶多是格式有点变化，但是在输出中文文档的时候，偶尔会因为字符集代码错误，导致输出的文件在Word、写字板中打开的时候，只能看到一堆乱码。对于这种情况，手工替换一下字符集编码即可解决。

出现乱码还有一种可能就是PDF文件中使用了自定义的字库，导致转换出来后的文件无法正常显示，这个比较麻烦。PDF文件自带字库有两种方式：自带一种完整的字库，称为font embedding；只自带一种字库中要用到的那几个字符，称为font subsetting。在ｅ类出版物论坛的“图书制作、阅读工具区”对此有过讨论，需要的可以自己去看。

不过有一次我试着用过一个叫PDF2Html的软件，这个软件的思想是将PDF文件的每一页转换成一个JPG文件，然后将JPG文件封装到HTML文件里，加上目录、翻页按钮等，这样在网络浏览的时候，连客户端的Acrobat Reader及客户端字体支持都可以省了。这个软件的HTML文件模板做得怎样先不去说它，最令我奇怪的是，转换出来的图像格式只能是JPG，不能是PNG。其实对于有大片白色背景的页面来说，使用PNG格式不仅文件长度比JPG小，而且不会象JPG格式一样，在文字、图像边缘产生许多细小的碎片（高次杂波）。

2.2 基于IE内核的电子书 
随着互联网的发展，现在越来越多的网络文档内容是以HTML格式提供的，而微软本身又以控件的形式提供了IE浏览器的内核，可以很方便地被几乎所有Windows下的编程工具所调用，因此目前基于IE内核的电子书似乎占据了主流位置。

2.2.1 CHM格式 
CHM（发音为“chum”）的原意是Compiled HTML help file，是微软作为HLP格式（16位Windows下的标准帮助文件格式）的替代格式提出的，因此微软自己不仅随4.01以上版本的IE一起提供免费的浏览器，而且免费提供制作工具Microsoft HTML Help Workshop。

CHM文件内部使用ITS格式，这是一种非常优秀的压缩格式，感觉压缩比要比zip、rar大。

由于ITS格式的开放性，国外早就有人做出了CHM格式的独立编译、反编译工具，并且公开了全部源代码，需要的人可以到这里看：

http://bonedaddy.net/pabs3/hhm/

这个网站除了提供CHM编译、反编译工具及其源代码外，还提供CHM格式的详细说明，当然是英文的。我做的UnEBook在开始的时候，就使用了其中chmdeco的源代码，实现批量反编译CHM的功能。如果这个网站不幸登录不了，google一下chmdeco就好，有很多备份站点的。chmdeco内部使用的是chmlib的源代码，这份源代码很有名，除chmdeco外，chmtools用的也是它。

不过在使用了一段时间后，我发现这份代码在反编译某些CHM文件的时候，会出现数组越界错误。这种错误出现的概率虽然不大，但是出现后还是比较心烦，因此最终放弃了这份代码。

现在UnEBook使用的CHM反编译代码是从这里改出来的：

http://www.codeproject.com/winhelp/htmlhelp.asp

这份代码使用了微软未公开的ITS文件访问接口，直接对文件进行操作。由于使用的都是微软的东西，不仅目标码比较小，兼容性也好得多，目前还没有遇到反编译不出来的CHM文件（唯一的一次例外，是那个CHM文件本身就打不开），内存漏洞什么的也没有发现。看来微软的东西还是要由微软来对付，方为王道。

另外某些人制作CHM电子书的时候，为了省事，没有制作index.htm，而是单纯依赖左侧的目录树进行导航。对于这样的电子书，在反编译后，一般还需要根据生成的hcc文件，自动生成一个索引页，以免看的时候不方便。hcc文件结构大致如下：

多级目录通过<UL>控制，见到<UL>的时候往下走一级目录，</UL>往回走一级。  
目录项以<OBJECT type="text/sitemap">开始，以</OBJECT>结束。以<PARAM NAME="Name" VALUE="xxx">存放项名称，<PARAM NAME="Local" VALUE="xxx.html">存放项链接。  
某些目录项可能只有名称，没有链接。  
在UnEbook中，不仅能够根据hcc文件自动生成索引页，还能自动生成框架页，将索引页和显示页嵌入框架中，以最大限度模仿CHM中的目录效果。如果要完全模仿能够动态伸缩的树形目录效果，则需要增加图片、js、css等文件，实在得不偿失。

2.2.2 EXE格式

除了CHM格式外，大量基于IE内核的电子书是以EXE格式提供的。制作EXE格式的电子书工具现在似乎已成为一个产业，养活了大批的程序员。虽然很多人认为这种格式的电子书很酷：一个文件就可以执行，界面也可以做得很漂亮，还可以带密码保护。但是我个人对这种格式的电子书是最最痛恨的：除了前面说到的安全性、速度、空间、检索等问题外，我最心烦的一点是目前的EXE电子书都没有好用的书签功能，尤其是没有能够定位到页面中任意位置的书签功能，看长文档看到一半的时候被打断会很麻烦，所以自从MyReader实现了书签功能后，我就下定决心一定要解决反编译问题。

当前1/3页 123下一页阅读全文