]> EPUB Open Container Format (OCF) 3.0(日本語訳版)

この文書は「EPUB Open Container Format (OCF) 3.0」を日本語訳したものです。最新の文書は http://www.idpf.org/epub/30/spec/epub30-ocf.html です。原文もしくは最新の情報を参照したい場合は、 EPUB Open Container Format (OCF) 3.0 を参照ください。

この日本語訳は参考です。公式な文書ではありません。翻訳・解釈の正確性を保証しておりません。

1.2. 用語にあげられている名称は本文中でも基本的に原文のままとした。

公開日:
2013-04-05
翻訳者:
Wataru Yoshimura
校正者:
Fumihiro Kato

EPUB Open Container Format (OCF) 3.0

2011年10月11日 勧告仕様

この版
http://www.idpf.org/epub/30/spec/epub30-ocf-20111011.html
最新版
http://www.idpf.org/epub/30/spec/epub30-ocf.html
前の版
http://www.idpf.org/epub/30/spec/epub30-ocf-20110908.html

前回のドラフトからの変更点の差分は、このリンクで入手可能である。

この文書(いくらかの規範的な訂正を含むかもしれない)のために、正誤表を参照されたい。

Editors

James Pritchett, Learning Ally (formerly Recording for the Blind & Dyslexic)

Markus Gylling, DAISY Consortium

目次

1. 概要
1.1. 目的とスコープ
1.2. 用語
1.3. 適合性
1.4. コンテンツの適合性
1.5. Reading System の適合性
2. OCF 抽象コンテナ
2.1. 概要
2.2. ファイルとディレクトリの構造
2.3. 他のコンポーネントを参照するための相対 IRI
2.4. ファイル名
2.5. META-INF
2.5.1. コンテナ - META-INF/container.xml
2.5.2. 暗号化 - META-INF/encryption.xml
2.5.3. マニフェスト - META-INF/manifest.xml
2.5.4. メタデータ - META-INF/metadata.xml
2.5.5. 著作権管理 - META-INF/rights.xml
2.5.6. 電子署名 - META-INF/signatures.xml
3. OCF ZIP コンテナ
3.1. 概要
3.2. ZIP ファイルの要件
3.3. OCF ZIP コンテナのメディアタイプの識別
4. フォント難読化
4.1. 前置き
4.2. 難読化のアルゴリズム
4.3. 難読化キーの生成
4.4. 難読化されたリソースの指定
A. スキーマ
A.1. container.xml スキーマ
A.2. encryption.xml スキーマ
A.3. signatures.xml スキーマ
B. 用例
C. application/epub+zip Media Type
D. 謝辞と貢献者
参照・参考

> 1 概要

> 1.1 目的とスコープ

このセクションは参考情報である。

この仕様、EPUB Open Container Format (OCF) 3.0 は、単一ファイルのコンテナに1つ以上の EPUB® Publication を構成する関連リソースのセットをカプセル化するためのファイル形式と処理モデルを定義する。

この仕様は EPUB 3、XML および Web 標準に基づいて、デジタル出版物の交換や配信形式の第 3 版を構成する関連仕様のファミリーの1つである。それは EPUB 3 を構成する他の仕様を読み、調和して理解されることになっている:

  • EPUB 3 Overview [EPUB3Overview] は EPUB 3 文書の残りの部分に EPUB の有益な概要とロードマップを提供する。EPUB 3 Overview は最初に読んでおくべきである(should)。

  • EPUB Publications 3.0 [Publications30] は出版レベルのセマンティクスと EPUB Publication のための包括的な適合性要件を定義する。

  • EPUB Content Documents 3.0 [ContentDocs30]EPUB Publication のコンテキストで使用するための XHTML、SVG と CSS のプロファイルを定義する。

  • EPUB Media Overlays 3.0 [MediaOverlays30] はフォーマットとテキストとオーディオの同期のための処理モデルを定義する。

