EPUB開放容器格式3.2

概要

本規格定義了一個檔案格式與處理模型，以包裝一組相關聯的資源組成一本EPUB®出版品為單一檔案容器，即為EPUB容器。

本規格定義了規則供建構抽象（即為「抽象容器（abstract container）」）的檔案集合，以及規定此抽象容器於ZIP封存檔（即為「ZIP容器」）的呈現。供ZIP容器的規則建構於 [ODF] 所使用的ZIP技術。OCF也定義了一套標準方式供嵌入資源模糊化，例如字體，以提供需要這些功能的EPUB出版品使用。

本規格屬於組成 [EPUB32] 的規格群之一，其為基於XML與Web標準的數位出版品交換與遞送格式。要了解整體EPUB 3規格，需要與其他規格一併閱讀且理解。

可參考 [EPUB32Changes] 以了解本規格與其前版本的差異資訊。

3. OCF抽象容器

3.1 導論

本章節為非規範性。

OCF抽象容器檔案系統模型，使用單一通用根目錄來置放所有內容。所有供EPUB出版品使用的本地資源都放在由根目錄所開始的目錄樹中，本規格中不對資源做檔案系統結構的指定。

此檔案系統模型也包含一個必要的資料夾META-INF，為根目錄下直接子目錄，用於置放以下特殊檔案：

container.xml [必要]: 識別定義該EPUB出版品中每個內容釋義的包裝文件位置。
signatures.xml [選擇性]: 包含各種用途的數位簽章。
encryption.xml [選擇性]: 包含關於出版品資源加密的資訊。當使用模糊化時本檔案為必要。
metadata.xml [選擇性]: 用於儲存OCF ZIP容器的詮釋資料。
rights.xml [選擇性]: 用於儲存關於數位權利的資訊。
manifest.xml [選擇性]: 一份容器內容的宣告，開放文件格式 [ODF] 允許使用。

在META-INF資料夾中各檔案的適用性需求定義於META-INF資料夾。

3.2 檔案與目錄結構

供OCF抽象容器使用的虛擬檔案系統必需有單一通用的根目錄置放容器中的所有內容。

OCF抽象容器必需包含一個名為META-INF的目錄，作為容器根目錄的直接子目錄。對該資料夾中內容的需求在META-INF資料夾中說明。

根目錄中 mimetype檔案名稱保存供OCF ZIP容器使用，於OCF ZIP容器中說明。

所有其他在OCF抽象容器中的檔案可以放置於根目錄以下的所有階層位置，但不能置放在META-INF資料夾中。

3.3 參照其他元件時相對IRI

