word导出pdf后乱码-复制pdf格式文件里的文字粘贴到Word文挡时显示的是...

它们之间的转换最牛逼的方式是先打印出来 再扫描进去。呵呵不扯瞎话了，它们，转换可用下面的工具来实现：
solid converter pdf

应用情景：利用office 2003中的microsoft office document imaging组件来实现pdf转word文档在一定程度上的确可以实现pdf文档到word文档的转换，但是对于很多“不规则”的pdf文档来说，利用上面的方法转换出来的word文档中常常是乱码一片。为了恢复pdf的原貌，推荐的这种软件可以很好地实现版式的完全保留，无需调整，而且可以调整成需要的样板形式。

使用方法：

1、下载安装文件solid converter pdf,点击安装。

提示：安装前有个下载安装插件的过程，因此需要保证网络连接通畅。

2、运行软件，按工具栏要求选择需要转换的pdf文档，点击右下的“转换”（convert）按扭，选择自己需要的版式，根据提示完成转换。

下载地址： http://www.skycn.com/soft/20929.html

比较简单的办法是将图像中的文字识别出来，然后就可以用翻译软件读取了。

你可以这样去做：
一、将pdf文件中的各页图像提取出来
1）使用adobe acrobat软件
2）在上面菜单上选文件>导出>提取图像为>jpeg文件（其他二种也行，jpeg文件比较小）
3）按提示，选择一个适当的文件夹，保存图像
二、安装一个文字识别（ocr）软件用来识别已提取的图像
本人推荐汉王文本王。理由：
1）识别率高，可识别英文、表格等
2）可以直接输出成word文件
三、保存为word文件

一.如果不能打开，可这样恢复文件关联：
1、开始运行，输入：regsvr32 c:\windows\system32\hhctrl.ocx ，确定，重新关联文件。
2、执行一下windows目录里的hh.exe 。
有时候chm文件放在中文目录就不行。包括中文chm名字。试着把文件考出来.中文名字一改.

二.1.在微软网站上下载hhupd.exe,安装hh.exe后并运行。
2.实际上,下载hhupd.exe后,运行后就可以了。这个东西大小为461kb 3.在c:\windows\system32里找到“hhctrl.ocx”文件,然后运行:“regsvr32“c:\windows\system32\hhctrl.ocx...
网上的解决方法不可行，下载不了hhupd.exe.我直接执行regsvr32 c:\windows\system32\hhctrl.ocx就ok了。

解决方法2是：
1，右键关联chm文件的“打开方式”到\windows\hh.exe
2，在命令行运行regsvr32 itss.dll
3，在命令行运行regsvr32 hhctrl.ocx

三.也许是 hh.exe 所必需的某个组件出了问题。但是不知道 hh.exe 会用到些什么组件，所以上网查了一下，有人建议重新注册 hhctrl.ocx。我在系统目录下找到了 hhctrl.ocx，重新注册一下 hhctrl.ocx 试试：regsvr32 hhctrl.ocx。依然不能正常阅读 chm。

既然如此，很有可能是协议出了问题。hh.exe 用的是 ms-its 等协议，这些协议应该是由某个 dll 文件提供服务的。问题是，是什么 dll 呢？于是再用 google 搜索 ms-its 协议。终于找到了，原来是一个 itss.dll 在做服务。不过网上查到的解决方案是修改注册表。

要修改 itssrestrictions 注册表项以启用特定的安全区域，请按照下列步骤操作：
1. 单击“开始”，单击“运行”，键入 regedit，然后单击“确定”。
2. 找到并单击下面的子项：
hkey_local_machine\software\microsoft\htmlhelp\1.x\itssrestrictions
注意：如果该注册表子项不存在，则使用方法 1 中的步骤 2a 和 2b 创建该子项。
3. 右键单击“itssrestrictions”子项，指向“新建”，然后单击“dword 值”。
4. 键入 maxallowedzone，然后按 enter 键。
5. 右键单击“maxallowedzone”值，然后单击“修改”。
6. 在“数值数据”框中，键入 0 至 4 之间的一个数字，然后单击“确定”。
7. 退出注册表编辑器。
注意：默认情况下，“maxallowedzone”值设置为 0。下表摘要列出了“maxallowedzone”值对各个项的解释。 maxallowedzone 本地计算机区域 本地 intranet 区域 受信任的站点区域 internet 区域 受限站点区域
0 允许 阻止 阻止 阻止 阻止
1 允许 允许 阻止 阻止 阻止
2 允许 允许 允许 阻止 阻止
3 允许 允许 允许 允许 阻止
4 允许 允许 允许 允许 允许