OCF は、EPUB Publication に必要なコンテナ技術である。OCF は、以下のワークフローの役割を果たしてもよい(may):

  • デジタルの出版物を作り出す準備手順の間に、OCF は、異なる個人と(または)異なる団体の間で進行中の出版物を交換する時に、コンテナフォーマットを使用してもよい(may)。

  • 出版社や変換企業から流通や販売チャンネルまで、デジタルの出版物を提供する場合、OCF は、転送フォーマットとして使用するのに推奨されるコンテナフォーマットである。

  • EPUB Reading System や User に最終的な出版物を交付する時、OCF は、出版物を構成する資源の全てを保持するコンテナとして必須のフォーマットである。

OCF 仕様書は、抽象的なファイルコレクションを構造化のための規則である“抽象コンテナ”を定義する。それはまた、ZIP アーカイブ内のこの抽象コンテナを表現するための規則である“物理コンテナ”を定義する。ZIP の物理コンテナのための規則は、[ODF] によって使用される ZIP 技術に基いて構築される。OCF は、埋め込んだフォントを難読化をする機能を要求する EPUB Publication のための標準的な手法を定義する。

この仕様は Open Container Format (OCF) 2.0.1 [OCF2] に取って代わる。この仕様書と前身の違いについては [EPUB3Changes] を参照されたい。

> 1.2 用語

EPUB Publication (or Publication)

この仕様とその兄弟仕様によって定義されるように)一組の相互関係のあるリソースから成っていて、EPUB Container でパッケージされている論理的な文書のエンティティ。

Publication Resource

コンテンツまたは EPUB Publication のロジックと表示に関する命令を含んでいるリソース。このリソースがない場合には、出版物は Author の意図したとおりに表示されないことがある。Publication Resource の例としては Package DocumentEPUB Content DocumentEPUB Style Sheet、音声、動画、画像、埋め込みフォントとスクリプトが含まれている。

Package Document 自身を除いて Publication Resource が manifest [Publications30] に記載されている必要があり(must)、Publication Resource Locations [Publications30] で特に指定がない限り EPUB container ファイルにバンドルする必要がある。

Publication Resource でないリソースの例としては、Package Document の link [Publications30] 要素で識別されるものと EPUB Container の外で解決するアウトバウンドのハイパーリンクで識別されるものが含まれている。(例えば [HTML5]a 要素の href 属性)

EPUB Content Document

EPUB Content Document の定義(XHTML または SVG)の1つに従う Publication Resource

EPUB Content Document は Core Media Type であるためフォールバック [Publications30] を提供することなく、EPUB Publication に含まれていてもよい(may)。

XHTML Content Document

XHTML Content Documents [ContentDocs30] で定義されている [HTML5] のプロファイルに準拠する EPUB Content Document

XHTML Content Document は、[HTML5]XHTML syntax を使用する。

SVG Content Document

SVG Content Documents [ContentDocs30] で表現された制約に準拠した EPUB Content Document

Core Media Type

Publication Resource 型のセットは、それに対するフォールバックは必須ではない。詳細については Publication Resources [Publications30] を参照されたい。

Package Document

EPUB Publication について Package Documents [Publications30] で定められいる文献の構造化メタデータをもたらしている Publication Resource

Manifestation

知的内容の作品のデジタル(または物理的)な具体化。大幅な改修、要訳、翻訳または新しい manifestation の結果を別のデジタルや物理的な形状のコンテンツとして実現させるコンテツの変化。"インスタンス"または"アイテム"と呼ばれる manifestation の多くの単一だが、同一の複製であるかもしれない(may)。ISBN は manifestation の識別子の例であり、そしてその manifestation のすべてのインスタンスによって共有される。

manifestation のすべてのインスタンスは、ささいな修正や改訂が新しい manifestation や作業を引き起こすと判断されていないとして、ビット単位で同一である必要はない。

Unique Identifier

unique-identifier 属性によって識別される Unique Identifier は EPUB Publication のための主要な識別子である。Unique Identifier は一つまたは複数の EPUB standard に従って同じ作品の Manifestation によって共有さるかもしれず(may)、Manifestations の違いが EPUB Reading System と自分自身との違いを考慮し、それらの違いに限定して同じコンテンツを表すには、ISBN の変更が必要になるかもしれない(may)。

Unique Identifier は ISBN よりも細分化される。しかしコンテンツの大幅な見直し、要訳などは新しい Unique Identifier が必要である。

