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

脚本专栏 发布日期:2024/12/25 浏览次数:1

正在浏览:常见电子书格式及其反编译思路分析第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。在e类出版物论坛的“图书制作、阅读工具区”对此有过讨论,需要的可以自己去看。 

不过有一次我试着用过一个叫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实现了书签功能后,我就下定决心一定要解决反编译问题。 
123下一页阅读全文