第四章、epub文件處理 -- epub文件內部組成

第四章、epub文件處理 -- epub文件內部組成

第三章的結尾，咱們說到從FBReaderApp類的openBookInternal方法，就要開始對epub文件的處理流程了。

在對這個流程進行詳細的分析以前，咱們有必要先用一個章節詳細介紹一下epub文件的內部組成。

首先，epub文件一種壓縮文件，是壓縮格式是與zip壓縮文件是同樣的。換一句話說，epub文件是能夠用支持zip格式的解壓縮文件解壓的（有些軟件不能識別epub後綴名，須要手動把.epub的後綴名改爲.zip）。

把epub文件解壓以後，打開文件夾，咱們能夠看到有以下的文件與文件夾，咱們一個一個來看一下。

META-INF文件夾

這個文件文件夾的名字翻譯成中文就是「元信息」。文件夾裏面只有一個container.xml文件

container.xml文件

文件的內容以下：

這段內容的做用就是標明瞭.opf文件的位置。這個.opf文件是一個很重要的文件，它記錄了epub文件內部各個文件的具體信息，咱們會在介紹OPS文件夾的時候詳細介紹這個文件。

程序必須正確解析.opf文件的內容後才能正常運行，可是.opf這個文件的文件名自己倒是能夠自定義的，也就是說，不一樣的epub文件裏面可能包含不一樣名字、位於不一樣行位置的.opf文件。那麼，如何確保程序可以正確找到並解析.opf文件呢，就是經過container.xml這個文件來指定.opf文件。正是基於這個緣由，epub文件的標準裏規定「EPUB 根目錄下必須包含 META-INF 目錄，並且其中必需要有一個文件 container.xml」（引用自http://blog.sina.com.cn/s/blog_6441e0640100gmhv.html）。

你們能夠試一下，若是你把解壓後的epub文件裏的container.xml文件更名後再從新壓縮成epub文件，程序就會報錯。

OPS文件夾

OPS文件夾主要包含三種重要的文件.opf文件、ncx文件、.xhtml文件。同時，還可能會有css文件和圖片文件。下面詳細介紹下這些文件。

.opf文件

opf表明「Open Packaging Format」，意譯成中文差很少應該是「EPUB文件包格式」。咱們說過epub文件是個zip壓縮文件，opf文件的做用能夠被理解爲描述了EPUB文件解壓後，內部各個文件和文件夾的名字、位置等信息。

.opf文件主要包含三個主要的節點metadata、manifest、spine，這個三個節點分別描述了不一樣信息。

其中，metadata節點定義了epub的做者、書名、語言等元信息。這些元信息大部分都在dc的命名空間下。dc表明Dublin Core，意指國際組織「Dublin Core Metadata Initiative」定義的標準。

manifest節點的做用是描述epub文件內部對應不一樣章節對應的文件的位置。manifest節點在這裏的做用有點像以前提到的container.xml文件：container定義了.opf文件的位置，而manifest節點中的item子節點的href屬性則定義了含有對應每一個章節的文件的位置。

spine節點的做用是定義讀者在順序閱讀時，每一個章節出現的前後次序。linear這個節點的做用是這樣的：「 EPUB 規範的閱讀系統將首先打開 spine 中沒有設置爲 linear=no 中的第一項」。因此，「建議將封面定義爲 linear=no」。（引用自http://blog.sina.com.cn/s/blog_6441e0640100gmi8.html） 

    咱們能夠看到，咱們的測試epub文件彷佛並無嚴格按照epub規範將封面的linear屬性設置爲「no」。正由於如此，第一次打開測試文件的時候，默認的第一頁是封面而不是正文。

.ncx文件

ncx表明「Navigation Center eXtended」，意思大體就是導航文件，這個文件與目錄有直接的關係。

.ncx文件中最主要的節點是navMap。navMap節點是由許多navPoint節點組成的。而navPoint節點則是由navLabel、content兩個子節點組成。

navPoint節點中，playOrder屬性定義當前項在目錄中顯示的次序。