EPUB Style Sheet (or Style Sheet)

CSS のプロファイルに準拠する CSS スタイルシートは EPUB Style Sheets [ContentDocs30] で定義されている。

Viewport

EPUB Publication の内容が視覚的に User に与えられる EPUB Reading System の領域。

EPUB Container (or Container)

OCF ZIP コンテナで定義されている EPUB Publication 用 ZIP ベースのパッケージングと配布のフォーマット。

OCF Processor

本仕様書に従って EPUB コンテナを処理するソフトウェア・アプリケーション。

Author

EPUB Publication(必ずしも、それが含まれるコンテンツとリソースの作者であるというわけではありません)の制作に対して責任がある人または組織。

User

EPUB Reading System を使用して EPUB Publication を消費する個人。

EPUB Reading System (or Reading System)

この仕様書と兄弟仕様と方法の準拠で User に提示するために EPUB Publication を処理するシステム。

> 1.3 適合性

キーワードは"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、そしてこの文書の"OPTIONAL"は [RFC2119] の記述に従って解釈される。

この仕様のすべてのセクションは"このセクションは、有益である"有益なステータスラベルで識別される場合を除き、規範的である。セクションと付録に有益な状態のアプリケーションは、すべての子コンテンツおよびそれに含まれる可能性のサブセクションに適用される。

この仕様のすべての例は有効である。

> 1.4 コンテンツの適合性

  • > OCF 抽象コンテナは、OCF 抽象コンテナで定義された適合性要件を満たさなければならない(must)。

  • > OCF ZIP コンテナ(また、EPUB Container と呼ばれる)は、OCF ZIP コンテナで定義された適合性要件を満たさなければならない(must)。

> 1.5 Reading System の適合性

EPUB Reading System は、以下の基準全てを満たさなければならない(must):

  • > それは、OCF ZIP コンテナで表現されたすべての Reading System の適合性要件に適合する OCF ZIP コンテナを処理しなければならない(must)。

  • > それが Viewport を持つ場合、フォント難読化で定義されたフォントの解読をサポートしなければならない(must)。

> 2 OCF 抽象コンテナ

> 2.1 概要

このセクションは参考情報である。

OCF 抽象コンテナは、コンテナのコンテンツのためのファイルシステムモデルを定義している。ファイルシステムモデルは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを使用する。埋め込まれた出版物の(非リモートの)全てのリソースは、特定のファイルシステム構造はこのために強制はされないが、コンテナのルートディレクトリが率いるディレクトリツリー内に配置される。ファイルシステムモデルは、コンテナのルートディレクトリの直接の子で、以下の特別なファイルを補完するに利用する META-INF という名前の必須ディレクトリを包含する:

container.xml [必須]

埋め込まれた各出版物のエントリポイントであるファイルを識別する。

signatures.xml [省略可]

様々な資産のためのデジタル署名が含まれている。

encryption.xml [省略可]

出版物のリソースの暗号化に関する情報が含まれている。(このファイルは、フォント難読化をする場合には、必要である。)

metadata.xml [省略可]

コンテナに関するメタデータを格納するために使用する。

rights.xml [省略可]

デジタル著作権に関する情報を格納するために使用する。

manifest.xml [許可]

Open Document Format [ODF] によって許可されるコンテナコンテンツのマニフェスト。

META-INF の各ファイルのための完全な適合性要件は、META-INF にある。

> 2.2 ファイルとディレクトリの構造

OCF 抽象コンテナのための仮想ファイルシステムは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを持たなければならない(must)。

OCF 抽象コンテナは、コンテナのルート・ディレクトリの直接の子である META-INF という名前のディレクトリを包含しなければならない(must)。このディレクトリのコンテンツのための要件は、META-INF に記載されている。

ルートディレクトリにあるファイル名の mimetype は、OCF ZIP コンテナで説明されているとおり、OCF ZIP コンテナによって使用するために予約済みである。

OCF 抽象コンテナ内の他の全てのファイルは、META-INF ディレクトリ内を除くコンテナのルートディレクトリから任意の場所の子孫でもよい(may)。

特定の出版物のそれぞれのコンテンツは、コンテナのルート配下の専用のディレクトリに格納されることを推奨する。

