现在流行的电子书有哪些格式的呢?
PDF格式是Adobe公司推出的一种跨平台电子文档格式,Adobe公司提供专用的文档浏览器,使用户可以在不同平台下获得相同的阅读效果。
其实Adobe公司提供的PDF编辑工具--Adobe Acrobat本身,就已经支持将PDF文件另存为RTF格式,因此我对PDF的反编译研究不多。 不过这个功能似乎受到“文档安全性”的限制,好在我google了一下,破解PDF安全保护的软件似乎不少。如果真的对批量转换有兴趣,在codeproject上也有一篇文章,提供将PDF转换成纯文本的源代码。
从我使用的情况看,Adobe Acrobat本身输出的RTF格式,对英文文档来说应该没有什么太大的问题...全部
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格式一样,在文字、图像边缘产生许多细小的碎片(高次杂波)。
CHM(发音为“chum”)的原意是Compiled HTML help file,是微软作为HLP格式(16位Windows下的标准帮助文件格式)的替代格式提出的,因此微软自己不仅随4。
01以上版本的IE一起提供免费的浏览器,而且免费提供制作工具Microsoft HTML Help Workshop。
CHM文件内部使用ITS格式,这是一种非常优秀的压缩格式,感觉压缩比要比zip、rar大。
EXE格式
除了CHM格式外,大量基于IE内核的电子书是以EXE格式提供的。制作EXE格式的电子书工具现在似乎已成为一个产业,养活了大批的程序员。虽然很多人认为这种格式的电子书很酷:一个文件就可以执行,界面也可以做得很漂亮,还可以带密码保护。
但是我个人对这种格式的电子书是最最痛恨的:除了前面说到的安全性、速度、空间、检索等问题外,我最心烦的一点是目前的EXE电子书都没有好用的书签功能,尤其是没有能够定位到页面中任意位置的书签功能,看长文档看到一半的时候被打断会很麻烦,所以自从MyReader实现了书签功能后,我就下定决心一定要解决反编译问题。
Web Compiler 1。67
这种格式的电子书,因为其制作工具在国内出现得比较早,而且有非常彻底的汉化解密版,所以曾经比较流行,E书时空提供的很多电子书都是这种格式。不过也正因为它的流行,导致想反编译它的人也多,引出了各种反编译工具,所以现在用的人似乎已经不多了。
反编译工具里,收费的就不去说它了,国内RMH和Fbilo还联合推出过免费的unwebcompiler,并且提供全套的Delphi源代码,有需要的到google或百度搜索一下unwebcompiler就有了。
不过可能国内大多数软件网站的管理员都不是开发人员出身,对源代码不感兴趣,所以收藏的都是212 KB的EXE,有源代码的不多,需要仔细找一下。
在unwebcompiler的源代码里,RMH和Fbilo对Web Compiler 1。
67生成的电子书的文件格式进行了详细描述,在这里我就不做无聊的重复,有兴趣就自己去看吧。我做的UnEBook也使用了他们提供的源代码,实现对Web Compiler 1。67生成的电子书的批量反编译,不过被我将代码从Delphi改成了C,似乎长度缩短了一些(原代码中有一段在字符串和十六进制数之间转换来、转换去,看起来比较怪异,被我省了),不过LHA解压缩部分改起来实在太麻烦,我直接在网上找了一段现成的C代码来用。
Caislabs eBook Pack Express 1。6
这个电子书制作工具也出过汉化版,所以在国内也有一定影响,不过这种影响似乎还没有大到足以使反编译工具满天飞的程度,嘿嘿……
在分析这种格式的电子书的时候,我没有使用任何反汇编工具,用UltraEdit32和系统监视工具就猜出来了:
文件标识:以十六进制串 00 F8 03 00 结尾。
这个似乎是一种惯例,差不多所有EXE格式的电子书都有自己特殊的文件结尾。
目录块起始地址指针:0003F81C
目录块中目录项结构:以0字符结尾的文件名+4字节起始地址,文件名起始字节为FF则目录块结束。
如果文件存放在子目录里,则文件名首字符:02=。。/,01:第一个00变成/,直到遇到02。
文件内容实际起始地址:目录项里的4字节起始地址+9
文件内容长度:目录项里4字节起始地址所指内容,DWORD。
在分析出目录结构后,我曾经想通过调试工具,分析文件加密算法,再反编译出具体的文件内容,但是很快我就发现那样干太累了,实在是得不偿失。
。收起