在OCF抽象容器中的檔案必需透過相對IRI位置相互參照 ( [RFC3987和 [RFC3986] )。

範例1

以下範例呈現一個名為image1.jpg的檔案，與XHTML內容文件放在同一資料夾，如何透過一個 [HTML] img>元素參照。

<img src="image1.jpg" alt="…" />

對相對IRI位置，其基本IRI [RFC3986] 由其給予的檔案格式之相關的語言規格所定義。例如，CSS的相對IRI位置如何運作，定義於CSS樣式表以及特性宣告 [CSSSnapshot] 之脈絡。

注意事項

有些語言規格參考早於 [RFC3987] 的IETF意見需求 [RFC] （Requests For comments），在這些案例中，特殊語言套用較早的意見需求於內容上。

不像大多數的語言規格，所有在META-INF資料夾中的檔案使用OCF抽象容器的根目錄作為預設的基本IRI。

舉個例子，如果META-INF/container.xml有以下內容：

範例2

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/Great_Expectations.opf"
            media-type="application/oebps-package+xml" />	
    </rootfiles>
</container>

接著EPUB/Great_Expectations.opf的路徑相對於該OCF抽象容器的根目錄，不相對於META-INF目錄。

所有相對IRI位置必需解析到位於OCF抽象容器中的資源（例如，位於或者低於根目錄）。

3.4 檔案名稱

本章節所說明的檔案名稱限制，設計用於使路徑名稱與檔案名稱在多數常用的作業系統上無需調整即可使用。本規格不指示OCF處理器在無法表現OCF檔案與路徑名時，如何添補其相容性問題的作法。

在一個OCF抽象容器的脈絡下，檔案與路徑名稱在乎大小寫區分，並且必需符合以下領域需求：

檔案名稱必需為UTF-8 [Unicode] 編碼。
檔案名稱不得超過255位元組（bytes）。
任何在OCF抽象容器中的資料夾與檔名，其路徑名稱不得超過65535位元組。
檔案名稱不得使用以下 [Unicode] 字元，因為這些字元可能在常用作業系統間支援程度不一：
- SOLIDUS: / (U+002F)
- QUOTATION MARK: " (U+0022)
- ASTERISK: * (U+002A)
- FULL STOP as the last character: . (U+002E)
- COLON: : (U+003A)
- LESS-THAN SIGN: < (U+003C)
- GREATER-THAN SIGN: > (U+003E)
- QUESTION MARK: ? (U+003F)
- REVERSE SOLIDUS: \ (U+005C)
- VERTICAL LINE: \ (U+007C)
- DEL (U+007F)
- C0 range (U+0000 … U+001F)
- C1 range (U+0080 … U+009F)
- Private Use Area (U+E000 … U+F8FF)
- Non characters in Arabic Presentation Forms-A (U+FDDO … U+FDEF)
- Specials (U+FFF0 … U+FFFF)
- Tags and Variation Selectors Supplement (U+E0000 … U+E0FFF)
- Supplementary Private Use Area-A (U+F0000 … U+FFFFF)
- Supplementary Private Use Area-B (U+100000 … U+10FFFF)
所有在同一個資料夾中的檔案名稱必需在大小寫正規化後皆為獨特，如3.13章節中 [Unicode] 所解釋。
所有在同一個資料夾中的檔案名稱應該在NFC或NFD正規化 [TR15] 後為獨特。

注意事項

有些商用ZIP工具不支援完整Unicode範圍，且可能僅支援 [US-ASCII] 範圍的檔案名稱。作者若想使用有這些限制的ZIP工具的話，最好盡可能將檔案名稱限制在 [US-ASCII] 範圍。如果檔案的名稱在解壓縮過程時無法保留，在檔案透過URI被內容所參照時，可能有需要補齊名稱解譯。

3.5 `META-INF`資料夾

3.5.1 內含物

所有OCF抽象容器必需在其根目錄中包含一個名為META-INF的資料夾。

此資料夾中的檔案為META-INF保留的檔案。其他未列於本章節的檔案可以被放在META-INF資料夾中；而OCF處理器當遇到這些檔案時不得視為錯誤。

3.5.2 保留的檔案

3.5.2.1 容器檔案 (`container.xml`)

置放於META-INF資料夾中的container.xml為必要，其用於指定在OCF抽象容器中的EPUB包裝。

該檔案的內容必需在移除所有來自其他命名空間的元素以及屬性（包含所有屬性以及有這些元素的內容）後，合乎定義在「供container.xml使用的綱要」裡提供的綱要。

每一個rootfile元素必需指定一份包裝文件的位置，以代表EPUB出版品的一份內容釋義。每一份內容釋義必需與其容器的EPUB版本相容。

一個OCF處理器必需將在rootfile元素中第一個rootfile元素視為所容納的EPUB出版品中的預設內容釋義。閱讀系統需要呈現預設內容釋義，但可以顯示容器中的其他內容釋義。

注意事項

儘管EPUB容器具備能包含一個以上內容釋義之內容的能力，閱讀系統對於多重內容釋義的支援依然未受到廣泛支援，僅有相關團體為了其目的與手段提供特定的環境支援。

範例3

以下範例呈現一個EPUB出版品的container.xml範例，其根檔案為EPUB/My Crazy Life.opf（包裝文件）：

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/My_Crazy_Life.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

範例4

以下範例呈現SVG與XHTML內容釋義包裝於相同的容器中：

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="SVG/Sandman.opf"
            media-type="application/oebps-package+xml" />
        <rootfile full-path="XHTML/Sandman.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

選擇性的links元素用來指定處理OCF ZIP容器時所需要的資源。其每一個link元素必需包含一個href屬性，其值指定了一個資源的位址。每一個link元素都必需包含一個rel屬性，其值指定與資源的關係，以及可以包含一個media-type屬性，其值必需為一個媒體類型 [RFC2046] ，其指定了該link參照的資源的類型與格式。

注意事項

links元素用於多重內容釋義EPUB時，用以指向內容釋義所映射的文件。

rootfile元素中full-path屬性的值與link元素的href屬性必需包含一個路徑部件（path component） [RFC3986] 其必需僅使用path-rootless [RFC3986] 形式。其路徑部件與根目錄為相對。

OCF處理器必需忽略container.xml檔案中的外圍元素與屬性。

3.5.2.2 加密檔案 (`encryption.xml`)

在META-INF資料夾中選擇性的encryption.xml包含所有該容器內容的加密資訊。如果任何容器中的資源有受到加密，encryption.xml必需用於指出哪一份資源受到加密，以及提供如何解密的資訊。

本檔案是一個XML文件，其根元素為encryption。encryption元素包含類型子元素EncryptedKey及EncryptedData由 [XMLENC-CORE1] 所定義。EncryptedKey元素解釋了用於容器的每一個加密密鑰，而EncryptedData元素解釋了每一個加密檔案。每一個EncryptedData元素參照一個EncryptedKey，如在XML加密中所說明。

encryption.xml檔案之內容必需合乎定義在「供encryption.xml使用的綱要」裡提供的綱要。

OCF獨立地加密個別檔案，以一些安全性交換效能的提升，允許容器內容能夠被遞增解密。但以這種方式加密會暴露目錄結構與整個包裝的檔案命名。

OCF採用XML加密 [XMLENC-CORE1] 來提供一個加密用的框架，允許使用多種演算法。XML加密指定一個程序供加密任意資料並且以XML表示其結果。儘管OCF抽象容器中可能包含非XML資料，但XML加密可用於加密OCF抽象容器中的所有資料。OCF加密僅支援對在容器中的整個檔案加密，而非檔案的一部分。若encryption.xml檔案存在，則其自身不得被加密。

在OCF抽象容器中，以加密資料置換未加密的資料。例如，如果一個名為photo.jpeg的影像為加密，photo.jpeg資源的內容應該被置換成其加密後的內容。在ZIP資料夾中，應該儲存加密後的檔案而非Deflate壓縮檔。

請注意在一些狀況下，需要模糊儲存被內容釋義參照的嵌入資源，以連接到「母」EPUB出版品並且使它們更難以在非限制的使用下解壓縮（例如，字體）。儘管模糊化並非加密，encryption.xml檔案用於對應資源模糊化演算法以識別哪些資源需要在使用前去模糊化。

以下檔案不得被加密，無論是使用預設或者特別的加密法：

mimetype
META-INF/container.xml
META-INF/encryption.xml
META-INF/manifest.xml
META-INF/metadata.xml
META-INF/rights.xml
META-INF/signatures.xml
包裝文件

簽署的資源可以之後使用供XML簽章 [XMLENC-DECRYPT] 的解密變形法（Decryption Transform）加密。這項功能使應用程式，例如一個OCF客戶端在從檔案簽署前來辨別資料是否加密。只有在簽署後為加密的檔案必需要在計算其摘要用於查核簽名前解壓縮。

範例5

以下範例採用2.2.1節中之 [XMLENC-CORE1] ，資源image.jpeg使用對稱密鑰加密（AES）加密，其對稱密鑰更進一步使用非對稱密鑰加密（RSA）加密，其密鑰由John Smith持有。

<encryption
    xmlns ="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <enc:EncryptedKey Id="EK">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo>
            <ds:KeyName>John Smith</ds:KeyName>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherValue>xyzabc</enc:CipherValue>
        </enc:CipherData>
    </enc:EncryptedKey>
    <enc:EncryptedData Id="ED1">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK"
                Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="image.jpeg"/>
        </enc:CipherData>
    </enc:EncryptedData>
</encryption>

3.5.2.2.1 壓縮與加密順序

儲存在ZIP容器中，非編碼內容類型的資料流應該在加密前壓縮，必需使用Deflate壓縮。這種做法可確保存放在ZIP容器中的檔案能夠佔較少的空間。

編碼內容類型的資料不應在加密前壓縮。在這些案例中，額外的壓縮會在製作時產生不必要的處理程序（尤其在處理大型資源檔案時），以及在閱讀時將會影響影音播放效率。在某些案例中，某些加密綱要的組合壓縮可能會降低閱讀系統處理部分內容需求的能力（例如，HTTP位元組範圍byte range），由於技術上無法在媒體播放時判斷完整資源的長度（例如，HTTP內容長度檔頭Content-Length header）。

在加密前壓縮的資料流應該提供額外的EncryptionProperties詮釋資料來指定初始資源的大小（即為，在壓縮與加密前），如同下列每個CompressionXML元素所定義。加密前沒受壓縮的資料流可以提供額外的EncryptionProperties詮釋資料來指定初始資源的大小（即為，加密前）。

元素名稱

Compression

命名空間

http://www.idpf.org/2016/encryption#compression

用法

EncryptionProperty的選擇性子元素。

屬性

Method [必要]

識別所使用的壓縮法。

值需為「0」（無壓縮）或「8」（Deflate演算法）。

OriginalLength [必要]

代表資源初始大小（位元組數）。

值為正整數。

內容模型

空白

範例6

以下範例呈現一個MP4檔案經過Deflate壓縮，其原來大小為3500000位元組。

<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
        ...
        <enc:CipherData>
            <enc:CipherReference URI="OEPBS/video.mp4"/>
        </enc:CipherData>
        <enc:EncryptionProperties>
            <enc:EncryptionProperty xmlns:ns="http://www.idpf.org/2016/encryption#compression">
                <ns:Compression Method="8" OriginalLength="3500000"/>
            </enc:EncryptionProperty>
        </enc:EncryptionProperties>
        ...
    </enc:EncryptedData>
</encryption>

3.5.2.3 宣告檔案 (`manifest.xml`)

META-INF資料夾裡選擇性的manifest.xml檔案提供了對容器裡檔案的宣告。

OCF規格不強制指定宣告的格式。

請注意在包裝文件中的manifest元素為唯一用於處理該內容釋義的宣告。包含在ZIP封存中的額外宣告資訊或者選擇性的manifest.xml不得被用於處理內容釋義。

注意事項

本功能僅為了相容於 [ODF] 續存。

3.5.2.4 詮釋資料檔案 (`metadata.xml`)

META-INF資料夾裡若有選擇性的META-INF/metadata.xml檔案，則必需用於容器層級的詮釋資料。

若有metadata.xml檔案，其內容應該僅包含命名空間認可的元素 [XML-NAMES] 。該檔案應該包含根元素metadata，其命名空間為http://www.idpf.org/2013/metadata，但其他根元素可以用於向後相容目的。閱讀系統應該忽略根元素無法識別之metadata.xml。

本版本的OCF規格不定義供metadata.xml檔案使用的詮釋資料格式。容器層級的詮釋資料可以在本規格的未來版本以及EPUB延伸規格中定義。

3.5.2.5 權利管理檔案 (`rights.xml`)

META-INF資料夾裡選擇性的rights.xml為供數位權利管理（DRM）資訊所保留，目的為讓EPUB出版品能在權利人、中介與使用者間可被信任地傳遞。

本版本的OCF規格不要求特定格式的DRM資訊，但未來版本可能會要求。rights.xml的內容應該僅包含命名空間認可的元素 [XML-NAMES] ，以避免與未來的格式產生斷裂。

當rights.xml檔案不存在時，該容器中沒有任何部分在容器層級上受到權利管控。但權利表述可能存在於容納的內容釋義。

如果rights.xml不存在時，OCF抽象容器沒有任何部分受到權利管控。

3.5.2.6 數位簽章檔案 (`signatures.xml`)

注意事項

添加數位簽章並不保證EPUB檔案不受到變更，主要因為閱讀系統不被要求必須確認簽章。

META-INF資料夾裡選擇性的signatures.xml包含供容器與其內容的數位簽章。本檔案的內容必需合乎定義在「供signatures.xml使用的綱要」裡提供的綱要。

signatures.xml檔案的根元素為signatures元素。該元素包含類型子元素Signature如 [XMLDSIG-CORE1] 所定義。簽章可套用於一本EPUB出版品的整體或者其部分，並且可以指定用於簽署任何種類的資料（即為，不只是XML）。

當signatures.xml不存在時，該容器中沒有任何部分在容器層級上受到數位簽署。但EPUB出版品中可能存在數位簽署。

當資料簽章為該容器所創建，其簽章應該被加到signatures元素中最後一個子Signature元素。

注意事項

每一個在signatures.xml中的Signature由IRI所識別其簽章所適用的資料，使用 [XMLDSIG-CORE1] Manifest元素以及其Reference子元素。獨立涵蓋的檔案可以被分別或者一起簽署。對每個檔案個別簽署時會創建資源的摘要值以能被獨立驗證。這種方式會讓簽章元素變大。如果檔案被一起簽署，簽署檔案的集合可以被列於單一XML簽章Manifest元素以讓一或多個Signature元素參照。

所有位於容器中的檔案都可以被完整簽署，除了自身包含計算過的簽章資訊的signatures.xml檔案。不管signatures.xml如何被簽署或者簽署者的目的為何。

當簽署者想要為容器允許加入或者移除簽章，卻沒有無效化簽署者簽章時，signatures.xml不應被簽署。

如果簽署者想要對添加或者移除簽章以無效化簽署者的簽章時，可應用定義於6.6.4節中 [XMLDSIG-CORE1] 的Enveloped Signature transform以簽署整個預先存在的簽署檔，而非創建Signature。這種變形手段可以簽署所有之前的簽章，而在後續簽章加入套件時會變成無效。

注意事項

如果簽署者想要移除既有的簽章使簽署者的簽章無效化，但也希望能夠允許添加簽章，可以適用XPath transform來僅對存在的簽章進行簽署。然而，像這樣變形的細節在本規格的目的之外。

[XMLDSIG-CORE1] 規格與簽章的沒有任何語意關聯，使用者端可以包含語意資訊，例如，在簽章元素加入資訊來說明該簽章。 [XMLDSIG-CORE1] 規格解釋如何為簽章加入額外資訊，例如使用SignatureProperties元素。

範例7

以下XML表述呈現一個signatures.xml檔案範例，其基於第2章 [XMLDSIG-CORE1] 中的範例。其包含一個簽章，該簽章適用於兩個容器中的資源EPUB/book.xhtml與EPUB/images/cover.jpeg。

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <Signature Id="sig" xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod 
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
            <Reference URI="#Manifest1">
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>…</SignatureValue>
        <KeyInfo>
            <KeyValue>
                <DSAKeyValue>
                    <P>…</P><Q>…</Q><G>…</G><Y>…</Y> 
                </DSAKeyValue>
            </KeyValue>
        </KeyInfo>
        <Object>
            <Manifest Id="Manifest1">
                <Reference URI="EPUB/book.xhtml">                    
                    <Transforms>                                                
                        <Transform
                            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>                        
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="EPUB/images/cover.jpeg">
                    <Transforms>                                                
                        <Transform
                            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>                        
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
            </Manifest>
        </Object>
    </Signature> 
</signatures>

5. 資源模糊化

5.1 導論

本章節為非規範性。

由於OCF ZIP容器基本上是一個ZIP檔案，一般常見的ZIP工具都可以用於從其包裝中解壓縮未加密的內容流。此外，ZIP檔案的特性表示其內容可以如其他原生容器在一些系統上（例如，資料夾）顯示。

ZIP檔案的單純很便於使用，但也產生了一個問題，不加密的副作用是易於提取資源，而這不是期盼的結果。例如，作者想要包含第三方字體時，一般不會希望字體被解壓縮並且被其他人使用。更重要的是，許多商用字體允許被嵌入，但嵌入字體即代表其為EPUB出版品整體的一部分，不只是隨著內容提供其原始字體。

雖然現在作業系統普遍整合了ZIP支援，但只是把字體置放到ZIP封裝並不足以表示其不想被用於其他脈絡的意圖。這種不確定性會損害EPUB出版品中相當有用的嵌入字體能耐。

為了避免字體受到使用，有些字體提供者可能僅會在以某些方法與EPUB出版品連結的狀況下，才允許使用它們的字體於EPUB出版品。即為，當字型檔案不能以預設工具被直接安裝在裝置中供作業系統使用，也不能被其他EPUB出版品所直接使用。

提供數位權利管理或者強制系統供這些資源使用超過本規格的目標。本章節則以定義模糊化的方法取代，其需要花額外的功夫在最終OCF收受端以增加對任何模糊化資源的一般性存取。

請注意，本規格並不將其宣稱為加密，也不能保障資源安全無虞不受侵權。然而，僅希望這項演算法將會符合多數提供者希望為其資源提供一些保障，而不會簡單地透過對容器解壓縮就能取出。

在字體的案例中，主要使用的方法是模糊化，定義的機制將簡單地提供阻擋方式來避免人們沒有注意到授權細節。其將無法避免有意圖的使用者獲得對字體的完整存取權。對該OCF容器而言，則可以套用該定義的演算法來取出原始字型檔案。本模糊手段是否能滿足個別字體的授權，依然還需詢問授權者與被授權者。

5.2 模糊化密鑰

用於模糊化演算法的密鑰，由預設內容釋義的獨特識別碼所取得。

所有空白字元，如XML 1.0規格中2.3節 [XML] 所定義，必需由識別碼中移除 — 尤其是Unicode碼點U+0020、U+0009、U+000D與U+000A。

UTF-8表意的SHA-1摘要結果字串應該被取得以被安全雜湊標準（Secure Hash Standard） [FIPS-180-4] 所指定。其摘要即直接作為演算法密鑰使用。

5.3 模糊化演算法

部署供模糊化資源的演算法固定調整最初檔案的1040位元組（~1KB）。在罕見的狀態下，檔案小於1040位元組時，則整個檔案都會變動。

為了模糊化原始資料，結論上使用邏輯互斥或（logical exclusive or, XOR）於原始檔案的第一個位元組，以及將模糊化密鑰的第一個位元組儲存作為嵌入資源的第一個位元組。

本程序將逐來源檔案和密鑰的位元組重複，持續到所有密鑰的位元組都被使用完畢。此時，處理將會繼續從密鑰的第一個位元組與來源的第21個位元組開始。當1040個位元組以這種方式編碼後（或者到達來源的結束時），任何來源中剩下的資料都將直接複製到結果檔。

資源模糊化必需發生早於壓縮及加入OCF容器前。請注意模糊化不是加密，本需求不會違反加密檔案（encryption.xml）在加密前先壓縮資源的規則。

範例8

以下假代碼展示了模糊化演算法。

set ocf to OCF container file
set source to file
set destination to obfuscated file
set keyData to key for file
set outer to 0
while outer < 52 and not (source at EOF)
    set inner to 0
    while inner < 20 and not (source at EOF)
        read 1 byte from source     //Assumes read advances file position
        set sourceByte to result of read
        set keyByte to byte inner of keyData
        set obfuscatedByte to (sourceByte XOR keyByte)
        write obfuscatedByte to destination
        increment inner
    end while
    increment outer
end while
if not (source at EOF) then
    read source to EOF
    write result of read to destination
end if
Deflate destination
store destination as source in ocf

為了恢復成原來的字型檔案，程序僅要簡單地反向進行：來源檔案變成模糊化資料，而其結果檔案將包含原始資料。

注意事項

對字體的模糊化早在EPUB 3.0.1版就已經允許使用，但沒有指定模糊化與壓縮的順序。結果而言，在解壓縮與去模糊化後可能會得到不合規的字體。在這些狀況下，在解壓縮前對資料進行去模糊化可能取得合規的字體。本規格不要求對這種逆向方法的支援，原因是不適用本版本規格，但其可能需要納入對EPUB 3內容的一般支援。

5.4 指定模糊化資源

儘管技術上並非對資料加密，所有模糊化資源必需在該EPUB出版品中的encryption.xml檔案中登錄（請見加密檔案（encryption.xml））。

EncryptedData元素必需包含每一個模糊化資源。每一個EncryptedData元素必需包含一個EncryptionMethod子元素，其Algorithm屬性之值設定為http://www.idpf.org/2008/embedding。這項屬性出現代表使用本規格所闡釋的演算法。對模糊化資源的路徑必需被列於CipherData元素中的 CipherReference子元素。

範例9

以下範例顯示一筆在encryption.xml檔案裡的模糊化字型資料。

<encryption 
    xmlns="urn:oasis:names:tc:opendocument:xmlns:container" 
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <enc:EncryptedData> 
        <enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding"/> 
        <enc:CipherData> 
            <enc:CipherReference URI="EPUB/Fonts/BKANT.TTF"/>  
        </enc:CipherData> 
    </enc:EncryptedData>  
</encryption>

為了避免無意義地複製嵌入資源到其他EPUB出版品，模糊化密鑰不得在encryption.xml檔案中提供。

B. 範例

本章節為非規範性。

以下範例示範了使用OCF格式於 OCF ZIP容器中包含簽署及加密的EPUB出版品。

範例10

OCF ZIP容器中依序排列的檔案列表

mimetype
META-INF/container.xml
META-INF/signatures.xml
META-INF/encryption.xml
EPUB/As_You_Like_It.opf
EPUB/book.html
EPUB/nav.html
EPUB/images/cover.png

範例11

mimetype檔案的內容

application/epub+zip

範例12

META-INF/container.xml檔案的內容

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/As_You_Like_It.opf"
            media-type="application/oebps-package+xml"/>
    </rootfiles>
</container>

範例13

META-INF/signatures.xml檔案的內容

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <Signature Id="AsYouLikeItSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
        
        <!--
             SignedInfo is the information that is actually signed.
             In this case, the SHA-1 algorithm is used to sign the 
             canonical form of the XML documents enumerated in the
             Object element below.
        -->
        <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
            <Reference URI="#AsYouLikeIt">
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>…</DigestValue>
            </Reference>
        </SignedInfo>
        
        <!--
             The signed value of the digest above, using the DSA 
             algorithm
        -->
        <SignatureValue>…</SignatureValue>
        
        <!--
             The key used to validate the signature
        -->
        <KeyInfo>
            <KeyValue>
                <DSAKeyValue>
                    <P>…</P>
                    <Q>…</Q>
                    <G>…</G>
                    <Y>…</Y>
                </DSAKeyValue>
            </KeyValue>
        </KeyInfo>
        
        <!--
             The list of resources to sign (note that the canonical
             form of XML documents is signed, while the binary form
             of all other resources is used)
        -->
        <Object>
            <Manifest Id="AsYouLikeIt">
                <Reference URI="EPUB/As_You_Like_It.opf">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="EPUB/book.html">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="EPUB/images/cover.png">
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
            </Manifest>
        </Object>
    </Signature>
</signatures>

範例14

META-INF/encryption.xml檔案的內容

<?xml version="1.0"?>
<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <!--
         The RSA-encrypted AES-128 symmetric key used to encrypt
         data enumerated in EncryptedData blocks below
    -->
    <enc:EncryptedKey Id="EK">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo>
            <ds:KeyName>John Smith</ds:KeyName>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherValue>xyzabc…</enc:CipherValue>
        </enc:CipherData>
    </enc:EncryptedKey>

    <!--
         Each EncryptedData block identifies a single resource
         that has been encrypted using the AES-128 algorithm.
         The data remains stored, in its encrypted form, in the
         original file within the container.
    -->
    <enc:EncryptedData Id="ED1">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="EPUB/book.html"/>
        </enc:CipherData>
    </enc:EncryptedData>

    <enc:EncryptedData Id="ED2">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="EPUB/images/cover.png"/>
        </enc:CipherData>
    </enc:EncryptedData>
</encryption>

範例15

EPUB/As_You_Like_It.opf檔案的內容

<?xml version="1.0"?>
<package version="3.0"
         xml:lang="en"
         xmlns="http://www.idpf.org/2007/opf"
         unique-identifier="pub-id">
    
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="pub-id">urn:uuid:B9B412F2-CAAD-4A44-B91F-A375068478A0</dc:identifier>
        
        <dc:language>en</dc:language>
        
        <dc:title>As You Like It</dc:title>
        
        <dc:creator id="creator">William Shakespeare</dc:creator>
        
        <meta property="dcterms:modified">2000-03-24T00:00:00Z</meta>
        
        <dc:publisher>Project Gutenberg</dc:publisher>
        
        <dc:date>2000-03-24</dc:date>
        
        <meta property="dcterms:dateCopyrighted">9999-01-01</meta>
        
        <dc:identifier id="isbn13">urn:isbn:9780741014559</dc:identifier>
        
        <dc:identifier id="isbn10">0-7410-1455-6</dc:identifier>
        
        <link rel="xml-signature"
              href="../META-INF/signatures.xml#AsYouLikeItSignature"/>
    </metadata>
    
    <manifest>
        <item id="r4915" 
              href="book.html" 
              media-type="application/xhtml+xml"/>
        <item id="r7184" 
              href="images/cover.png" 
              media-type="image/png"/>
        <item id="nav" 
              href="nav.html" 
              media-type="application/xhtml+xml" 
              properties="nav"/>
    </manifest>
    
    <spine>
        <itemref idref="r4915"/>
    </spine>
</package>

EPUB開放容器格式（Open Container Format, OCF) 3.2

