常見電子書格式及其反編譯思路分析第1/3頁

2020-01-31 16:13:36

字體：大中小

來源：轉載

供稿：網友

聲明：本文可能夾雜大量技術術語，如果您對此感到不快，請勿繼續閱讀。
本文僅僅討論一些思路，不會提供相關源代碼，最多也只提供源代碼網站的鏈接。如果您對此有所不滿，請勿繼續閱讀。
本文僅僅從技術角度討論電子書反編譯問題，請勿將之用于侵犯版權等等非法目的，或損害他人利益。如果您對此感到失望，請勿繼續閱讀。
本文版權歸作者所有，轉載前請先征得作者書面同意。
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?？蓤绦畜w指的是電子書的執行代碼部分，包括程序代碼、插件代碼、界面資源等。內容指的是電子書中真正包含的文本、圖像內容，一般使用某種壓縮、加密算法進行處理。TOC（Table Of Content）相當于目錄索引，作用是加速對內容的訪問。因此相對于直接用WinZip、WinRAR對原始內容進行壓縮，每一本EXE格式的電子書都會浪費一部分磁盤空間，以存儲執行體部分。電子書的軟件界面越花哨，這種浪費一般也越大，我見過最夸張的電子書比原始內容足足多出 1 MB多的東西。
避免垃圾。對于某些基于IE內核的電子書來說，由于實現技術的限制，可能會在注冊表和系統目錄下留下垃圾。
安全。如果說如今的網絡社會是一個充滿惡意、毫無誠信的環境，可能有點夸張了，不過確實有人不知“做人要厚道”為何物。老實說，每次拿到一個來路不明的EXE格式的電子書的時候，我都在懷疑里面有沒有什么木馬、病毒，實在難受。
便于平臺轉換，包括轉換到手持設備。EXE格式的電子書看起來可能很爽，但是畢竟只能在Windows下看，如果想在其它系統下看，尤其是在手持設備上看，唯一的出路就是反編譯了它。
當然，在反編譯后，也必須尋找合適的替代品，以繼續滿足原先的需要：

打包工具。建議選擇Winzip或WinRAR，不僅使用方便，而且打包后文件也小，進入目錄還快。
閱讀工具?，F在可以不解包就直接閱讀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實現了書簽功能后，我就下定決心一定要解決反編譯問題。

12 3 下一頁閱讀全文

上一篇：第15天(就業班) 課程回顧、mysql安裝、管理數據庫、管理表、增刪改數據、查詢數據

下一篇：推薦的一篇用多種腳本清理iis日志的代碼第1/3頁