注册表修改之后还是不能打开！
试试偷懒的办法吧――重新注册dll：regsvr32 itss.dll。

四.操作系统的语言不是中文（经常出现这种情况）
1.看看你的 os 是不是中文的 os ？ 如果你的 os 不是 中文的，那么到 control pane 中看看那个“语言和区域” 的option， 打开看看“区域选项” 是不是中国，这个选项对一些软件还是有一些影像的。
2.如果你的chm文件是中文的，可能存在缺省语言设置问题。可能你用是的英文版的windows，把ragional and language options中的language 和advanced 中的 语言和国家选项都设置成中文（prc）。就可以了

五.可以试试改变此文件的名字.比如去掉多余的符号

六.如果都不能，最后一招就是，把电子书chm格式转换为pdf文件：
chm converter是一个专门转换chm格式的文件，它可以把chm文件转换成pdf、txt、doc等常用的格式。
http://dl.pconline.com.cn/html/1/6/dlid=11896&dltypeid=1&pn=0&.html

下载后运行软件，软件默认是英文界面，点击菜单“tools-language”，在弹出的对话框中选择“chinese_simplified”就可以换成中文了，软件还支持其他很多语言。

选好语言后点击左上角的“打开”按钮来选择要转换的chm文件，如果chm文件是英文版的，那么在旁边的下拉菜单中就选择 “defailt_charset”，如果是中文的，那需要在下拉菜单中选择“gb2312_charset”，否则会产生乱码，然后在右面的“导出”中来选择要转换的文件类型，软件支持很多格式的文件，如这里选择“word97-2003”，最后点击“另存数据库为”按钮，选择保存的文件夹后就开始进行转换了。

ps: window2k中不能打开*.chm文件的解决办法
这个问题的发生，是由于hhctrl.ocx的版本号出现错误或未正确注册。原因在于安装的其他软件用hhctrl.ocx的旧版本替换了原来的版本。
ie6sp1中，这个文件的版本号应为5.2.3735.0。可以看看你的系统这个文件的版本号。
位于winnt/system32这个文件夹。大小504k（英文版本）从其他相同的系统（ie版本也相同）中copy一份
粘贴到你的系统相应文件夹中。然后注册一下。

注意：
1、先替换winnt/system32/dllcache文件夹的这个文件
后替换winnt/system32文件夹里的这个文件
2、如果看不到这个文件，
先工具--文件夹选项中，设置显示隐藏文件
并设置显示系统文件
3、注册的方法是
开始--运行，输入regsvr32 hhctrl.ocx
之后出来一个注册成功的对话框，确定然后重启系统。

一本e书过于臃肿，造成的原因有多种。观上交的作业，有几百k到2、3m不等，由于这次作业内容是统一的，很容易对比出问题，也有问到如何“减肥”，由于各人的表现手法不尽相同，纵观这次存在的，结合以前有过的，不外几种典型类型，总结了一下，希望对你有所帮助。

一、图片

一般装饰图：包括封面图、题头图、背景图以及用于美化的其他图片，不要使用bmp位图，可用jpg或gif格式，背景常用带循环图案的小尺寸图，尽量避免多帧gif（动画），曾经看到过有会员为了追求特定效果而用800×600甚至更大幅的单图作为背景，只能以牺牲“体重”为代价。如果用制图软件编辑过某张图片，注意在导出时有压缩率和清晰度选项，两者成反比，越往上图片会成倍增大，甚至超出原有很多，而此时清晰度的增加并不明显，一般达到70％以上就可以了。

闪屏图：很多会员喜欢用闪屏。大家知道，不管用eep还是ews，所支持的格式只能是bmp，而这种格式在常见几种图片类型中压缩率是最小的，如果尺寸小点，影响还不大，只怕图片做得过大，以前见过一本书，打开时满屏显示，开始还以为是本翻页书，“闪”过后才知道只是欢迎画面，一张800×600的bmp可以达到1.4m左右，如果书的主要内容部分以k计算，不免有点喧宾夺主了。个人信息或声明可以在“关于”中说明，或者多做一个网页也可以，不是非常重要时，不推荐用闪屏。

