編譯和反編譯pdf

⑴ 如何用反編譯的方法解除pdf閱讀器的列印和拷貝復制

是LocalImport裡面的那兩本嗎？adobereader均可以打開，另存和轉txt還有列印都是可選的啊

⑵ PDF格式的電子書怎麼反編譯呀

PDF分兩種，圖片式的和文字式的，前者要OCR，難些，後者簡單，可直接復制。但都可以搞。

⑶ pdf格式怎麼轉換成word

"用軟體，使用之後然後有兩種結果
1、轉化出來的就是想要的word，這種情況最理想了；
2、轉化出來的word上都是圖片，需要上網找「ABBYY finereader v9」一類的文字識別軟體。ABBYY finereader v9是我見過的最強大的PDF（圖片格式或者是掃描件）轉word的軟體。它是一款OCR軟體，界面比較簡潔明，9.0和以上版本有簡體中文版的，支持100語言的識別，特別是混合多種語言識別效果也非常好：安裝完畢之後，首先把圖片上的文字識別出來，然後再對照圖片把識別錯誤的地方改過來，這樣就實現了，從JPEG文件到word的格式轉換。
這一類的軟體有PDF To Word Converter、Solid converter PDF等，大致過程都是一樣的。
也可以在線聯網將PDF轉為word文件，但是存在泄密的可能性，因此不建議使用。
轉出來的Word文件就可以正常進行編輯操作了。

⑷ pdf轉word亂碼怎麼辦

PDF轉word亂碼超實用解決方法

方法/步驟

• 首先我們要先弄明白為什麼PDF轉word會亂碼。

  轉換亂碼的原因主要有這幾個：

  1、原文檔的文字編碼丟失或不兼容。

  2、文檔轉為PDF時使用了內嵌的字體。

  3、PDF文檔製作時沒有嚴格按照PDF標准，反向轉換時，也無法順利反編譯。

  以上原因造成的亂碼，用軟體無論轉換多少次都依然是亂碼。

  下圖就是以上幾種問題的pdf轉word後的效果。

  

• 4

  在選擇人工服務的時候，要記得查看一下是否有提供OCR服務哦。有OCR功能才能轉換這樣的文檔。

⑸ PDF是什麼，為什麼PDF轉換成Word文字很麻煩

PDF是什麼
pdf（Portable
Document
Format的簡稱，意為「攜帶型文檔格式」），是由Adobe
Systems用於與應用程序、操作系統、硬體無關的方式進行文件交換所發展出的文件格式。PDF文件以PostScript語言圖象模型為基礎，無論在哪種列印機上都可保證精確的顏色和准確的列印效果，即PDF會忠實地再現原稿的每一個字元、顏色以及圖象。
可移植文檔格式是一種電子文件格式。這種文件格式與操作系統平台無關，也就是說，PDF文件不管是在Windows，Unix還是在蘋果公司的Mac
OS操作系統中都是通用的。這一特點使它成為在Internet上進行電子文檔發行和數字化信息傳播的理想文檔格式。越來越多的電子圖書、產品說明、公司文告、網路資料、電子郵件在開始使用PDF格式文件。
為什麼PDF轉換成Word文字很麻煩？
不麻煩啊，使用轉換器（Sanpdf）進行轉換就可以啦。

⑹ 如何反編譯PDF文檔以方便進行文檔操作

有三種方法——————
1、對於打字文件製作的PDF文件，福昕PDF閱讀器就可以把它另存為TXT文本；
2、對於掃描文件製作的PDF文件，用漢王PDF OCR8.1把它識別為TXT文件；
3、用福昕PDF編輯器處理，但個人覺得那個技術不容易掌握。

⑺ 求做電子書

一本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

⑻ 怎麼反編譯spire.pdf.dll

如果丟失，按我說的試試
第一、修復
使用騰訊電腦管家，點開電腦診所之後，搜缺失的dll文件，會自動篩選出來，然後你只需要點立即修復即可！
第二、下載安裝
根據你的系統下載(比如XP或w7),然後點開你的系統盤,點開windows這個文件夾再點開system32這個文件夾，把下載下來的dll文件復制進來就可

⑼ 怎麼把PDF格式文件里的文字復制出來

可以下載個pdf的反編譯工具，反編譯成word文檔，或者是文本文檔！

⑽ 如何反編譯PDF文檔以方便進行文檔操作

可以用Foxit PDF Editor等對這種各式的文檔進行反編譯操作，然後再對需要的文件或圖片進行提取。
有些PDF文件出於版權等因素而設置了密碼，不過，可以破解