この文書は「EPUB Open Container Format (OCF) 3.2」の日本語訳である。最新の文書は https://www.w3.org/publishing/epub3/epub-ocf.html である。原文もしくは完全な情報は、EPUB Open Container Format (OCF) 3.2 を参照されたい。

この日本語訳は参考である。公式な文書ではなく、翻訳・解釈の正確性を保証していない。

公開日:
2019年7月29日
翻訳者:
Wataru Yoshimura

EPUB Open Container Format (OCF) 3.2

Final Community Group Specification

Latest editor's draft:
https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html
Editor:
Garth Conboy (Google)
Former editors:
James Pritchett (Learning Ally)
Markus Gylling (International Digital Publishing Forum (IDPF))
Participate:
GitHub w3c/publ-epub-revision
File a bug
Commit history
Pull requests

要約

この仕様は、単一のファイル コンテナ、EPUB コンテナ内のEPUB® 出版物から成る関連したリソースのセットをカプセル化するためのファイル フォーマットと処理モデルを定義する。

この仕様書は、抽象的(抽象コンテナ)なファイルコレクションを構造化のための規則と、ZIP アーカイブ(ZIP コンテナ)内のこの抽象コンテナを表現するための規則を定義する。ZIP コンテナのための規則は、[ODF] によって使用される ZIP 技術に基づいて構築される。OCF は、この機能を必要とする EPUB 出版物のために、埋め込んだリソース、例えばフォントなどを難読化する方法を定義する。

この仕様は、XML および Web 標準に基づいて、デジタル出版物の交換や配信形式を構成する EPUB 3 [EPUB32] の仕様群のひとつである。これは EPUB 3 を構成する他の仕様を読み、調和して理解されることになっている。

この仕様書と前身の違いの詳細については [EPUB32Changes] を参照されたい。

このドキュメントのステータス

この仕様は、EPUB 3 Community Group によって発行された。W3C 規格ではなく、W3C の規格化手順でもない。W3C Community Final Specification Agreement (FSA) の下では、他の条件が適用されることに注意されたい。W3C Community 及び Business Groups に関して学ばれたい。

このドキュメントに関するコメントを投稿したい場合、public-epub3@w3.orgsubscribearchives)に送信されたい。

1. まえがき

1.1 用語

EPUB 3 で固有の意味を持つ用語は、このドキュメントで利用される(例えば、「著者」や「リーディング システム」)。これら用語と定義の完全なリストは、[EPUB32] で提供されている。

セクションにある用語の最初のインスタンスのみが、その定義にリンクされる。

また、以下の用語は、この仕様で使用するために定義されている。

コーデック(Codec)

コーデックは、例えば、動画と音声メディア タイプなどを最適な圧縮のために設計され、また、最適化されたストリーミング機能を提供する、本質的なバイナリ形式の品質を持っているコンテンツを指す。

初期設定のレンディション(Default Rendition)

container.xml ファイルの最初の rootfile 要素に記載されるレンディション

ファイル名(File Name)

ディレクトリかディレクトリ内のファイルかにかかわらず、OCF 抽象コンテナ内にあるファイルの全てのタイプの名前。

非コーデック(Non-Codec)

非コーデックは、(例えば、HTML、CSS など)文字列に基づいたファイル形式のように、それらの内部データ構造の性質のおかげで、圧縮の利益を受けるコンテンツ タイプを指す。

OCF 抽象コンテナ(OCF Abstract Container)

OCF 抽象コンテナは、OCF 抽象コンテナで定義されているように、OCF ZIP コンテナのコンテンツのために、ファイル システムのモデルを定義する。

OCF プロセッサ(OCF Processor)

この本仕様の要件に従って OCF ZIP コンテナを処理するソフトウェア アプリケーション。

OCF ZIP コンテナ(OCF ZIP Container)

OCF ZIP コンテナに定義されているように、EPUB 出版物の ZIP ベースのパッケージングと配布形式。

OCF ZIP コンテナと EPUB コンテナは、同義である。

パス名(Path Name)

OCF 抽象コンテナ内の特定のディレクトリのために、ディレクトリのファイル名を分離する /U+002F)文字列で連結されたフルパスにある全てのディレクトリのファイル名を保持する文字列。