> 2.3 他のコンポーネントを参照するための相対 IRI

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="OEBPS/Great Expectations.opf"
            media-type="application/oebps-package+xml" />	
    </rootfiles>
</container>

この場合、OEBPS/Great Expectations.opf のパスは OCF 抽象コンテナのためのルートディレクトリから相対であり、META-INF ディレクトリからの相対ではない。

> 2.4 ファイル名

File Name の用語は、ディレクトリまたは OCF 抽象コンテナのディレクトリ内の通常のファイルといった任意の型のファイルの名前を表現する。

OCF 抽象コンテナの特定のディレクトリの場合、パス名は、ディレクトリのファイル名を分割する / (U+002F) 文字と一緒に連結されたフルパス内にすべてのディレクトリのファイル名を保持する文字列である。OCF 抽象コンテナの特定のファイルの場合、パス名は、ディレクトリのファイル名を分割する / 文字と一緒に連結されたすべてのディレクトリのファイル名を保持する文字列に続いて、/ 文字とファイルのファイル名となっている。

後に説明するファイル名の制約は、最も一般的に使用されているオペレーティング・システム上で変更なしに使用されているパス名とファイル名を考慮にいれて設計されている。本仕様書は、OCF ファイルとパス名を表すことのできない OCF Processor の相互互換性を補う方法を指定しない。