二、音效

一本精美的书中，加入一段适合内容的动听音乐，可以渲染气氛。但要注意的是，对于看书而言，音乐毕竟是配角，不必追求过高音质，一个mp3文件小则3、4m，大点6、7m甚至更大，而且在配置不高的机器上载入过大的单个文件时还会使e书打开的很慢，所以除非迫不得已（有些英语类的有声e书），用一个几k的midi足矣。

三、网页本身

如果说图片、音乐等都是配角，那么对于文字类的书籍来说网页对“减肥”起着决定性的作用。但是这个因素反而容易被忽略。多数会员都用软件做网页，而软件制作出来的网页往往带有很多垃圾代码和无效代码，比如代码中带有制作软件本身的信息，这些信息对于书的内容来说毫无意义，也不会在页面中反映出来，可以删除；有些对网页元素设置的尺寸、位置属性代码，如一张图片1：1显示，限制宽、高的代码就成多余；需要一个单元格中的元素对左显示，就没有必要加上对左代码，因为浏览器默认不加限制的都对左。所以说要想让网页“减肥”，过后要对软件制作的网页加以修改。这点对于新手来说有难度，可以不做，但当你对源代码达到一定熟悉程度后，必须要做。下面这个附件中的两个文件，一个是学员用软件直接做的《抗战史》目录页，另一个是在此基础上修改过的，大家可以比较一下，页面效果基本一样，但是文件从19.8k减小到了1.66k，这不是单个网页减小十几k的问题，而是当一本书存在几十上百或更多网页时累计节约的百分比，所以说网页本身带来的增肥效果也要得到重视。
另一个问题就是文件名，每个文件名称都在其他网页的链接中得到体现，尽管增加的只是字节数，对e书的“减肥”贡献微乎其微，但是积少成多，可用1、2个字节命名文件，不用3个字节，中文命名更要避免。再说简单的文件名在你建立链接时不至于自己被搞得晕头转向，何乐而不为呢？

四、ews的“关于”页面

之所以单独提出，是因为存在一个极易被忽略的问题。ews采用html对话框是因为网页有很强的表现力，可以把“关于”页面设计得非常个性化，同时也带来整本e书的图片、音效等问题，上面说过的不再重复。值得注意的是，存放“关于”页面的文件夹绝对不能放在e书的网页文件的所在文件夹，否则会造成重复编译。

五、后期工作

打包前要清理文件夹，一切不需要的文件如制作图片时的辅助用图、公共的网页模板删除无商量；自制图标、闪屏图片、按钮背景图、logo等不需打进书中，任你移到犄角旮旯，软件的浏览功能照样都能找出来。这次看见有会员把初稿一初稿二一并打包进稿三，相当于一个人有了三个人的体重，不叫“肥肥”才怪。

总之，在不影响e书表达效果的前提下，“减肥”的原则是少一点是一点，可用1k表达，决不用1.1k。一切搞定后，放心压缩，包你做出的书“身轻如燕”“娇小玲珑”“人见人爱”

