现在流行的电子书有哪些格式的呢?
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。
在ｅ类出版物论坛的“图书制作、阅读工具区”对此有过讨论，需要的可以自己去看。
不过有一次我试着用过一个叫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。
在分析出目录结构后，我曾经想通过调试工具，分析文件加密算法，再反编译出具体的文件内容，但是很快我就发现那样干太累了，实在是得不偿失。
。收起