OCF 抽象コンテナ内の特定のファイルのために、パス名は、ファイルのファイル名の後に / 文字列に続く、ディレクトリのファイル名を分離する / 文字列で連結された全てのディレクトリのファイル名を保持する文字列である。

ルート ディレクトリ(Root Directory)

ルート ディレクトリは、OCF 抽象コンテナファイル システムの基点を表現する。このディレクトリは、性質上、仮想で、EPUB リーディング システムは、コンテンツが解凍されているとき、OCF 抽象コンテナのコンテンツのための物理的なルート ディレクトリを生成するかもしれないし、しないかもしれない。

1.2 適合性

規定ではないとマークされたセクションと同様に、この仕様書の全てのオーサリング ガイドライン、図、例及び注意は規定ではない。この仕様書の他の全ては規定である。

キー ワード MAYMUSTMUST NOTRECOMMENDEDSHOULD 及び SHOULD NOT は、[RFC2119] の宣言に従って解釈される。

2. OCF 適合性

2.1 コンテナの適合性

2.2 リーディング システムの適合性

EPUB リーディング システムは、以下の基準全てを満たさなければならない(MUST):

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

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

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

OCF 抽象コンテナ内の他の全てのファイルは、META-INF ディレクトリ内に存在せず提供され、ルート ディレクトリから任意の場所の子孫でもよい(MAY)。

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

OCF 抽象コンテナ内のファイルは、相対 IRI 参照([RFC3987] と [RFC3986])経由して相互に参照しなければならない(MUST)。

相対 IRI 参照は、ベース IRI [RFC3986] に与えられたファイル形式に関連のある言語仕様によって決定される。例えば、CSS は、CSS スタイルシートとプロパティ宣言 [CSSSnapshot] のコンテクストでどのように相対 IRI 参照が動作するのかを定義する。

Note

いくつかの言語仕様は、先行する [RFC3987] の リクエスト フォー コメンツ [RFC] を参照し、その場合、以前の RFC は、特定の言語でコンテンツに適用される。

ほとんどの言語仕様とは異なり、META-INF ディレクトリ内の全てのファイルのためのベース IRI は、初期設定のベース IRI としてOCF 抽象コンテナのルート ディレクトリを使用する。

例えば、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 ディレクトリからの相対ではない。

全ての相対 IRI 参照は、OCF 抽象コンテナ内のリソース(すなわち、ルート ディレクトリ以下)を解決しなければならない(MUST)。

3.4 ファイル名

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

OCF 抽象コンテナのコンテクストでは、ファイル名とパス名の大小文字を区別し、次の基準を満たさなければならない(MUST):

Note

いくつかの商用 ZIP ツールは、完全な Unicode の範囲をサポートしておらず、ファイル名のみ [US-ASCII] の範囲のみサポートするかもしれない。これらの制限を持つ ZIP ツールを使うことを望む製作者は、[US-ASCII] 範囲にこれらのファイル名を制限することが最善であることに気づくだろう。ファイルの名前は、解凍処理の中に保存することができない場合、そのファイルはコンテンツ内のURIにより参照されるときに行われた任意の名前に変換を相殺する必要がある。

3.5 META-INF ディレクトリ

3.5.1 導入

全ての OCF 抽象コンテナは、それらのルート ディレクトリMETA-INF と呼ばれるディレクトリを包含しなければならない(MUST)。

このディレクトリは、META-INF 予約済みファイルで指定されたファイルを含む。そのセクションに記載されているもの以外のファイルは、META-INF ディレクトリに包含されてもよい(MAY)。このようなファイルに遭遇したとき、OCF プロセッサは、機能しなくなってはならない(MUST NOT)。

3.5.2 予約済みファイル

3.5.2.1 コンテナ ファイル (container.xml)

META-INF ディレクトリにある必須(REQUIRED)の container.xml ファイルは、OCF 抽象コンテナEPUB パッケージを識別する。

このファイルのコンテンツは、(このような要素のすべての属性と内容を含む)他の名前空間から全ての要素と属性を取り除いた後に、container.xml のスキーマにあるスキーマに妥当でなければならない(MUST)。