OCF 抽象コンテナのコンテクストでは、ファイルとパス名は、以下の基準を満たさなければならない(must):

  • > ファイル名は、 UTF-8 [Unicode] でエンコードされていなければならない(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により参照されるときに行われた任意の名前に変換を相殺する必要がある。

> 2.5 META-INF

全ての OCF 抽象コンテナは、META-INF というディレクトリを包含しなければならない(must)。このディレクトリは、以下に指定されているファイルを含む。以下に定義されている以外のファイルは、META-INF ディレクトリに包含してもよく(may)、OCF Processor は、そのようなファイルを検出したときに失敗してはならない(must not)。

> 2.5.1 コンテナ - META-INF/container.xml

全ての OCF コンテナは、META-INF ディレクトリ内に container.xml と呼ばれるファイルを包含しなければならない(must)。container.xml ファイルは、コンテナ内に包含されている EPUB Publication のためのルート・ファイルのメディアタイプとパスを識別しなければならない(must)。

container.xml ファイルは暗号化してはならない(must not)。

container.xml ファイルのスキーマは container.xml のためのスキーマで使用可能で、container.xml ファイルは、(このような要素のすべての属性と内容を含む)他の名前空間からのすべての要素と属性を除去した後に、このスキーマに応じて妥当でなければならない(must)。

rootfiles 要素は、1つ以上の rootfile 要素を含まなければならず(must)、それぞれは、一意に単一の出版物を表す Package Document を参照しなければならない(must)。OCF に格納されている出版物は、同じ Manifestation の異なるレンダリングであるべきである(should)。

OCF プロセッサは、含まれている出版物のデフォルトのレンダリングを表現するために rootfiles 要素内の最初の rootfile 要素を考慮しなければならない(must)。Reading System は、標準で一つ以外の任意のレンダリングを使用することは必須ではない。

以下のサンプルは、ルートファイルの OEBPS/My Crazy Life.opf (the Package Document) を持つ EPUB Publication のためのサンプル container.xml を示している:

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

以下のサンプルは、同じコンテナ内にバンドルされている The Sandman の 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>

Package Document 内に含まれる manifest 要素は、EPUB の処理に使用される唯一無二のマニフェストを指定する。ZIP アーカイブ内またはオプションの manifest.xml ファイルに含まれている補助的なマニフェスト情報を、EPUB の処理のために使用してはならない(must not)。ZIP アーカイブ内の任意の追加のファイルは、(すなわち、META-INF ファイルや出版物の代替の派生した翻訳物のように、Package Document の manifest 要素内にリストされていない ZIP アーカイブ内のファイルは)EPUB Publication の処理に使用してはならない(must not)。

full-path 属性の値は、(RFC3986 で定義されている)path-rootless のみの形式から得る必要があり、(RFC 3986 で定義されている)path component を含まなければならない(must)。path component は、それらが使用されているコンテナのルートからの相対パスである。

OCF Processorcontainer.xml ファイル内にある外部の要素と属性を無視しなければならない(must)。

> 2.5.2 暗号化 - META-INF/encryption.xml

コンテナファイルシステムのルートレベルにある META-INF ディレクトリ内のオプションの encryption.xml ファイルは、コンテナのコンテンツの全ての暗号化情報を保持する。このファイルは、ルート要素の encryption の XML 文書である。encryption 要素は、[XML ENC Core] で定義されている EncryptedKeyEncryptedData 型の子要素を含む。各 EncryptedData 要素は、コンテナ内の一つ以上のファイルを暗号化する方法を説明している。encryption.xml は、リソースが暗号化されていることを示し、それが暗号化されている方法に関する情報を提供する示さなければならない(must)。それ故に、コンテナ内のいずれかのリソースが暗号化されているとき、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 Publication により参照される埋め込みフォントのストレージを難読化して"親"出版物に繋げ、無制限使用のための抽出をより困難にする必要がある。これらのケースでは、encryption.xml は、フォント難読化に従って必要なフォントのデコード情報を提供するために使用するべきである(should)。

以下のファイルは、デフォルトか特定の暗号化が求められているかどうかに関わらず暗号化してはならない(must):

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>

> 2.5.3 マニフェスト - META-INF/manifest.xml

manifest.xml という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF ディレクトリに包含してもよい(may)。

manifest.xml は、(ファイルが存在する場合)暗号化してはならない(must not)。

> 2.5.4 メタデータ - META-INF/metadata.xml

metadata.xml という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF ディレクトリに包含してもよい(may)。このファイルは、(もし存在するなら)コンテナレベルのメタデータのために使用しなければならない(must)。OCF 仕様のこのバージョンでは、任意のコンテナレベルのメタデータを指定しない。

META-INF/metadata.xml ファイルが存在するとき、そのコンテンツは、このファイルの特定のフォーマットを指定する OCF の将来のバージョンとの衝突を回避するため名前空間で装飾された要素 [XMLNS] にするべきである(should)。

metadata.xml は、(ファイルが存在する場合)暗号化してはならない(must not)。

> 2.5.5 著作権管理 - META-INF/rights.xml

rights.xml という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF ディレクトリに包含してもよい(may)。このファイルは、権利者、仲介者、そして利用者の間で出版物の交換のための信頼できるデジタル著作権管理 (DRM) 情報のために予約されている。OCF 仕様のこのバージョンでは、DRM 情報に必要な形式を指定しないが、将来のバージョンでは、DRM 情報の特定の形式を指定するかもしれない。

META-INF/rights.xml ファイルが存在するとき、そのコンテンツは、このファイルの特定のフォーマットを指定する OCF の将来のバージョンとの衝突を回避するため名前空間で装飾された要素 [XMLNS] にするべきである(should)。

rights.xml ファイルは、暗号化してはならない(must not)。

rights.xml ファイルが存在しないとき、OCF コンテナは、コンテナの任意の部分を示す情報を提供しない権利が抑制される。

> 2.5.6 電子署名 - META-INF/signatures.xml

コンテナファイルシステムのルートレベルにある META-INF ディレクトリ内のオプションの signatures.xml は、コンテナとコンテンツの電子署名を保持する。このファイルは、ルート要素の signatures の XML 文書である。signatures 要素は、[XML DSIG Core] で定義されている Signature 型の子要素を含んでいる。署名は、出版物と翻訳の全体または一部の出版物と代替えの翻訳に適用できる。XML Signature は、XML だけではなく、あらゆる種類のデータで署名を指定することができる。

signatures.xml ファイルは、暗号化してはならない(must not)。

signatures.xml ファイルが存在しないとき、OCF コンテナは、コンテナの任意の部分がコンテナレベルで電子署名されていることを示す情報を提供しない。しかしながら、それは、含まれている任意のオプションの代替え表現内に電子署名が存在している可能性がある。

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.htmlOEBFPS/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>

> 3 OCF ZIP コンテナ

> 3.1 概要

このセクションは参考情報である。

OCF ZIP コンテナは、抽象コンテナの物理的な単一ファイルの明示である。

> 3.2 ZIP ファイルの要件

OCF ZIP コンテナは、[ZIP APPNOTE] によって規定されているような ZIP 形式を使用するが、以下の制約と説明に従う:

  • > OCF ZIPコンテナのコンテンツは、抽象コンテナに一致しなければならない(must)。

  • > OCF ZIP コンテナは、ZIP ファイルが複数のストレージメディアを横断するために分割を許可している ZIP アプリケーションノートの機能を使用してはならない(must not)。OCF Processor は、複数のストレージメディアを横断するよう分割している ZIP ファイルであることが明らかな任意の OCF ファイルをエラーとして処理しなければならない(must)。

  • > OCF ZIP コンテナは、ZIP アーカイブに非圧縮ファイルかデフレート圧縮ファイルのみ包含しなければならない(must)。OCF Processor は、デフレート以外の圧縮技術を使用している任意の OCF コンテナをエラーとして処理しなければならない(must)。

  • > OCF ZIP コンテナは、[ZIP APPNOTE] のアプリケーションノートのサブセクション 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 attributesExtra field など)に対応するファイルシステム情報を保持する CRC 値、コメントフィールド、フィールドを保存しない。

  • > OCF ZIP コンテナは、UTF-8 [Unicode] を使用してファイルシステム名をエンコードしなければならない(must)。