navLabel子節點中的text節點定義了每一個目錄的名字。

content子節點的src屬性定義了對應每一個章節的文件的具體位置。

看到這裏，可能會有有人以爲.opf文件與.ncx文件有一點重複：.opf文件的item節點中的href屬性描述了各個章節文件的位置與順序，.ncx文件中的conten節點中的src屬性也描述了各個章節文件的位置與順序。其實他們仍是有區別的，區別就在於，.opf文件定義的是讀者在順序閱讀時會用到的章節文件與它們的順序，.ncx文件則定義的是目錄中會用到的章節文件與它們的順序。若是存在某些附件性質的內容被但願在目錄中出現，但卻不但願在讀者順序閱讀的時候出現時，那麼就能夠經過對.opf文件和.ncx文件進行不一樣的設置來達到這個目的。固然，大部分的時候，.opf與.ncx這兩個文件的內容基本是重合的。

.xhtml文件

.xhtm文件就是存儲每一個章節具體內容。按照epub的規範，存儲具體內容的文件應該是xhtml爲後綴名（參照http://zh.wikipedia.org/wiki/EPUB），可是彷佛並非每一個epub裏面都用xhtml做爲存儲具體內容的文件的後綴名。好比，咱們的測試文件就使用了html做爲後綴名，我還看到過htm做爲後綴名的。但其實無論用什麼做爲後綴名都不會有問題，由於在.opf和.ncx文件已經準肯定義文件的位置和後綴名。同時，無論epub文件使用了什麼後綴名，FBReader程序都是使用XHTMLReader類來處理這些文件。

樣式文件

樣式文件的做用是定義一些文本信息顯示的格式。並非每個epub文件內部都會附有樣式文件，沒有樣式文件的狀況下，就會使用程序默認的樣式文件。

在FBReader程序1.0的版本里面並無專門讀取epub文件內部樣式文件的類。1.0的版本直接使用了/asstes/default/style.xml做爲默認的樣式文件。不論是epub文件是否附有自帶的樣式文件文件，1.0的版本都使用的是這一套樣式文件的格式。2.0的版本增長了讀取自定義樣式文件文件的功能。你們能夠在1.0版本和2.0版本下分別打開Quiet這本書（這個文件只做爲測試用，請支持正版，多看中譯版購買地址），就能夠明顯看到樣式文件格式的不一樣。

1.0版本中的css解析類：ZLTextStyleCollection類

2.0的版本中的樣式文件解析類：

1.0版本顯示效果：

2.0版本顯示效果（標題與小字部分都使用epub文件內置的樣式文件）

圖片文件

圖片文件通常集中存儲在一個文件夾裏面。最多見的圖片的文件就是封面圖片。封面圖片的位置會在.opf文件標明。

Mimetype文件

這個文件的內容很簡單，只有一行：application/epub+zip。其實這行內容就是代表了epub文件的mimetype屬性。搞過網頁的朋友應該挺熟悉這個mimetype屬性的，html文件的mimetype屬性就是text/html，樣式文件文件的mimetype屬性是text/樣式文件，js文件的mimtype屬性則是application/javascript。

根據epub的標準，epub根目錄下必須包含mimetype文件，文件名與內容都不能變。不過，我仔細看了下FBReader代碼，並無發現專門針對這個文件的部分。我有試着把這個miemtype文件刪掉而後再從新壓縮成epub文件。FBReader程序仍是能正常打開這個文件。總而言之，按照標準，mimetype文件必須有，並且文件名與內容都不能變。不過，實際操做起來，沒有mimetype文件，FBReader同樣能正常打開epub文件。

若是你們想更深刻得了解epub文件的組成，能夠參考下這個博客的相關內容。

http://blog.sina.com.cn/s/blog_6441e0640100gmfe.html

http://blog.sina.com.cn/s/blog_6441e0640100gmhv.html

http://blog.sina.com.cn/s/blog_6441e0640100gmi8.html

http://blog.sina.com.cn/s/blog_6441e0640100gmj9.html