rootfile 要素は、EPUB 出版物のひとつのレンディションを表しているパッケージ ドキュメントの配置を特定しなければならない(MUST)。各レンディションは、そのコンテナと同じ EPUB のバージョンに準拠しなければならない(MUST)。

OCF プロセッサは、含まれている EPUB 出版物の初期設定のレンダリングを表現するために rootfiles 要素内の最初の rootfile 要素を考慮しなければならない(MUST)。リーディング システムは、初期設定のレンディションの表示は必須(REQUIRED)だが、コンテナ内の他のレンディションを表示してもよい(MAY)。

Note

EPUB コンテナは、複数のコンテンツのレンディションを包含する能力を提供するけれども、複数のレンディションに対するリーディング システムのサポートは、レンディションの目的と意味が関係者によって保証された特殊な環境以外では、ほとんど実現できていないままである、

省略可能(OPTIONAL)な links 要素は、OCF ZIP コンテナの処理に必要なリソースを識別する。その子 link 要素のそれぞれは、値が、リソースの配置を識別する href 属性を包含しなければならない(MUST)。各 link 要素は、値が、リソースの関係性を識別する rel 属性もまた包含しなければならず(MUST)、値が、link によって参照されたリソースの種類と形式を指定するメディア タイプ [RFC2046] でなければならない(MUSTmedia-type 属性を包含してもよい(MAY)。

Note

links 要素は、複数のレンディションを持つ EPUB のレンディション マッピング ドキュメントを指すために使用される。

rootfile 要素の full-path 属性と link 要素の href 属性の値は、path component [RFC3986] を含まなければならなず(MUST)、要は、path-rootless [RFC3986] の形式のみから得なければならない(MUST)。path component は、ルート ディレクトリに相対的である。

OCF プロセッサは、container.xml ファイル内にある外部の要素と属性を無視しなければならない(MUST)。

3.5.2.2 暗号化ファイル (encryption.xml)

META-INF ディレクトリ内にある省略可能(OPTIONAL)な encryption.xml ファイルは、コンテナのコンテンツの全ての暗号化情報を保持する。コンテナ内の任意のリソースが暗号化されているとき、encryption.xml は、リソースが暗号化されていることを示し、暗号化されている方法の情報を提供するために存在していなければならない(MUST)。

このファイルは、ルート要素の encryption の XML 文書である。encryption 要素は、[XMLENC-CORE1] で定義されている EncryptedKeyEncryptedData 型の子要素を含む。EncryptedKey 要素が、暗号化された各ファイルを説明するのと同時に、EncryptedData 要素は、コンテナ内で使用される各暗号化キーを説明する。各 EncryptedData 要素は、XML Encryption で説明されているように、EncryptedKey 要素を参照する。

encryption.xml ファイルのコンテンツは、encryption.xml のスキーマのスキーマに妥当でなければならない(MUST)。

OCF は、独立して個々のファイルを暗号化し、これらはセキュリティとパフォーマンスのトレードオフだが、コンテナのコンテンツは一つ一つ復号化される。この方法による暗号化は、パッケージ全体のディレクトリの構造とファイルの命名を公開する。

OCF は、様々なアルゴリズムを使用できるように、暗号化のフレームワークを提供する XML Encryption [XMLENC-CORE1] を使用する。XML Encryption は、任意のデータを暗号化し、結果を XML で表現するための処理を規定している。OCF 抽象コンテナは、非 XML データが含まれてもよく、XML Encryption は、OCF 抽象コンテナに含まれるすべてのデータを暗号化するために使用できる。OCF 暗号化は、コンテナ内のファイル全体のみをサポートし、ファイルの一部の暗号化はサポートしない。encryption.xml ファイルは、もし存在するなら、暗号化はしてはならない(MUST NOT)。

暗号化データは、OCF 抽象コンテナ内の非暗号化データを置き換える。例えば、photo.jpeg という名前の画像が暗号化されているとき、photo.jpeg リソースのコンテンツは、その暗号化されたコンテンツにより置き換えられるべきである(SHOULD)。ZIP ディレクトリ内では、暗号化されたフィルは、デフレートで圧縮するよりは、むしろ格納するべきである(SHOULD)。

状況によっては、"親" の EPUB 出版物に繋ぎ、(例えば、フォントなどを)無制限に使用するための抽出をより困難にするために、レンディションによって参照される埋め込みリソースのストレージを難読化する必要があることに注意されたい。難読化は暗号化ではないので、encryption.xml ファイルは、それらを使用する前に、難読化解除に必要なリソースを識別するために リソース難読化アルゴリズムと共に使用される。

以下のファイルは、初期設定か特定の暗号化が求められているかどうかに関わらず暗号化してはならない(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
  • パッケージ ドキュメント

署名済みリソースは、続けて XML 署名復号変換 [XMLENC-DECRYPT] を使用して暗号化してもよい(MAY)。この機能は、例えば署名後に暗号化したデータから署名する前に暗号化されたデータを識別する OCF エージェントなどのアプリケーションを可能にする。署名後に暗号化されたデータのみ、署名を検証するために使用する要約を計算する前に複合しなければならない(MUST)。

3.5.2.2.1 圧縮と暗号化の順番

ZIP コンテナに格納されているとき、非コーデックのコンテンツ タイプであるデータのストリームは、それらが圧縮される前に暗号化されるべきで(SHOULD)、デフレート圧縮が使用されなければならない(MUST)。この方法は、ZIP コンテナに格納されるファイル エントリが小さなサイズであることを保証する。

コーデックのコンテンツ タイプであるデータのストリームは、それらが暗号化される前に圧縮されるべきではない(SHOULD NOT)。このような場合、追加の圧縮は、(特に大きなリソース ファイルを含む)制作時におけるオーバーヘッドの不要な処理を取り込むだろうし、消費時における音声/動画の再生パフォーマンスに影響を与えるであろう。場合によっては、いくつかの暗号化スキームを伴う圧縮の組み合わせは、(例えば、HTTP Content-Length header など)メディアの再生に先んじて完全なリソースの長さを決定することが技術的に不可能なために、(例えば、HTTP byte ranges など)部分的なコンテンツの要求を処理するリーディング システムの能力を損なうかもしれない

暗号化する前に圧縮されたデータのストリームは、次で定義されている Compression XML 要素に従って、初期リソースのサイズ(すなわち、圧縮と暗号化する前)を指定する、追加の EncryptionProperties メタデータを提供するべきである(SHOULD)。暗号化する前に圧縮されていないデータのストリームは、初期リソースのサイズ(すなわち、暗号化する前)を指定する、追加の EncryptionProperties メタデータを提供してもよい(MAY)。

要素名

Compression

名前空間

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

使用例

省略可能(OPTIONAL)な EncryptionProperty の子。

属性
Method [必須(required)]

使用している圧縮方法を識別する。

値は、「0」(非圧縮)かそれとも「8」(デフレート アルゴリズム)である。

OriginalLength [必須(required)]

初期リソースのサイズ(バイト数)を表す。

値は、正の整数である。

コンテンツ モデル

3.5.2.3 マニフェスト ファイル (manifest.xml)

META-INF ディレクトリの省略可能(OPTIONAL)な manifest.xml ファイルは、コンテナ内にあるファイルのマニフェストを提供する。

OCF 仕様は、マニフェストにメタデータ形式を指定しない。

パッケージ ドキュメントに含まれる manifest 要素は、規定のレンディションを処理するために使用される、ただひとつのマニフェストを識別することに注意されたい。ZIP アーカイブもしくは省略可能(OPTIONAL)な manifest.xml に含まれている補助的なマニフェスト情報は、レンディションを処理するために使用してはならない(MUST NOT)。

Note
この機能は、[ODF] との互換性のためだけに存在する。
3.5.2.4 メタデータ ファイル (metadata.xml)

META-INF ディレクトリに省略可能(OPTIONAL)な META-INF/metadata.xml ファイルが、もし存在するなら、コンテナレベルのメタデータのために使用しなければならない(MUST)。

metadata.xml ファイルが存在するとき、そのコンテンツは、名前空間で装飾された要素 [XML-NAMES] のみにするべきである(SHOULD)。ファイルは、名前空間 http://www.idpf.org/2013/metadata のルート要素 metadata を含むべきだが(SHOULD)、他のルート要素は、後方互換性のために許可する。リーディング システムは、認識されていないルート要素を持つ metadata.xml ファイルを無視するべきである(SHOULD)。

OCF 仕様のこのバージョンは、metadata.xml ファイルで使用するためのメタデータを定義しない。コンテナ レベルのメタデータは、この仕様の将来のバージョンと EPUB 拡張仕様で定義してもよい(MAY)。

3.5.2.5 著作権管理ファイル (rights.xml)

META-INF ディレクトリの省略可能(OPTIONAL)な rights.xml ファイルは、権利者、仲介者、そして利用者の間で EPUB 出版物の交換のための信頼できるデジタル著作権管理 (DRM) 情報のために予約されている。

OCF 仕様のこのバージョンでは、DRM 情報に特定の形式を要求しないが、将来のバージョンでは、そうするかもしれない。rights.xml ファイルのコンテンツは、将来の形式との衝突を回避するために、名前空間で装飾された要素 [XML-NAMES] のみにするべきである(SHOULD)。

rights.xml ファイルが存在しないとき、コンテナの何れの部分も、コンテナ レベルで管理される権利はない。権利の表現は、含まれているレンディション内に存在するかもしれない。

rights.xml ファイルが存在しない場合、OCF 抽象コンテナのいかなる部分も権利に抑制されない。

3.5.2.6 電子署名ファイル (signatures.xml)
Note

リーディング システムは、署名をチェックは要求されないので、電子署名を追加することは EPUB が改ざんできないという保証ではない。

META-INF ディレクトリ内の省略可能(OPTIONAL)な signatures.xml ファイルは、コンテナとコンテンツのための電子署名を保持する。このファイルのコンテンツは、signatures.xml のスキーマのスキーマに妥当でなければならない(MUST)。

signatures.xml ファイルのルート要素は、signatures 要素である。この要素は、[XMLDSIG-CORE1] で定義されているように Signature 型の子要素を含んでいる。署名は、全体または部分的に、EPUB 出版物へ適用でき、(XML だけでなく)あらゆる種類のデータの署名を特定することができる。

signatures.xml ファイルが存在しないとき、コンテナのいかなる部分もコンテナ レベルで電子的に署名されていない。電子署名は、EPUB 出版物内に存在するかもしれない。

データの署名がコンテナのために作られるとき、署名は、signatures 要素の最後の子 Signature 要素として追加されるべきである(SHOULD)。

Note

signatures.xml ファイルの各 Signature は、[XMLDSIG-CORE1] の Manifest 要素とその Reference サブ要素を使用して、IRI の署名が適用されるデータによって識別される。単一で含まれるファイルは、個々にまたは統合して署名されるかもしれない。個々に署名された各ファイルは、独立して検証できるリソースのダイジェスト値が作られる。このアプローチでは、署名の要素が大きくなってもよい。ファイルが統合して署名されるとき、署名されたファイルのセットは、単一の XML 署名の Manifest 要素のリスト化され、一つ以上の Signature 要素によって参照することができる。

コンテナの任意または全てのファイルは、計算された署名情報を含んでいる signatures.xml ファイルを除外して、全体を署名することができる。signatures.xml ファイルを署名するべきか、またその署名方法は、署名者の目的に依存する。

署名者が、署名者の署名を無効にせずにコンテナに署名を追加したり削除したりできるようにしたい場合は、signatures.xml ファイルに署名するべきではない(SHOULD NOT)。

署名者が、署名の任意の追加または削除をしたときに署名者の署名を無効にしたい場合は、[XMLDSIG-CORE1] のセクション 6.6.4 で定義されている エンベロープ署名変換を作成済みの Signature を除いた全体の既存の署名ファイルに署名するために使用することができる。この変換は、既存の全ての署名を署名できるだろうが、パッケージに後で署名が追加されると無効になる。

Note

署名者が、既存の署名の削除時に署名者の署名を無効にしたいが、署名の追加は許したいとき、既存の署名を署名するのに XPath 変換を使用することができる。しかしながら、このような変換の詳細は、この仕様の範囲外である。

[XMLDSIG-CORE1] 仕様は、署名に任意のセマンティクスを紐付けないが、エージェントが、例えば、署名を表現する Signature 要素に情報を加えることにより、セマンティクスな情報を包含してもよい。[XMLDSIG-CORE1] 仕様は、(例えば、SignatureProperties 要素を使うことによって)追加情報を署名に追加する方法を説明する。

4. OCF ZIP コンテナ

4.1 導入

このセクションは規定ではない。

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

4.2 ZIP ファイルの要件

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

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

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

OCF ZIP コンテナ の最初のファイルは、次の要件を満たす mimetype ファイルでなければならない(MUST)。

Note

application/epub+zip メディア タイプについてのより詳細な情報は、補足 C の application/epub+zip メディア タイプを参照されたい。

5. リソース難読化

5.1 導入

このセクションは規定ではない。

OCF ZIP コンテナは、基本的に ZIP ファイルなので、一般的に入手可能な ZIP ツールを、パッケージから任意の非暗号化したコンテンツストリームを抽出するのに使用できる。また、ZIP ファイルの性質は、その内容が一部のシステム上の任意の他のネイティブコンテナ(例えば、フォルダなど)に表示されるかもしれないことを意味する。

この ZIP ファイルの単純さは非常に便利だが、それはまたリソースを抽出する容易さは、暗号化していないリソースの予期しない副作用の問題を引き起こす。サードパーティ製フォントの包含したい製作者は、例えば、典型的にフォントが他人によって抽出され再利用されるのを望まない。より重要なことは、多くの商業フォントは埋め込みを許可しているが、フォントの埋め込むことは、単にコンテンツと一緒にオリジナルのフォントファイルを提供せず、出版物の重要な部分を形成していることを意味する。

統合された ZIP のサポートは、モダンなオペレーティング システムに偏在しおり、ZIP アーカイブ内に単純に配置したフォントは、他のコンテクストで再利用されることは意図しないフォントであることを意味するには不十分である。この不確定要素は、他の非常に便利な EPUB 出版物のフォント埋め込みの機能を弱めることができる。

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

そのようなリソースのためのデジタル著作権管理や施工システムを提供することはこの仕様の範囲を超える。このセクションは、任意の難読化したリソースへの一般的なアクセスを得るための最終的な OCF 受容者側の追加の作業として必要になる難読化の方法を定義する。

この仕様によって作られた要求ではなく、これが暗号化を構成するわけでも、リソースが著作権侵害から安全であることを保証するわけでもないことに注意されたい。しかしながら、このアルゴリズムが、コンテナを解凍することによってそれらのリソースを簡単に抽出できないようにするいくつかの保証を求める多くのベンダーの要求を満たすであろうというのが期待である。

フォントの場合、暗号化のための主要なユースケースは、定義されたメカニズムは、ライセンスの詳細に気付いていない人に障害を提供する。これは、フォントへの完全なアクセスを得ようと考えているユーザーは防げないだろう。OCF コンテナが提供されると、RAW フォントファイルを抽出するために定義したアルゴリズムを適応することが可能である。難読化のこの方法は、個々のフォント ライセンスの要件を満たすかどうかに関わらず、使用許諾者や被許諾者の課題が残る。

5.2 難読化キー

難読化アルゴリズムに用いられるキーは、初期設定のレンディション一意識別子から得られる。

XML 1.0 仕様書のセクション 2.3 [XML] によって定義されている、全ての空白文字、具体的には Unicode コードポイント U+0020U+0009U+000DU+000A は、この識別子から削除されなければならない(MUST)。

結果として生じる文字列の UTF-8 表現の SHA-1 ダイジェストは、Secure Hash Standard [FIPS-180-4] で規定されているように生成するべきである(SHOULD)。このダイジェストは、その後、アルゴリズムのためのキーとして直接使用される。

5.3 難読化アルゴリズム

アルゴリズムは、リソースを難読化するために、ファイルの最初の 1,040 バイト (~1KB) の変更から成る。万一、ファイルが 1,040 バイト に満たない場合、ファイル全体が変更される。

元データを難読化するのに、RAW ファイルの最初のバイトと難読化キーの最初のバイトの排他的論理和(XOR)の計算の結果は、埋め込まれたリソースの最初のバイトとして格納される。

この処理は、ソースとキーの次のバイトで繰り返され、キー内の全てのバイトが使用されるまで続く。ここで、キーの最初のバイトとソースの 21 バイト目から処理が始まり継続する。1,040 バイトがこの方法で(またはソースの終わりに到達して)エンコードされたら、ソース内の残りのデータは、格納先に直接コピーされる。

リソースの難読化は、それらが圧縮または OCF コンテナに追加される前に生じなければならない(MUST)。難読化は暗号化ではなく、この要件は、それらを暗号化する前にリソースを圧縮する 暗号化ファイル (encryption.xml)のひとつに違反しないことに注意されたい。

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

Note

フォントの難読化は、EPUB 3.0.1 で先行して許可されるが、難読化と圧縮の順序は指定しない。その結果、無効なフォントは、圧縮解除と難読化解除の後に遭遇するであろう。このような場合、伸張する前の難読化解除データは、妥当なフォントを返すかもしれない。この仕様のこのバージョンで対応していないので、この仕様は、この復旧方法のサポートを要求しないが、一般的には EPUB 3 コンテンツをサポートするときに考慮する必要がある。

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

すべての難読化リソースは、技術的には暗号化データではないけれど、EPUB 出版物に添付する encryption.xml ファイル(暗号化ファイル (encryption.xml)を参照)に記入しなければならない(MUST)。

EncryptedData 要素は、各難読化リソースのために包含されなければならない(MUST)。各 EncryptedData 要素は、値に http://www.idpf.org/2008/embedding を設定された Algorithm 属性を EncryptionMethod 要素の子に包含しなければならない(MUST)。この属性の存在は、本仕様書に記載されているアルゴリズムの使用を示している。難読化リソースへのパスは、CipherData 要素の子の CipherReference に記載しなければならない(MUST)。

他の EPUB 出版物へ埋め込みリソースのささいな複製を防ぐために、難読化キーを、encryption.xml ファイルに提供してはならない(MUST NOT)。

A. スキーマ

A.1 container.xml のスキーマ

container.xml ファイルのスキーマは、https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/ocf-container-30.nvdl が利用可能である。

このスキーマを使用する検証は [RelaxNG-Schema] と [XMLSCHEMA-2] をサポートするプロセッサが必要になる。

A.2 encryption.xml のスキーマ

encryption.xml ファイルのスキーマは、[XMLSEC-RNGSCHEMA-20130411] に包含されている。

A.3 signatures.xml のスキーマ

signatures.xml ファイルのスキーマは、[XMLSEC-RNGSCHEMA-20130411] に包含されている。

B.

このセクションは規定ではない。

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

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

このセクションは規定ではない。

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

OCF ZIP コンテナ 又は EPUB コンテナ は、[ZIP] アーカイブ形式に基づくコンテナの技術である。それは、EPUB 出版物のレンディションをカプセルに包むために使用する。OCF とその関連規格は、World Wide Web Consortium (W3C) によって維持・定義される。

MIME メディアタイプ名:

application

MIME サブタイプ名:

epub+zip

必要なパラメータ:

なし。

任意のパラメータ:

なし。

エンコードの考慮:

OCF ZIP コンテナ ファイルは、 application/zip メディア タイプでエンコードされる。

セキュリティの考慮:

OCF ZIP コンテナ ファイルを読む全てのプロセッサは、検索されたデータのサイズと妥当性を厳密にチェックするべきである。

さらに、OCF ZIP コンテナ ファイルに埋め込むことのできる様々なコンテンツタイプのために、application/epub+zip が、ここに注記されたものを超えてセキュリティについての暗黙の姿勢でコンテンツを説明してもよい。しかしながら、プロセッサが、追加コンテンツまたは他のプロセッサによって送られるコンテツの処理を認識・処理するばあいには、セキュリティの問題は潜在的に生じる。またその場合、それらは、この登録ドキュメントの範囲から外れるであろう。

application/zip に適用されるセキュリティの考慮は、OCF ZIP コンテナ ファイルにも適用される。

相互運用性の考慮:

なし。

発行されている仕様書:

このメディアタイプの登録は、https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html にある EPUB Open Container Format (OCF) 3.2 仕様書で説明されている EPUB Open Container Format (OCF) のためのものである。

EPUB OCF 3.2 仕様書は、RFC 4839 及び https://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
  • Bluefire Reader
  • Calibre
  • Google Play Books
  • Kobo
  • Microsoft Edge
  • Readium
追加情報:
マジックナンバー:

0: PK 0x03 0x04 , 30: mimetype , 38: application/epub+zip

ファイル拡張子:

OCF ZIP コンテナ ファイルは、ほとんどの場合、.epub の拡張として識別される。

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

ZIP

フラグメント識別子:

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

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

public-epub3@w3.org

用途:

COMMON

著者/改訂管理:

発行された仕様は、World Wide Web Consortium(W3C)のEPUB 3 コミュニティ グループの作業成果物である。 W3C は、この仕様を変更することができる。

D. 謝辞と貢献者

このセクションは規定ではない。

EPUB 3 はPublishing Business Group と連携して、W3C の EPUB 3 Community Group によって開発された。

EPUB 3.2 リビジョンは、以下の人によって導かれた。

編集者に加えて、この EPUB のバージョンは以下の方々の多大な貢献なしには不可能だったであろう。

International Digital Publishing Forum の前メンバー、特に Markus Gylling と Bill McCoy に感謝する。彼らなしでは EPUB は実現しなかったであろう。

E. 参照・参考

E.1 規定の参照

[CSSSnapshot]
CSS Snapshot. URL: https://www.w3.org/TR/CSS/
[EPUB32]
EPUB 3.2. URL: epub-spec.html
[FIPS-180-4]
FIPS PUB 180-4 Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology. URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[RelaxNG-Schema]
Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC. 2008. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
[RFC2046]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[TR15]
Unicode Normalization Forms. URL: http://www.unicode.org/reports/tr15/
[Unicode]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[US-ASCII]
"Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986..
[XML]
Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/
[XML-NAMES]
Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/
[XMLDSIG-CORE1]
XML Signature Syntax and Processing Version 1.1. Donald Eastlake; Joseph Reagle; David Solo; Frederick Hirsch; Magnus Nyström; Thomas Roessler; Kelvin Yiu. W3C. 11 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/xmldsig-core1/
[XMLENC-CORE1]
XML Encryption Syntax and Processing Version 1.1. Donald Eastlake; Joseph Reagle; Frederick Hirsch; Thomas Roessler. W3C. 11 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/xmlenc-core1/
[XMLENC-DECRYPT]
Decryption Transform for XML Signature. Merlin Hughes; Takeshi Imamura; Hiroshi Maruyama. W3C. 10 December 2002. W3C Recommendation. URL: https://www.w3.org/TR/xmlenc-decrypt/
[XMLSCHEMA-2]
XML Schema Part 2: Datatypes Second Edition. Paul V. Biron; Ashok Malhotra. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-2/
[XMLSEC-RNGSCHEMA-20130411]
XML Security RELAX NG Schemas. Murata Makoto; Frederick Hirsch. W3C. 11 April 2013. W3C Note. URL: https://www.w3.org/TR/2013/NOTE-xmlsec-rngschema-20130411/
[ZIP]
.ZIP File Format Specification. 1 September 2012. Final. URL: https://www.pkware.com/documents/casestudies/APPNOTE.TXT

E.2 規定ではない参照

[EPUB32Changes]
EPUB 3.2 Changes. URL: epub-changes.html
[HTML]
HTML. W3C. W3C Recommendation. URL: https://www.w3.org/TR/html/
[ODF]
Open Document Format for Office Applications (OpenDocument) v1.0. 1 May 2005. URL: https://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf
[RFC]
Request for Comments. URL: https://www.ietf.org/standards/rfcs/