以下の制約は、OCF ZIP コンテナアーカイブ内の特定のフィールドに適用する:

  • > ローカルファイルヘッダーテーブルでは、OCF ZIP コンテナは、特定のファイルにより必要とされる最大バージョンレベルに合わせるために、version needed to extract フィールドの値を 102045 に設定しなければならない(must)。(例えば、デフレートが必要な場合は 20、ZIP64 が必要な場合は 45)。OCF Processor は、他の任意の値をエラーとして処理しなければならない(must)。

  • > ローカルファイルヘッダーテーブルでは、OCF ZIP コンテナは compression メソッドフィールドの値を 08 に設定しなければならない(must)。OCF Processor は、他の任意の値をエラーとして処理しなければならない(must)。

  • > OCF Processor は、Archive decryption header または Archive extra data record を持つ OCF ZIP コンテナをエラーとして処理しなければならない(must)。

> 3.3 OCF ZIP コンテナのメディアタイプの識別

OCF ZIP コンテナは、コンテナ内に最初のファイルとして mimetype ファイルを包含しなければならなず(must)、このファイルのコンテンツは、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 を参照されたい。

> 4 フォント難読化

> 4.1 前置き

このセクションは参考情報である。

OCF ZIP コンテナは、基本的に ZIP ファイルなので、一般的に入手可能な ZIP ツールを、パッケージから任意の非暗号化したコンテンツストリームを抽出するのに使用できる。一部のシステムでは、ZIP ファイルのコンテンツは、他の任意のネイティブコンテナ(例えば、フォルダなど)に表示されるかもしれない(may)。これを実現する能力はとても便利だが、サードパーティ製フォントの包含したい Author のために問題を引き起こすことがある。

多くの商業フォントは埋め込みを許可しているが、フォントの埋め込みは、出版物のその重要な部分を形成していることを意味し、コンテンツと一緒にオリジナルフォントファイルは提供しない。統合された ZIP のサポートは、現代的なオペレーティングシステムに偏在しおり、ZIP アーカイブ内に単純に配置したフォントは、他のコンテクストで再利用されることは意図しないフォントであることを意味するには不十分である。この不確定要素は、他の非常に便利な EPUB Publication のフォント埋め込みの機能を弱めることができる。

フォントの再利用を防ぐために、多くのフォントベンダーは、もしそれらのフォントが、出版物に何らかの方法で固定化されている場合、EPUB Publication 内のこれらのフォントの使用を許可するかもしれない(may)。フォントファイルが、コンピュータデバイスの組み込みツールを使ってオペレーショングシステム上で使用するため直接インストールできないならば、他の EPUB Publication によって直接使用することはできない。