常见电子书格式及其反编译思路

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实现了书签功能后，我就下定决心一定要解决反编译问题。 2.2.2.1 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代码来用。 2.2.2.2 caislabs ebook pack express 1.6 这个电子书制作工具也出过汉化版，所以在国内也有一定影响，不过这种影响似乎还没有大到足以使反编译工具满天飞的程度，嘿嘿…… 在分析这种格式的电子书的时候，我没有使用任何反汇编工具，用ultraedit32和系统监视工具就猜出来了： 文件标识：以十六进制串 00 f8 03 00 结尾。这个似乎是一种惯例，差不多所有exe格式的电子书都有自己特殊的文件结尾。 目录块起始地址指针：0003f81c 目录块中目录项结构：以0字符结尾的文件名＋4字节起始地址，文件名起始字节为ff则目录块结束。 如果文件存放在子目录里，则文件名首字符：02＝../，01：第一个00变成/，直到遇到02。 文件内容实际起始地址：目录项里的4字节起始地址＋9 文件内容长度：目录项里4字节起始地址所指内容，dword。 在分析出目录结构后，我曾经想通过调试工具，分析文件加密算法，再反编译出具体的文件内容，但是很快我就发现那样干太累了，实在是得不偿失。 不过在经过几次尝试后，我还是找到了一个偷懒的办法： 通过安装hook的方法，往电子书的进程空间注入一个dll。 在这个dll里，用windows标准的api函数urldownloadtofile，就可以下载到指定的文件。文件的url可以按前面说的方法，从目录项得到相对路径，再加上一个固定前缀（"file://z:\\com_caislabs_ebk\\"）构成绝对路径。 unebook在批量反编译这种格式的电子书的时候，就是按照上面的分析结果实现的。 不过到了更高版本的caislabs ebook pack express的时候，似乎caislabs公司也开始意识到文件内容保护的重要性，因此不仅对文件内容采用更强的加密算法，杜绝了可以用urldownloadtofile下载的漏洞，连目录块的加密强度都强到足够使我不想去分析了。幸好这个时候我已经有了更好的反编译思路－－与具体文件格式无关的，专门针对使用ie内核的电子书的通用反编译思想。 2.2.2.3 通用反编译思路在分析过几种电子书格式后，我开始领悟到一个真理：电子书内部文件结构的变化是无穷的，而我的时间和精力是有限的；把有限的时间和精力投入到对抗无穷的变数中去，早晚会有累死的一天。 有此认识后，我开始思考有没有什么通用的方法，可以解决大部分电子书的反编译问题（我还没有幼稚到相信这世上会有万能药的程度）。按照惯例（不可救药的职业病），第一步当然是市场调查、产品定位，结论是目前大多数电子书都是基于ie内核的，但是根据我在开发myreader时对ie内核的了解，这里面明显存在一个误区：微软以控件的形式提供ie内核，其目的就是希望通过控件接口的开放性、方便性，吸引更多的人加入微软的标准阵营，如果想在此基础上添加加密、保护等等内容，恐怕与微软的初衷不合（我说的是当时，以后微软改主意了也说不定）。因此我相信ie内核一定有后门可走！经过一番努力，果然没有令我失望。 1、基本原理 针对ie内核电子书的通用破解技术实现起来可能需要一些技术和技巧，但是原理却很简单，几句话就可以说清楚：不论电子书在存储的时候如何对内容进行加密，在将内容传递给ie内核进行显示的时候，一定要将内容转换成ie内核能够识别的标准格式－－html格式。而ie内核为了便于显示、刷新，在对html代码进行解析后，并不是立刻就把这些html代码抛弃，而是在内存里保存了一份备份。因此只要将这份备份从ie内核里搞出来，就得到了解码后的内容，也就是反编译想得到的内容。 至于网页中的其它内容，包括图片、css、js、flash文件等，就更简单了：模拟ie内核，直接找电子书要就好。如果电子书分辨不出请求是来自ie内核还是来自其它地方，自然会乖乖把我们需要的东西双手奉上！ 虽然反编译的原理几句话就可以说清，但是要加以实现，还需要经过艰苦的探索和试验，我自己就经过了长期的努力，ie内核的源代码都翻来覆去看了好几遍（吹的，别当真！）。而我思想的发展也大概经历了两个阶段：第一个阶段是在得到某份传说中的源代码（没错，就是那份展开后近700mb，被国内主流媒体形容为噱头、无足轻重、充满无聊垃圾的东西）之前，完全立足于微软公开的ie内核接口。当时我考虑将电子书内容按照html、图像等分类，分别解决获取问题。第二个阶段是在得到那份源代码之后，我突然发现其实对于所有文件，我都可以直接找电子书要，只要假装是ie内核在要就行了。 由于某些东西比较敏感，因此下面叙述的主要是我第一个阶段的想法，其中有些属于基础性的东西。第二个阶段的实现恕我不便奉告。