最終社群小組規格 08 May 2019

概要

本文件狀態

1. 導論

1.1 術語

1.2 適用性

2. OCF適用性

2.1 容器適用性

2.2 閱讀系統適用性

3. OCF抽象容器

3.1 導論

3.2 檔案與目錄結構

3.3 參照其他元件時相對IRI

3.4 檔案名稱

3.5 META-INF資料夾

3.5.1 內含物

3.5.2 保留的檔案

3.5.2.1 容器檔案 (container.xml)

3.5.2.2 加密檔案 (encryption.xml)

3.5.2.2.1 壓縮與加密順序

3.5.2.3 宣告檔案 (manifest.xml)

3.5.2.4 詮釋資料檔案 (metadata.xml)

3.5.2.5 權利管理檔案 (rights.xml)

3.5.2.6 數位簽章檔案 (signatures.xml)

4. OCF ZIP容器

4.1 導論

4.2 ZIP檔案需求

4.3 OCF ZIP容器媒體類型識別

5. 資源模糊化

5.1 導論

5.2 模糊化密鑰

5.3 模糊化演算法

5.4 指定模糊化資源

A. 綱要（Schemas）

A.1 供container.xml使用的綱要

A.2 供encryption.xml使用的綱要

A.3 供signatures.xml使用的綱要

B. 範例

C. application/epub+zip媒體類型

D. 謝詞與貢獻者

E. 參考資料

E.1 規範性文件

E.2 參考性文件

3.5 `META-INF`資料夾

3.5.2.1 容器檔案 (`container.xml`)

3.5.2.2 加密檔案 (`encryption.xml`)

3.5.2.3 宣告檔案 (`manifest.xml`)

3.5.2.4 詮釋資料檔案 (`metadata.xml`)

3.5.2.5 權利管理檔案 (`rights.xml`)

3.5.2.6 數位簽章檔案 (`signatures.xml`)

A.1 供`container.xml`使用的綱要

A.2 供`encryption.xml`使用的綱要

A.3 供`signatures.xml`使用的綱要

C. `application/epub+zip`媒體類型