フォントファイルのためのデジタル著作権管理や施工システムを提供することはこの文書の範囲を超える。その代わりに、任意の含まれているフォントへの一般的なアクセスを得るための最終的な OCF 受容者側の追加の作業として必要になる難読化の方法を定義する。これは、多くのフォントベンダーの要求を満たすであろうという IDPF の期待である。本文書や IDPF によって作られた要求ではなく、これが暗号化を構成するわけでも、フォントファイルが著作権侵害から安全であることを保証するわけでもない。定義されたメカニズムは、単に提供されたフォントのライセンスの詳細に気付いていない人に障害を提供する。これは、フォントへの完全なアクセスを得ようと考えているユーザーは防げないだろう。OCF コンテナが提供されると、RAW フォントファイルを抽出するために定義したアルゴリズムを適応することが可能である。個々のフォントライセンスの要件を満たすかどうかに関わらず、使用許諾者や被許諾者の課題は残る。

> 4.2 難読化のアルゴリズム

アルゴリズムは、フォントファイルを難読化するために、フォントファイルの最初の 1040 バイト (~1KB) の変更から成る。万一、ファイルが 1040 バイト に満たない場合、ファイル全体が変更される。アルゴリズムのキーは、難読化キーの生成のセクションに指定されている手順を使用して生成される。元データを難読化するのに、RAW ファイルの最初のバイトとキーの最初のバイトの排他的論理和(XOR)の計算の結果は、埋め込まれたフォントファイルの最初のバイトとして格納される。この処理は、キー内の全てのバイトが使用されるまで、ソースとキーの次のバイトで繰り返される。ここで、キーの最初のバイトとソースの 21 バイト目から処理が始まり継続する。1040 バイトがこの方法で(またはソースの終わりに到達して)エンコードされたら、ソース内の残りのデータは、格納先に直接コピーされる。以下が擬似コードにおけるアルゴリズムである:

set source to font file
set destination to obfuscated file
set keyData to key for font
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

元のフォントデータを得るには、処理は単純に逆になる。つまり、ソースファイルは、難読化データと RAW フォントデータが格納されている格納先のファイルからなる。

> 4.3 難読化キーの生成

難読化アルゴリズムに用いられるキーは、EPUB Publications 3.0 仕様書から要求され、Unique Identifier [Publications30] に詳しく述べられている、コンテナ内にある出版物の一意識別子から得られる。キーを生成するために、コンテナに含まれる全ての出版物の一意識別子は、container.xml と各識別子の間に挿入されるスペース (Unicode コードポイント U+0020)に出現する出版物の順番で連結しなければならない(must)この文字列を生成する前に、XML 1.0 仕様書 [XML] のセクション 2.3 によって定義されている全ての空白文字は、個々の識別子から削除される。具体的な Unicode コードポイント U+0020U+0009U+000DU+000A は、連結されたスペース区切りの文字列を加える前に各識別子から削除しなければならない(must)。この文字列の UTF-8 表現の SHA-1 ダイジェストは、Secure Hash Standard [SHA-1] で規定されているように生成するべきである(should)。このダイジェストは、その後、難読化のアルゴリズムに記載されているアルゴリズムのためのキーとして直接使用される。

> 4.4 難読化されたリソースの指定

全ての OCF 抽象コンテナの暗号化データは、ここに記載されている方法を使用して難読化したフォントを包含する出版物に添付する encryption.xml ファイル(暗号化 - META-INF/encryption.xml を参照)に記入しなければならない(must)。encryption.xml ファイル内のそのような難読化したフォントのために、EncryptedData の子要素である EncryptionMethod 要素は、http://www.idpf.org/2008/embedding 値を持つ Algorithm 属性を持たなければならない(must)。この属性の存在は、本仕様書に記載されているアルゴリズムの使用を示している。このアプローチを使用して難読化された全てのリソースは、CipherData 要素に記載しなければならない(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="OEBPS/Fonts/BKANT.TTF"/>  
        </enc:CipherData> 
    </enc:EncryptedData>  
</encryption> 

他の出版物へ埋め込みフォントのささいな複製を防ぐために、明示的なキーを、encryption.xml ファイルに提供してはならない(must not)。Reading system は、パッケージの Unique Identifier からキーを得なければならない(must)。