2、获取html源代码的方法 从ie内核获取html源代码的方法不仅我一个人在想，从国内到国外，从csdn（csdn的vc/mfc区有一个栏目专门讨论ie内核编程）到msdn，早就有很多人讨论过了，归纳起来，一般认为可以通过下列步骤实现： 不管是通过鼠标点击也好，通过enumchildwindow也好，总之先找到ie内核的显示窗口，也就是电子书显示网页内容的那个窗口。 通过这个窗口的句柄（hwnd），取得这个窗口对应的ie内核文档接口ihtmldocument2的接口指针。取得的方法目前认为有两种，我个人认为这两种需要结合使用，否则总有一些电子书会搞不定：一个是通过msaa，一个是通过wm_html_getobject消息。至于具体的实现代码，在csdn上都快被讨论烂了，因此此处从略，有需要的自己到csdn上找。不过这两种方法都对平台有要求：xp下是完全没有问题，2000下可能需要装ie 6，98/me/nt就不要想了。 在得到ihtmldocument2接口指针后，按照这个接口提供的标准方法，即可获得文档的html代码。具体实现代码见csdn中的例子。 除了上面这种方法外，我自己还尝试过一种方法：使用mime filter。 对于搞过网页在线翻译、网页内容过滤的人来说，mime filter可是吃饭的本钱，它的作用和实现机理应该早就烂熟于心，但是对于其它人来说，可能还不是很熟，所以这里简单介绍一下：为了便于对ie内核的功能进行扩展，微软规定在ie内核显示某种标准格式（html、text等）的内容之前，会先将要显示的内容传递给这种格式的过滤器，即mime filter，由它先对内容进行预处理（如将英文翻译成中文，将下流文字替换成星号等），然后再显示。 按照这个原理，如果实现一个针对html格式的mime filter，即可拦截到最原汁原味的html代码。可惜，经过我的尝试，这招对ie本身是灵的，对某些电子书也有效，但是对另一些无效。再加上使用ihtmldocument2接口指针的方法要比这种方法简单得多，也可靠得多，所以后来在我开发的反编译工具killebook、iecracker和ctrln里就没有使用这种方法。不过这种方法也有一个好处：与平台无关，我在98/me/2000/xp下都试过，当然都是在虚拟机下试的啦。 mime filter的作用机理、实现方法在msdn里有详细说明，并提供了详细的实例代码，有需要的可以到msdn上搜“mime filter”。 3、获取图像的方法 与html代码相似，ie内核对图像的处理也有一个“下载->解码->显示”的过程。考虑到显示代码的抽象性，原来各种各样的图像格式，包括jpg、gif、png、tiff等，在解码后都被统一表示成位图格式，而原有格式数据在解码后即被从内存中释放，只在ie的cache中留有文件备份。如果指定不允许保存本地cache，则连这个备份都没有。在ie中通过右键菜单选“图片另存为...”的时候，其实就是将cache中的文件备份拷贝一份出来，如果cache中已经没有备份，就只能保存内存中的位图（*.bmp）了。现在明白为什么有些图片明明是jpg格式，但是用ie却只能保存为“无标题.bmp”了吧？ 因此，获取图像文件要比获取html文件难得多。而且在msdn里说得很清楚，用ihtmldocument2接口只能得到图像的链接，用mime filter也不能搞到网页里的图像数据，因此需要另想办法。我想过、试过的包括： 先将图像复制到剪贴板，再从剪贴板里获取图像数据，然后根据图像文件扩展名（可以从图像元素的url里解析），编码成原始图像格式，包括jpg、png、gif、tiff等。这个方法实现比较简单，到msdn kb里搜索q293125，拷贝图像到剪贴板的现成源代码就有了，图像编码的源代码则可以参考cximage，这个也是google一下就有的。不过这个方法远非完美无缺：a). 对于png、gif等允许带透明背景的格式，用这种方法处理后就不透明了。b). gif动画处理后就动不起来了，只能显示其中的某一帧。c). 对于jpg这样的有损压缩格式来说，每压缩一次就损失一次，多压缩几次可能就没法看了。d). 在电子书里，可以通过标准的windows api函数，使剪贴板失效。 将ie内核导航到图片，然后通过iviewobject接口获取图片的拷贝。这个方法与上面的方法基本相同，不过不通过剪贴板，可以防止因为剪贴板被封锁而搞不到图像。 使用ie图像解码插件。ie内核在下载到某种格式的图像文件后，会调用对应的解码器，对图像进行解码（类似于mime filter）。为了便于扩充，解码器是做成插件形式的。如果自己做一个图像解码器插件，对解码请求进行拦截，即可获得解码前的原始图像格式数据。解码器的接口、实现方法在微软公开文档中没有任何蛛丝马迹，但是在那份传说中的源代码里，不仅有详细的接口规范，而且有好几个内嵌图像解码器的实现代码，可供借鉴。奇怪的是，虽然在msdn中找不到，但是我在google