この文書は「EPUB Open Container Format (OCF) 3.0.1」の日本語訳である。最新の文書は http://www.idpf.org/epub3/latest/ocf である。原文もしくは完全な情報は、 EPUB Open Container Format (OCF) 3.0.1 を参照されたい。
この日本語訳は参考である。公式な文書ではなく、翻訳・解釈の正確性を保証していない。
1.2. 用語にあげられている名称は本文中でも基本的に原文のままとした。
2014年6月26日 Recommended Specification
以前のドラフトからの変更点の差分もまた利用できる。
この文書（いくらかの規範的な訂正を含むかもしれない）のために、正誤表を参照されたい。
Copyright © 2010-2013 International Digital Publishing Forum™
無断複写・転載を禁止する。本作品は合衆国法典第17編の下に保護されている。変更を伴うこの著作物の複製と頒布は、International Digital Publishing Forum (IDPF) の書面による許可を得ない限り禁止されている。
EPUBは International Digital Publishing Forum の登録商標である。
目次
このセクションは有益な情報である。
この仕様、EPUB Open Container Format (OCF) 3.0.1 は、単一ファイルのコンテナにひとつ以上の EPUB® Publication を構成する関連リソースのセットをカプセル化するためのファイル形式と処理モデルを定義する。
この仕様は EPUB 3、XML および Web 標準に基づいて、デジタル出版物の交換や配信形式の第 3 版を構成する関連仕様のファミリーのひとつである。それは EPUB 3 を構成する他の仕様を読み、調和して理解されることになっている：
EPUB 3 Overview [EPUB3Overview] は EPUB 3 文書の残りの部分に EPUB の有益な概要とロードマップを提供する。EPUB 3 Overview は最初に読んでおくべきである（should）。
EPUB Publications 3.0.1 [Publications301] セマンティクスとEPUB 出版物の各 Rendition のための包括的な適合性要件を定義する。
EPUB Content Documents 3.0.1 [ContentDocs301] はEPUB 出版物のコンテキストで使用するための XHTML、SVG と CSS のプロファイルを定義する。
EPUB Media Overlays 3.0.1 [MediaOverlays301] はフォーマットとテキストとオーディオの同期のための処理モデルを定義する。
OCF は、EPUB 出版物に必要なコンテナ技術である。OCF は、以下のワークフローの役割を果たしてもよい（may）：
EPUB 出版物を作り出す準備手順の間に、OCF は、異なる個人と（または）異なる団体の間で進行中の出版物を交換する時に、コンテナフォーマットを使用してもよい（may）。
出版社や変換企業から流通や販売チャンネルまで、EPUB 出版物を提供する場合、OCF は、転送フォーマットとして使用するのに推奨されるコンテナフォーマットである。
EPUB リーディングシステムや読者に最終的な EPUB 出版物を交付する時、OCF は、EPUB 出版物を構成する資源の全てを保持するコンテナとして必須のフォーマットである。
OCF 仕様書は、抽象的なファイルコレクションを構造化のための規則である“抽象コンテナ”を定義する。それはまた、ZIP アーカイブ内のこの抽象コンテナを表現するための規則である“物理コンテナ”を定義する。ZIP の物理コンテナのための規則は、[ODF] によって使用される ZIP 技術に基いて構築される。OCF は、この機能を必要とする EPUB 出版物のために、埋め込んだリソース、例えばフォントなどを難読化をする方法を定義する。
この仕様は Open Container Format (OCF) 3.0 [OCF30] に取って代わる。この仕様書と前身の違いについては [EPUB3Changes] を参照されたい。
この仕様と兄弟仕様に準拠したひとつ以上の Rendition のコレクションは、EPUB Container をパッケージ化している。
EPUB 出版物は典型的に単一の知的・芸術作品を表しているが、この仕様と兄弟仕様は、コンテンツの性質を制限しない。
コンテンツまたは EPUB 出版物の少なくともひとつの Rendition のロジックと表示に関する命令を含んでいるリソース。このリソースがない場合には、EPUB 出版物は 製作者の意図したとおりに表示されないことがある。Publication Resource の例としては Rendition の Package Document、EPUB Content Document、EPUB Style Sheet、音声、動画、画像、埋め込みフォントとスクリプトが包含される。
Package Document 自身を除いて、Rendition をレンダリングするために必要な Publication Resource は Rendition の manifest [Publications301] に記載され、（Publication Resource の位置 [Publications301] で特に指定がない限り）EPUB Container ファイルにバンドルする。
Publication Resource でないリソースの例としては、Package Document の link 要素 [Publications301] で識別されるものと EPUB Container の外で解決する外部へのハイパーリンクで識別されるものが包含されている（例えば [HTML5] の a 要素の href 属性）。
EPUB Content Document の定義（XHTML または SVG）のひとつに従う Publication Resource。
EPUB Content Document は Core Media Type であるためフォールバック [Publications301] を提供することなく、EPUB 出版物に含まれていてもよい（may）。
XHTML Content Documents [ContentDocs301] で定義されている [HTML5] のプロファイルに準拠する EPUB Content Document。
XHTML Content Document は、[HTML5] の XHTML syntax を使用する。
SVG Content Documents [ContentDocs301] で表現された制約に準拠した EPUB Content Document。
Publication Resource 型のセットは、それに対するフォールバックは必須ではない。詳細については Publication Resources [Publications301] を参照されたい。
EPUB 出版物の特定の Rendition について Package Documents [Publications301] で定められいる文献の構造化メタデータをもたらしている Publication Resource。
unique-identifier 属性によって識別される Unique Identifier は EPUB 出版物のための主要な識別子である。Unique Identifier は一つまたは複数の EPUB standard に従って同じ EPUB 出版物の Rendition によって共有されてもよい（may）。
Unique Identifier は ISBN よりも細分化される。しかしコンテンツの大幅な見直し、要訳などは新しい Unique Identifier が必要である。
CSS のプロファイルに準拠する CSS スタイルシートは EPUB Style Sheets [ContentDocs301] で定義されている。
EPUB 出版物の内容が視覚的に読者に与えられる EPUB リーディングシステムの領域。
OCF ZIP コンテナで定義されている EPUB 出版物用 ZIP ベースのパッケージングと配布のフォーマット。
本仕様書に従って EPUB コンテナを処理するソフトウェア・アプリケーション。
ルートディレクトリは、抽象コンテナファイルシステムの基点を表現する。このディレクトリは、性質上仮想で、リーディングシステムは、コンテンツが解凍されているとき、抽象コンテナのコンテンツのための物理的なルートディレクトリを生成するかもしれないし、しないかもしれない。
EPUB 出版物（必ずしも、それが含まれるコンテンツとリソースの作者であるというわけではありません）の制作に対して責任がある人または組織。
EPUB リーディングシステムを使用して EPUB 出版物を消費する個人。
次の表記上の規則は、この仕様に用いられる：
markupすべてのマークアップ（要素、属性、プロパティ）、コード（JavaScript、擬似コード）、機械処理可能な値（文字列、文字、メディアタイプ）とファイル名は、赤橙色の等幅フォントで示している。
markupマークアップとコードの定義へのリンクは、下線と赤橙色の等幅フォントで示している。各セクションの最初のインスタンスのみリンクがされている。
http://www.idpf.org/URI は紺色の等幅フォントで示している。
ハイパーリンクは、青い下線で示している。
規範的で参考情報は、角括弧で囲まれている。
用語集で定義されている用語は、キャピタルケースで示している。
用語の定義へのリンクはL、点線の青い下線である。各セクションの最初のインスタンスのみリンクがされている。
規範的な要素、属性とプロパティの定義は、青いボックスにある。
有益なマークアップ例は、白いボックス内にある。
有益な注記は、"Note"の見出しがある黄色いボックス内にある。
有益な警告は、"Caution"の見出しがある赤いボックス内にある。
この文書内のキーワード、must、must not、REQUIRED、SHALL、SHALL NOT、should、should not、RECOMMENDED、may、OPTIONAL は、[RFC2119] の記述に従って解釈される。
この仕様のすべてのセクションは規定ある。但し"このセクションは有益な情報である"という参考情報状態ラベルで識別される箇所を除く。セクションと付録への参考情報状態の適用は、含まれる可能性のあるすべての子コンテンツおよびサブセクションに適用される。
この仕様のすべての例は有益な参考情報である。
> OCF 抽象コンテナは、OCF 抽象コンテナで定義された適合性要件を満たさなければならない（must）。
> OCF ZIP コンテナ（また、EPUB Container と呼ばれる）は、OCF ZIP コンテナで定義された適合性要件を満たさなければならない（must）。
EPUB リーディングシステムは、以下の基準全てを満たさなければならない（must）：
> それは、OCF ZIP コンテナで表現されたすべてのリーディングシステムの適合性要件に適合する OCF ZIP コンテナを処理しなければならない（must）。
> それが Viewport を持つ場合、リソース難読化で定義されたリソースの解読をサポートしなければならない（must）。
このセクションは有益な情報である。
OCF 抽象コンテナは、コンテナのコンテンツのためのファイルシステムモデルを定義している。ファイルシステムモデルは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを使用する。埋め込まれた Rendition の（非リモートの）全てのリソースは、特定のファイルシステム構造はこのために強制はされないが、コンテナのルートディレクトリが率いるディレクトリツリー内に配置される。ファイルシステムモデルは、コンテナのルートディレクトリの直接の子で、以下の特別なファイルを補完するに利用する META-INF という名前の必須ディレクトリを包含する：
container.xml [必須] EPUB 出版物の埋め込まれた各 Rendition のエントリポイントであるファイルを識別する。
signatures.xml [省略可] 様々な資産のためのデジタル署名が含まれている。
encryption.xml [省略可] Publication Resource の暗号化に関する情報が含まれている。（このファイルは、難読化をするとき、必要である。）
metadata.xml [省略可] EPUB Container に関するメタデータを格納するために使用する。
rights.xml [省略可] デジタル著作権に関する情報を格納するために使用する。
manifest.xml [許可] Open Document Format [ODF] によって許可されるコンテナコンテンツのマニフェスト。
META-INF の各ファイルのための完全な適合性要件は、META-INF にある。
OCF 抽象コンテナのための仮想ファイルシステムは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを持たなければならない（must）。
OCF 抽象コンテナは、コンテナのルート・ディレクトリの直接の子である META-INF という名前のディレクトリを包含しなければならない（must）。このディレクトリのコンテンツのための要件は、META-INF に記載されている。
ルートディレクトリにあるファイル名の mimetype は、OCF ZIP コンテナで説明されているとおり、OCF ZIP コンテナによって使用するために予約済みである。
OCF 抽象コンテナ内の他の全てのファイルは、META-INF ディレクトリ内を除くコンテナのルートディレクトリから任意の場所の子孫でもよい（may）。
EPUB 出版物のコンテンツは、コンテナのルート配下の専用のディレクトリに格納されることを推奨する（recommended）。
OCF 抽象コンテナ内のファイルは、相対 IRI 参照 ([RFC3987] と [RFC3986])経由して相互に参照しなければならない（must）。例えば、chapter1.html という名前のファイルが、同じディレクトリにある image1.jpg という名前の画像ファイルを参照する場合、chapter1.html はそのコンテンツの一部として以下のように含めてもよい（may）：
<img src="image1.jpg" alt="…" />
相対 IRI 参照は、ベース IRI [RFC3986] に与えられたファイル形式に関連のある言語仕様によって決定される。例えば、CSS 仕様は、CSS スタイルシートとプロパティ宣言のコンテクストでどのように相対 IRI 参照が動作するのかを定義する。いくつかの言語仕様が、RFC3987 に先行した RFC を参照することに注意されたい。その場合、以前の RFC は、特定の言語でコンテンツに適用される。
ほとんどの言語仕様とは異なり、META-INF ディレクトリ内の全てのファイルのためのベース IRI は、初期設定のベース IRI として抽象コンテナのためにルートディレクトリを使用する。例えば、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/Great Expectations.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</container>この場合、EPUB/Great Expectations.opf のパスは OCF 抽象コンテナのためのルートディレクトリから相対であり、META-INF ディレクトリからの相対ではない。
File Name の用語は、ディレクトリまたは OCF 抽象コンテナのディレクトリ内の通常のファイルといった任意の型のファイルの名前を表現する。
OCF 抽象コンテナの特定のディレクトリの場合、Path Name は、ディレクトリのファイル名を分割する / (U+002F ) 文字と一緒に連結されたフルパス内にすべてのディレクトリのファイル名を保持する文字列である。OCF 抽象コンテナの特定のファイルの場合、パス名は、ディレクトリのファイル名を分割する / 文字と一緒に連結されたすべてのディレクトリのファイル名を保持する文字列に続いて、/ 文字とファイルのファイル名となっている。
後に説明するファイル名の制約は、最も一般的に使用されているオペレーティング・システム上で変更なしに使用されているパス名とファイル名を考慮にいれて設計されている。本仕様書は、OCF ファイルとパス名を表すことのできない OCF Processor の相互互換性を補う方法を指定しない。
OCF 抽象コンテナのコンテクストでは、ファイルとパス名は、以下の基準を満たさなければならない（must）：
> ファイル名は、255バイトを超えてはならない（must not）。
> 抽象コンテナ内の任意のディレクトリまたはファイルのパス名は、65535バイトを超えてはならない（must not）。
> ファイル名は、これらの文字は、一般的に使用されるオペレーティング・システムの間で一貫してサポートされない場合があり、以下の [Unicode] は使用してはならない（must not）：
スラッシュ: / (U+002F )
クォーテーションマーク: " (U+0022 )
アスタリスク: * (U+002A )
ピリオド: . (U+002E )
コロン: : (U+003A )
小なり記号: < (U+003C )
大なり記号: > (U+003E )
クエスチョンマーク: ? (U+003F )
バックスラッシュ: \ (U+005C )
DEL (U+007F )
C0 領域 (U+0000 … U+001F )
C1 領域 (U+0080 … U+009F )
私用領域 (U+E000 … U+F8FF )
アラビア表示形Aの非文字 (U+FDDO … U+FDEF )
特殊用途文字 (U+FFF0 … U+FFFF )
タグと異体字セレクタ補助 (U+E0000 … U+E0FFF )
補助私用領域A (U+F0000 … U+FFFFF )
補助私用領域B (U+100000 … U+10FFFF )
> ファイル名は、大文字と小文字が区別される。
> 同じディレクトリ内にあるすべてのファイル名は、[Unicode] のセクション 3.13 で定義されているような正規化のケースに従い一意でなければならない（must）。
> 同じディレクトリ内にあるすべてのファイル名は、NFC または NFD の正規化 [TR15] に従い一意であるべきである（should）。
いくつかの商用 ZIP ツールは、完全な Unicode の範囲をサポートしておらず、ファイル名のみ ASCII の範囲のみサポートするかもしれない（may）。これらの制限を持つ ZIP ツールを使うことを望むコンテンツ製作者は、ASCII の範囲にこれらのファイル名を制限することが最善であることに気づくかもしれない（may）。ファイルの名前は、解凍処理の中に保存することができない場合、そのファイルはコンテンツ内のURIにより参照されるときに行われた任意の名前に変換を相殺する必要がある。
全ての OCF 抽象コンテナは、META-INF というディレクトリを包含しなければならない（must）。このディレクトリは、以下に指定されているファイルを含む。以下に定義されている以外のファイルは、META-INF ディレクトリに包含してもよく（may）、OCF Processor は、そのようなファイルを検出したときに失敗してはならない（must not）。
全ての OCF コンテナは、META-INF ディレクトリ内に container.xml と呼ばれるファイルを包含しなければならない（must）。container.xml ファイルは、コンテナ内に包含されている EPUB 出版物の Rendition のそれぞれのルート・ファイルのメディアタイプとパスを識別しなければならない（must）。
container.xml ファイルは暗号化してはならない（must not）。
container.xml ファイルのスキーマは container.xml のためのスキーマで使用可能で、container.xml ファイルは、（このような要素のすべての属性と内容を含む）他の名前空間からのすべての要素と属性を除去した後に、このスキーマに応じて妥当でなければならない（must）。
rootfiles 要素は、ひとつ以上の rootfile 要素を含まなければならず（must）、それぞれは、一意に単一の EPUB の出版物 Rendition を表す Package Document を参照しなければならない（must）。複数の Rendition が OCF に格納されている場合、それぞれは同じ EPUB 出版物の異なるレンダリングでなければならない（must）。
OCF プロセッサは、含まれている EPUB 出版物の初期設定のレンダリングを表現するために rootfiles 要素内の最初の rootfile 要素を考慮しなければならない（must）。リーディングシステムは、初期設定以外の任意のレンダリングを使用することは必須ではない（not required）。
以下のサンプルは、ルートファイルの EPUB/My Crazy Life.opf (the Package Document) を持つ EPUB 出版物のためのサンプル container.xml を示している：
<?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>以下のサンプルは、同じコンテナ内にバンドルされている The Sandman の SVG と XHTML Rendition を示している：
<?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>Package Document 内に含まれる manifest 要素は、特定の Rendition の処理に使用される唯一無二のマニフェストを指定する。ZIP アーカイブ内またはオプションの manifest.xml ファイルに含まれている補助的なマニフェスト情報を、Rendition の処理のために使用してはならない（must not）。
ZIP アーカイブ内の任意の追加のファイルは、（すなわち、META-INF ファイルや出版物の他の Rendition を特定するリソースのように、Package Document の manifest 要素内にリストされていない ZIP アーカイブ内のファイルは）Rendition の処理に使用してはならない（must not）。
container.xml ファイルは、rootfiles 要素以下に links 要素を包含してもよく（may）、存在する場合、ひとつ以上の link 要素を含まなければならない（must）。各 link 要素は、値が、EPUB Container の処理のために必要なリソースの位置を識別する href 属性を包含しなければならない（must）。各 link 要素は、値が、リソースの関係性を識別する rel 属性もまた包含しなければならなず（must）、値が、link によって参照されたリソースの種類と形式を指定する media type [RFC2046] でなければならない（must） media-type 属性を包含してもよい（may）。
rootfile 要素の full-path 属性と link 要素の href 属性の値は、（RFC3986 で定義されている）path-rootless のみの形式から得なければならず（must）、（RFC 3986 で定義されている）path component を含まなければならない（must）。path component は、それらが使用されているコンテナのルートからの相対パスである。
OCF Processor は container.xml ファイル内にある外部の要素と属性を無視しなければならない（must）。
コンテナファイルシステムのルートレベルにある META-INF ディレクトリ内のオプションの encryption.xml ファイルは、コンテナのコンテンツの全ての暗号化情報を保持する。
コンテナ内の任意のリソースが暗号化されているとき、encryption.xml は、リソースが暗号化されていることを示し、暗号化されている方法の情報を提供するために存在していなければならない（must）。
このファイルは、ルート要素の encryption の XML 文書である。encryption 要素は、[XML ENC Core] で定義されている EncryptedKey と EncryptedData 型の子要素を含む。
それ故に、コンテナ内のいずれかのリソースが暗号化されているとき、encryption.xml は、リソースが暗号化されていることを示し、それが暗号化されている方法に関する情報を提供することを示さなければならない（must）。
EncryptedData 要素が、暗号化された各ファイルを説明するのと同時に、EncryptedKey 要素は、コンテナ内で使用される各暗号化キーを説明する。各 EncryptedData 要素は、XML Encryption で説明されているように、EncryptedKey 要素を参照する。
encryption.xml のスキーマは、encryption.xml のためのスキーマを使用でき、encryption.xml ファイルは、このスキーマに応じて妥当でなければならない（must）。
OCF は、独立して個々のファイルを暗号化し、これらはセキュリティとパフォーマンスのトレードオフだが、コンテナのコンテンツは一つ一つ復号化される。この方法による暗号化は、パッケージ全体のディレクトリの構造とファイルの命名を公開する。
OCF は、様々なアルゴリズムを使用できるように、暗号化のフレームワークを提供する XML Encryption [XML ENC Core] を使用する。XML Encryption は、任意のデータを暗号化し、結果を XML で表現するための処理を規定している。OCF 抽象コンテナは、非 XML データが含まれてもよく（may）、XML Encryption は、OCF 抽象コンテナに含まれるすべてのデータを暗号化するために使用できる。OCF 暗号化は、コンテナ内のファイル全体のみをサポートし、ファイルの一部の暗号化はサポートしない。encryption.xml ファイルは、（もし存在するなら）暗号化はしてはならない（must not）。
暗号化データは、OCF 抽象コンテナ内の非暗号化データを置き換える。photo.jpeg という名前の画像が暗号化されているとき、photo.jpeg リソースのコンテンツは、その暗号化されたコンテンツにより置き換えられるべきである（should）。ZIP コンテナに保持したとき、データのストリームは、暗号化する前に圧縮しなければならず（must）、デフレート圧縮を使用しなければならない（must）。ZIP ディレクトリ内では、暗号化されたフィルは、デフレートで圧縮するよりはむしろ格納するべきである（should）。
状況によっては、"親" の EPUB 出版物に繋ぎ、（例えば、フォントなどを）無制限に使用するための抽出をより困難にするために、Rendition によって参照される埋め込みリソースのストレージを難読化する必要があることに注意されたい。
難読化は暗号化ではないので、encryption.xml ファイルは、それらを使用する前に、難読化解除に必要なリソースを識別するために IDPF resource obfuscation algorithm と共に使用される。
以下のファイルは、初期設定か特定の暗号化が求められているかどうかに関わらず暗号化してはならない（must not）：
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 |
EPUB rootfile (the Package Document) |
署名済みリソースは、続けて XML 署名復号変換 [XML SIG Decrypt] を使用して暗号化してもよい（may）。この機能は、例えば署名後に暗号化したデータから署名する前に暗号化されたデータを識別する OCF エージェントなどのアプリケーションを可能にする。署名後に暗号化されたデータのみ、署名を検証するために使用する要約を計算する前に複合しなければならない（must）。
次の例では、[XML ENC Core] の Section 2.2.1 から適合したリソース image.jpeg は、対象鍵アルゴリズム (AES) を使用する暗号化と、対象鍵は、ジョン・スミスのキーを持つ非対称鍵アルゴリズム (RSA) を使用してさらに暗号化される。
<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>
manifest.xml という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF ディレクトリに包含してもよい（may）。
manifest.xml は、（ファイルが存在する場合）暗号化してはならない（must not）。
metadata.xml という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF ディレクトリに包含してもよい（may）。このファイルは、（もし存在するなら）コンテナレベルのメタデータのために使用しなければならない（must）。
META-INF/metadata.xml ファイルが存在するとき、そのコンテンツは、名前空間で装飾された要素 [XMLNS] のみにするべきである（should）。
ファイルは、名前空間 http://www.idpf.org/2013/metadata のルート要素 metadata を含むべきであるが（should）、他のルート要素は、後方互換性のために許可する。
リーディングシステムは、認識されていないルート要素を持つ metadata.xml ファイルを無視するべきである（should）。
OCF 仕様のこのバージョンは、metadata.xml ファイルで使用するためのメタデータを定義しない。Container-level のメタデータは、この仕様の将来のバージョンと IDPF が定義する EPUB 拡張仕様で定義してもよい（may）。
metadata.xml は、（ファイルが存在する場合）暗号化してはならない（must not）。
rights.xml という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF ディレクトリに包含してもよい（may）。このファイルは、権利者、仲介者、そして利用者の間で EPUB 出版物の交換のための信頼できるデジタル著作権管理 (DRM) 情報のために予約されている。OCF 仕様のこのバージョンでは、DRM 情報に必要な形式を指定しないが、将来のバージョンでは、DRM 情報の特定の形式を指定するかもしれない。
META-INF/rights.xml ファイルが存在するとき、そのコンテンツは、このファイルの特定のフォーマットを指定する OCF の将来のバージョンとの衝突を回避するため名前空間で装飾された要素 [XMLNS] にするべきである（should）。
rights.xml ファイルは、暗号化してはならない（must not）。
rights.xml ファイルが存在しないとき、OCF コンテナは、コンテナの任意の部分を示す情報を提供しない権利が抑制される。
コンテナファイルシステムのルートレベルにある META-INF ディレクトリ内のオプションの signatures.xml は、コンテナとコンテンツの電子署名を保持する。このファイルは、ルート要素の signatures の XML 文書である。signatures 要素は、[XML DSIG Core] で定義されている Signature 型の子要素を含んでいる。署名は、Rendition の全体または一部の EPUB 出版物の任意の Rendition に適用できる。XML Signature は、XML だけではなく、あらゆる種類のデータで署名を指定することができる。
signatures.xml ファイルは、暗号化してはならない（must not）。
signatures.xml ファイルが存在しないとき、OCF コンテナは、コンテナの任意の部分がコンテナレベルで電子署名されていることを示す情報を提供しない。しかしながら、それは、任意に含んでいる Rendition 内に電子署名が存在している可能性がある。
signatures.xml ファイルのスキーマは、signatures.xml のスキーマが利用でき、signatures.xml ファイルは、このスキーマに応じて妥当でなければならない（must）。
OCF エージェントが、コンテナ内のデータの署名を作るとき、それは、signatures.xml ファイル内に signatures 要素の最後の子 Signature 要素として新しい署名を加えるべきである（should）。
signatures.xml ファイルの各 Signature は、XML Signature の Manifest 要素とその Reference サブ要素を使用して、IRI の署名が適用されるデータによって識別される。単一で含まれるファイルは、個々にまたは統合して署名してもよい（may）。個々に署名された各ファイルは、独立して検証できるリソースのダイジェスト値が作られる。このアプローチでは、Signature 要素が大きくなってもよい（may）。ファイルが統合して署名されるとき、署名されたファイルのセットは、単一の XML Signature の Manifest 要素のリスト化され、一つ以上の Signature 要素によって参照することができる。
コンテナの任意または全てのファイルは、計算された署名情報を含んでいる signatures.xml ファイルを除外して、全体を署名することができる。signatures.xml ファイルを署名するべきか、またその署名方法は、署名者の目的に依存するべきである（should）。
署名者が署名者の署名を無効にせずにコンテナに署名を追加したり削除したりできるようにしたい場合は、signatures.xml ファイルに署名するべきではない（should not）。
署名者が署名の任意の追加または削除をしたときに署名者の署名を無効にしたい場合は、（[XML DSIG Core] のセクション 6.6.4 で定義されている）Enveloped Signature 変換を作成済みの Signature を除いた全体の既存の署名ファイルに署名するために使用することができる。この変換は、既存の全ての署名を署名できるだろうが、パッケージに後で署名が追加されると無効になる。
署名者が、既存の署名の削除時に署名者の署名を無効にしたいが、署名の追加は許したいとき、既存の署名を署名するのに XPath 変換を使用することができる。（これは単に提案である。特定の XPath 変換は、OCF 仕様書の一部ではない。）
XML-Signature は、署名に任意のセマンティクスを紐付けないが、エージェントが、例えば、署名を表現する Signature 要素に情報を加えることにより、セマンティクスな情報を包含してもよい（may）。XML Signature は、追加情報を、（例えば、SignatureProperties 要素を使うことによる）署名に追加する方法を説明する。
以下の XML 表現は、signatures.xml フィルの例のコンテンツを示し、[XML DSIG Core] のセクション 2 で見つかるサンプルを基にしている。それはコンテナに、一つの署名を含んでおり、署名は、OEBFPS/book.html と OEBFPS/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="OEBFPS/book.xml">
<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="OEBFPS/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>
OCF ZIP コンテナは、[ZIP APPNOTE 6.3.3] によって規定されているような ZIP 形式を使用するが、以下の制約と説明に従う：
> OCF ZIP コンテナは、ZIP ファイルが複数のストレージメディアを横断するために分割を許可している ZIP アプリケーションノートの機能を使用してはならない（must not）。OCF Processor は、複数のストレージメディアを横断するよう分割している ZIP ファイルであることが明らかな任意の OCF ファイルをエラーとして処理しなければならない（must）。
> OCF ZIP コンテナは、ZIP アーカイブに（未圧縮で）格納またはデフレート圧縮した ZIP エントリーのみ包含しなければならない（must）。OCF Processor は、デフレート以外の圧縮技術を使用している任意の OCF コンテナをエラーとして処理しなければならない（must）。
> OCF ZIP コンテナは、[ZIP APPNOTE 6.3.3] のアプリケーションノートのサブセクション G に、セクション V の "Version 1" として定義されている ZIP64 拡張を使用してもよく（may）、コンテンツがそれらを要求するとき、それらの拡張のみ使用するべきである（should）。OCF Processor は、"Version 1" として定義されている ZIP64 拡張をサポートしなければならない（must）。
> OCF ZIP コンテナは、ZIP フォーマットにより定義された暗号化機能を使用してはならず（must not）、代わりに、暗号化は、暗号化 - META-INF/encryption.xml で説明されている機能を使用しなければならない（must）。OCF Processor は、ZIP 暗号化機能を使用している任意の他の OCF ZIP コンテナをエラーとして処理しなければならない（must）。
> OCF Processor は、OCF 抽象コンテナで定義されていない読み込みと保存の操作を通じて OCF ZIP コンテナからの情報を保つことを要求しない。具体的には、OCF Processor は、特定のオペレーティングシステム（例えば、External file attributes と Extra field など）に対応するファイルシステム情報を保持する CRC 値、コメントフィールド、フィールドを保存しない。
> OCF ZIP コンテナは、UTF-8 [Unicode] を使用してファイルシステム名をエンコードしなければならない（must）。
以下の制約は、OCF ZIP コンテナアーカイブ内の特定のフィールドに適用する：
> ローカルファイルヘッダーテーブルでは、OCF ZIP コンテナは、特定のファイルにより必要とされる最大バージョンレベルに合わせるために、version needed to extract フィールドの値を 10 、20 、45 に設定しなければならない（must）。（例えば、デフレートが必要な場合は 20 、ZIP64 が必要な場合は 45 ）。OCF Processor は、他の任意の値をエラーとして処理しなければならない（must）。
> ローカルファイルヘッダーテーブルでは、OCF ZIP コンテナは compression メソッドフィールドの値を 0 か 8 に設定しなければならない（must）。OCF Processor は、他の任意の値をエラーとして処理しなければならない（must）。
> OCF Processor は、Archive decryption header または Archive extra data record を持つ OCF ZIP コンテナをエラーとして処理しなければならない（must）。
OCF ZIP コンテナは、コンテナ内に最初のファイルとして mimetype ファイルを包含しなければならなず（must）、このファイルのコンテンツは、US-ASCII [US-ASCII] でエンコードされた application/epub+zip 文字列の MIME タイプでなければならない（must）。
mimetype ファイルのコンテンツは、どんな文字埋めや空白を含んではならず（must not）、Unicode signature (または Byte Order Mark) で開始してはならず（must not）、そしてMIME タイプ 文字列の大文字と小文字は、上記の通り正確でなければならない（must）。さらに mimetype ファイルは、圧縮または暗号化をしてはならず（must）、そして ZIP ヘッダにエキストラフィールドがあってはならない（must not）。
application/epub+zip メディアタイプについてのより詳細な情報は 付録 C, application/epub+zip Media Type を参照されたい。
このセクションは有益な情報である。
OCF ZIP コンテナは、基本的に ZIP ファイルなので、一般的に入手可能な ZIP ツールを、パッケージから任意の非暗号化したコンテンツストリームを抽出するのに使用できる。 また、ZIP ファイルの性質は、その内容が一部のシステム上の任意の他のネイティブコンテナ（例えば、フォルダなど）に表示されてもい（may）ことを意味する。
この ZIP ファイルの単純さは非常に便利だが、それはまたリソースを抽出する容易さは、暗号化していないリソースの予期しない副作用の問題を引き起こす。サードパーティ製フォントの包含したい製作者は、例えば、典型的にフォントが他人によって抽出され再利用されるのを望まない。 より重要なことは、多くの商業フォントは埋め込みを許可しているが、フォントの埋め込むことは、単にコンテンツと一緒にオリジナルのフォントファイルを提供せず、出版物の重要な部分を形成していることを意味する。
統合された ZIP のサポートは、現代的なオペレーティングシステムに偏在しおり、ZIP アーカイブ内に単純に配置したフォントは、他のコンテクストで再利用されることは意図しないフォントであることを意味するには不十分である。 この不確定要素は、他の非常に便利な EPUB 出版物のフォント埋め込みの機能を弱めることができる。
フォントの再利用を防ぐために、多くのフォントベンダーは、もしそれらのフォントが、出版物に何らかの方法で固定化されている場合、EPUB 出版物内のこれらのフォントの使用のみ許可するかもしれない（may）。 フォントファイルが、コンピュータデバイスの組み込みツールを使ってオペレーショングシステム上で使用するため直接インストールできないならば、他の EPUB 出版物によって直接使用することはできない。
そのようなリソースのためのデジタル著作権管理や施工システムを提供することはこの仕様の範囲を超える。このセクションは、任意の難読化したリソースへの一般的なアクセスを得るための最終的な OCF 受容者側の追加の作業として必要になる難読化の方法を定義する。
この仕様や IDPF によって作られた要求ではなく、これが暗号化を構成するわけでも、リソースが著作権侵害から安全であることを保証するわけでもないことに注意されたい。しかしながら、このアルゴリズムが、コンテナを解凍することによってそれらのリソースを簡単に抽出できないようにするいくつかの保証を求める多くのベンダーの要求を満たすであろうというのが IDPF の期待である。
フォントの場合、暗号化のための主要なユースケースは、定義されたメカニズムは、ライセンスの詳細に気付いていない人に障害を提供する。これは、フォントへの完全なアクセスを得ようと考えているユーザーは防げないだろう。OCF コンテナが提供されると、RAW フォントファイルを抽出するために定義したアルゴリズムを適応することが可能である。難読化のこの方法は、個々のフォントライセンスの要件を満たすかどうかに関わらず、使用許諾者や被許諾者の課題が残る。
難読化アルゴリズムに用いられるキーは、Default Rendition の一意識別子から得られる。
XML 1.0 仕様書 [XML] のセクション 2.3 によって定義されている全ての空白文字、具体的には Unicode コードポイント U+0020 、U+0009、U+000D と U+000A は、この識別子から削除されなければならない（must）。
結果として生じる文字列の UTF-8 表現の SHA-1 ダイジェストは、Secure Hash Standard [SHA-1] で規定されているように生成するべきである（should）。 このダイジェストは、その後、アルゴリズムのためのキーとして直接使用される。
アルゴリズムは、リソースを難読化するために、ファイルの最初の 1040 バイト (~1KB) の変更から成る。 万一、ファイルが 1040 バイト に満たない場合、ファイル全体が変更される。
元データを難読化するのに、RAW ファイルの最初のバイトと難読化キーの最初のバイトの排他的論理和（XOR）の計算の結果は、埋め込まれたリソースの最初のバイトとして格納される。
この処理は、ソースとキーの次のバイトで繰り返され、キー内の全てのバイトが使用されるまで続く。 ここで、キーの最初のバイトとソースの 21 バイト目から処理が始まり継続する。 1040 バイトがこの方法で（またはソースの終わりに到達して）エンコードされたら、ソース内の残りのデータは、格納先に直接コピーされる。
リソースの難読化は、それらが圧縮または OCF Container に追加される前に生じなければならない（must）。 難読化は暗号化ではなく、この要件は、それらを暗号化する前にリソースを圧縮する Encryption - META-INF/encryption.xml のひとつに違反しないことに注意されたい。
次の擬似コードは、難読化アルゴリズムを示している。
set ocf to OCF container 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
元のフォントデータを得るには、処理は単純に逆になり、ソースファイルは、難読化データと RAW データが格納されている格納先のファイルからなる。
フォントの難読化は、EPUB 3.0.1 で先行して許可されるが、難読化と圧縮の順序は指定しない。その結果、無効なフォントは、圧縮解除と難読化解除の後に遭遇するであろう。このような場合、伸張する前の難読化解除データは、妥当なフォントを返してもよい（may）。復旧のこの方法のサポートは、この仕様のこのバージョンで対応していないので省略可能だが、一般的には EPUB 3 コンテンツをサポートするときに考慮する必要がある。
すべての難読化リソースは、技術的には暗号化データではないけれど、EPUB 出版物に添付する encryption.xml ファイル（暗号化 - META-INF/encryption.xml を参照）に記入しなければならない（must）。
EncryptionMethod 要素は、各難読化リソースのために包含されなければならない（must）。
それぞれが、値に http://www.idpf.org/2008/embedding を設定された Algorithm 属性を EncryptedData 要素の子に包含しなければならない（must）。
この属性の存在は、本仕様書に記載されているアルゴリズムの使用を示している。
難読化リソースへのパスは、CipherData 要素の子の CipherReference に記載しなければならない（must）。
次の例は、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 ファイルに提供してはならない（must not）。
container.xml のスキーマcontainer.xml ファイルのスキーマは、http://www.idpf.org/epub/301/schema/ocf-container-30.rnc が利用可能である。
このスキーマを使用する検証は [RelaxNG] と [XSD-DATATYPES] をサポートするプロセッサが必要になる。
encryption.xml のスキーマencryption.xml ファイルのスキーマは、[XML Sec RNG Schemas] に包含されている。
signatures.xml のスキーマsignatures.xml ファイルのスキーマは、[XML Sec RNG Schemas] に包含されている。
この付録内のスキーマは、規範である。
次の例は、ZIP コンテナ内の署名と暗号化された EPUB 出版物を含むための、OCF フォーマットを使用した実例である。
用例 B.1. 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/toc.ncx EPUB/images/cover.png
用例 B.3. 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>
用例 B.4. 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 SHA1 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 to use to validate the signature -->
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>…</P>
<Q>…</Q>
<G>…</G>
<Y>…</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
<!-- The list documents to sign. Note that the canonical form of XML -->
<!-- documents is signed while the binary form of the other documents -->
<!-- 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>
用例 B.5. 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 the data -->
<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 document that has been -->
<!-- encrypted using the AES-128 algorithm. The data remains stored in it’s -->
<!-- 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>
用例 B.6. 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>
<meta refines="#pub-id"
property="identifier-type"
scheme="xsd:string">uuid</meta>
<dc:language>en</dc:language>
<dc:title>As You Like It</dc:title>
<dc:creator id="creator">William Shakespeare</dc:creator>
<meta refines="#creator"
property="role"
scheme="marc:relators">aut</meta>
<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>
<meta refines="#isbn13"
property="identifier-type"
scheme="onix:codelist5">15</meta>
<dc:identifier id="isbn10">0-7410-1455-6</dc:identifier>
<meta refines="#isbn10"
property="identifier-type"
scheme="onix:codelist5">2</meta>
<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"/>
<item id="ncx"
href="toc.ncx"
media-type="application/x-dtbncx+xml"/>
</manifest>
<spine toc="ncx">
<itemref idref="r4915"/>
</spine>
</package>
application/epub+zip メディアタイプこの付録は有益な情報である。
この付録は、EPUB Open Container Format (OCF) のメディアタイプ application/epub+zip を登録している。
OCF ファイルは、ZIP アーカイブ形式に基づくコンテナの技術である。それは、EPUB 出版物の Rendition をカプセルに包むために使用する。OCF とその関連規格は、International Digital Publishing Forum (IDPF) によって維持・定義される。
application
epub+zip
なし。
なし。
OCF ファイルは、ZIP (http://www.iana.org/assignments/media-types/application/zip) 形式のバイナリファイルである。
OCF ファイルを読む全てのプロセッサは、検索されたデータのサイズと妥当性を厳密にチェックするべきである（should）。
さらに、OCF ファイルに埋め込むことのできる様々なコンテンツタイプのために、application/epub+zip が、ここに説明されたものを超えてセキュリティについての暗黙の意味をコンテンツに表現してもよい（may）。けれども、プロセッサが、追加コンテンツまたは他のプロセッサによって送られるコンテツの処理を認識・処理するばあいには、セキュリティの問題は潜在的に生じる。またその場合、それらは、この登録文書の範囲から外れるであろう。
application/zip に適用されるセキュリティの考慮は、OCF ファイルにも適用される。
なし。
このメディアタイプの登録は、http://www.idpf.org/epub/30/spec/epub30-ocf.html にある EPUB Open Container Format (OCF) 3.0 仕様書で説明されている EPUB Open Container Format (OCF) のためのものである。
EPUB OCF 3.0 仕様書は、http://www.idpf.org/doc_library/epub/ocf_2.0.1_draft.doc にあり、application/epub+zip メディアタイプとして使用する Open Container Format 2.0.1 仕様書に優先する。
このメディアタイプは、EPUB 形式の電子書籍の配布のために広く使われている。以下のアプリケーションのリストは、完全ではない。
Adobe Digital Editions
Aldiko
Azardi
Apple iBooks
Barnes & Noble Nook
Calibre
Google Books
Ibis Reader
MobiPocket reader
Sony Reader
Stanza
0: PK 0x03 0x04 , 30: mimetype , 38: application/epub+zip
OCF ファイルは、ほとんどの場合、.epub の拡張として識別される。
ZIP
IDPF は、http://www.idpf.org/epub/linking/ でリンクしているスキームの登録を維持する。このスキームの一部は、application/epub+zip と application/oebps-package+xml 文書を解決するカスタムフラグメント識別子を定義している。
William McCoy, bmccoy@idpf.org
COMMON
International Digital Publishing Forum (http://www.idpf.org)
この付録は有益な情報である。
EPUB は、出版社、ベンダー、ソフトウェア開発者、および関連する標準規格の専門家を集め、協力的な努力で国際電子出版フォーラム（International Digital Publishing Forum, IDPF） によって開発されました。
EPUB3 仕様は下に述べるリーダーシップにより2010年5月のメンバーシップによって承認された憲章の下で動作し国際電子出版フォーラム（International Digital Publishing Forum, IDPF）の EPUB Maintenance Working Group によって調整した：
ワーキンググループのアクティブメンバー：
> IDPF Members
> Invited Experts/Observers
より詳細な承認と EPUB の各バージョンへの貢献者については謝辞と貢献者 [EPUB3Overview] を参照されたい。
[ContentDocs301] EPUB Content Documents 3.0.1 .
[MediaOverlays301] EPUB Media Overlays 3.0.1 .
[OCF30] Open Container Format 3.0.
[OCF301] Open Container Format 3.0.1 .
[Publications301] EPUB Publications 3.0.1 .
[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046) . November 1996.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.
[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986) . January 2005.
[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . January 2005.
[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation - RELAX NG. Second Edition. 2008-12-15.
[SHA-1] Federal Information Processing Standards Publication 180-3: Secure Hash Standard (SHS) . October 2008.
[TR15] Unicode Normalization Forms .
[US-ASCII] "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986..
[Unicode] The Unicode Consortium. The Unicode Standard..
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . 26 November 2008.
[XML DSIG Core] XML-Signature Syntax and Processing Version 1.1 . 3 March 2011.
[XML ENC Core] XML Encryption Syntax and Processing Version 1.1 . 3 March 2011.
[XML SIG Decrypt] Decryption Transform for XML Signature . 10 December 2002.
[XML Sec RNG Schemas] XML Security RELAX NG Schemas (W3C Working Group Note) . 11 April 2013.
[XMLNS] Namespaces in XML (Third Edition) . 8 December 2009.
[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition. 28 October 2004.
[ZIP APPNOTE 6.3.3] ZIP File Format Specification . September 28, 2007. PKWARE, Inc..
[EPUB3Changes] EPUB 3.0.1 Differences from EPUB 3 .
[EPUB3Overview] EPUB 3 Overview .
[ODF] Open Document Format for Office Applications (OpenDocument) v1.0. 1 May 2005.