> 付録 A. スキーマ

この付録内のスキーマは、規範である。

> A.1 container.xml のスキーマ

container.xml ファイルのスキーマは、http://www.idpf.org/epub/30/schema/ocf-container-30.rnc が利用可能である。

> A.2 encryption.xml のスキーマ

encryption.xml ファイルのスキーマは、http://www.idpf.org/epub/30/schema/ocf-encryption-30.rnc が利用可能である。それは、[XML Sec RNG Schemas] のスキーマに基づいている。

> A.3 signatures.xml のスキーマ

signatures.xml ファイルのスキーマは、http://www.idpf.org/epub/30/schema/ocf-signatures-30.rnc が利用可能である。それは、[XML Sec RNG Schemas] のスキーマに基づいている。

> 付録 B. 用例

次の例は、ZIP コンテナ内の署名と暗号化された EPUB Publication を含むための、OCF フォーマットを使用した実例である。

> 

用例 B.1. ZIP コンテナ内ファイルのソートしたリスト

mimetype
META-INF/container.xml
META-INF/signatures.xml
META-INF/encryption.xml
OEBPS/As You Like It.opf
OEBPS/book.html
OEBPS/nav.html
OEBPS/toc.ncx
OEBPS/images/cover.png

> 

用例 B.2. mimetype ファイルの内容

application/epub+zip

> 

用例 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="OEBPS/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="OEBPS/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="OEBPS/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="OEBPS/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="OEBPS/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="OEBPS/images/cover.png"/>
        </enc:CipherData>
    </enc:EncryptedData>

</encryption>

> 

用例 B.6. OEBPS/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>

> 付録 C. application/epub+zip メディアタイプ

この付録は、EPUB Open Container Format (OCF) のメディアタイプ application/epub+zip を登録している。

OCF ファイルは、ZIP アーカイブ形式に基づくコンテナの技術である。それは、EPUB Publication とその任意の代替え演出をカプセルに包むために使用する。OCF とその関連規格は、International Digital Publishing Forum (IDPF) によって維持・定義される。

MIME メディアタイプ名:

application

MIME サブタイプ名:

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 の拡張として識別される。

Macintosh ファイルタイプコード:

ZIP

フラグメント識別子:

IDPF は、http://idpf.org/epub/linking/ でリンクしているスキームの登録を維持する。このスキームの一部は、application/epub+zipapplication/oebps-package+xml 文書を解決するカスタムフラグメント識別子を定義している。

詳細についての連絡先とメールアドレス:

William McCoy, bmccoy@idpf.org

用途:

COMMON

著者/改訂管理:

International Digital Publishing Forum (http://www.idpf.org)

> 付録 D. 謝辞と貢献者

この付録は参考である

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] を参照されたい。

> 参照・参考

参照文献

[ContentDocs30] EPUB Content Documents 3.0 .

[MediaOverlays30] EPUB Media Overlays 3.0 .

[Publications30] EPUB Publications 3.0 .

[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986) . Berners-Lee, et al. January 2005.

[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . M Duerst, et al. January 2005.

[TR15] Unicode Normalization Forms . Mark Davis, et al. 17 September 2010.

[Unicode] The Unicode Consortium. The Unicode Standard, Version 5.0.0, defined by: The Unicode Standard, Version 5.0 (Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0).

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XML DSIG Core] XML-Signature Syntax and Processing Version 1.1 . M. Bartel, et al. 3 March 2011.

[XML ENC Core] XML Encryption Syntax and Processing Version 1.1 . D. Eastlake, et al. 3 March 2011.

[XML SIG Decrypt] Decryption Transform for XML Signature . M. Hughes, et al. 10 December 2002.

[XML Sec RNG Schemas] XML Security RELAX NG Schemas .

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, D. Hollander, A. Layman, R. Tobin. W3C. 8 December 2009.

[ZIP APPNOTE] ZIP File Format Specification . September 28, 2007. PKWARE, Inc..

参考文献

[EPUB3Changes] EPUB 3 Differences from EPUB 2.0.1 . William McCoy, et al.

[EPUB3Overview] EPUB 3 Overview . Garth Conboy, et al.