先日の「HTML5電子書籍(1)」の続き、というよりも、(1)と(2)の間に入る余話になります。
　(2)を書いている途中であれの発表があったもので、そのまま続きを書いてよいものか調べておりました。それでせっかく調べたので、ということでまとめてみました。あのAppleの発表を実況サイトを追った範囲では、HTML5とJavaScritpばかりが強調されてEPUBには全く触れていなかった印象でしたからね。
というわけで、AppleのiBooks Authorです。

　

1. ibooks形式を作る

　　まずはiBooks Authorでibooks形式の電子書籍を１つ作ってみます。といっても、ほとんどサンプルをそのまま使用したものにします。

　ファイル名は「ibooks_auhtor_test」にしました。スペルミスは一度笑ってスルーしてください。　
　　
　このままサンプルをibooks形式のファイルとして書き出してしまおうと思います。
　「ファイル」→「書き出す」を選択すると以下のような画面がでます。

　ここで「iBooks」を選択するとibooks形式でコンテンツを書き出すことができます。
　
　
　これで、一応ibooks形式の電子書籍を作成できました。　
　

2. ibooks形式の中身を見る

　
　ではでは、ということで、ibooks形式の中身をのぞいてみたいと思います。
　
　拡張子のibooksをzipに変更して、そのzipファイルを解凍すればibooks形式の中を開くことができます。上で書き出したibooksファイルの中身を見てみると以下のようになっています。　

　中身を見ているとファイル構造そのものはほとんどEPUBです。コンテンツファイルがXHTML5で作成されたり、SVGや動画、音声ファイルに対応したりしているので、EPUBはEPUBでもEPUB2かEPUB3のどちらなんだろうかと迷うところもありますが、「ibooks.opf」ファイルがEPUB2のものなので、EPUB2かEPUB3かと言われると、EPUB2なのかなと思います。
とはいえ、
　
　トップレベルのディレクトリにある「minetype」ファイル（このファイルは〜形式であると宣言するファイル）には
　
application/x-ibooks+zip
　
とEPUBと異なるminetypeがしっかり定義されています。
　さらに各CSSの冒頭では

　
@namespace ibooks "http://www.apple.com/2011/iBooks"
　

と「-ibooks-」という独自の接頭辞が定義され、「-ibooks-」の接頭辞を持つibooks独自のプロパティが至るところで使用されています。
　
　つまり、ここまでの話を総合すると
　
ibooks形式＝EPUB2をHTML5対応させて独自拡張したApple独自のフォーマット（読めるデバイスはiPadに制限）
　と言ってしまってよいかと思います。
　さらに@wakufactory さんが以下で紹介されているようにDashboardウィジェットというHTMLウィジェットで作成したウェブアプリを組み込むこともできます。
・iBooks AuthorのHTMLウィジェットの作り方
　ウィジェットという形でウェブアプリを組み込めるならば、正直、使い方次第でもう何でもありになってしまいそうです。インタラクティブな機能はEPUB3の仕様が含有するそれの範囲を超えているのではないでしょうか。
　
　ちなみに・・・、なのですが、@commonstyle さんにお教えいただいたところによると、ibooks形式の拡張子を「.ibooks」から「.epub」に変更するとAdobe Digital Editions ver.1.72（ADE）では開けてしまうようです。
　実際に拡張子を「.epub」に変更して試してみると完全ではないようですが、一応、開けました。こういうところにEPUB由来を感じます。

　
　でも、ADEで開けても、肝心のiBooksでは開けないんですよね・・（レイアウトは崩れるが一応開けるEPUBビューワーはいくつか確認できました）。
　
　

3. ibooks形式のソースの編集する

　ところで、iBooks Authorで手軽に作れるのはよいとして、そのソースを直接編集できないのかという疑問も。
　上述のように中を開くことはできます。中のソースを直接編集してまたibooks形式に変換できるのかということですが、EPUBをベースにしているので、ibooks形式に固める方法もEPUBと同じ方法でいけるようです。つまり、以下のような感じで

$ cd ibooks_auhtor_test
$ zip -0 -X ../ibooks_auhtor_test.ibooks mimetype
$ zip -r ../ibooks_auhtor_test.ibooks * -x mimetype

と、minetypeファイルを除く形で圧縮をかけるとibooks形式のファイルに再度固めることができるようです。
　とはいえ、Appleの規約がそれを許すかどうかはよくわかりません（規約の拘束力がどれほどのものかも含めて）。
でも、一応、技術的には可能と。最も仕様が公開されないとどこまでいじってよいのかもよくわかりませんね。
　

4. itmsp

　itmpとはなんぞやですが、「ファイル」→「公開」を選択すると「itmsp」というファイル、というかいくつかのファイルを格納したディレクトリが作成されます。おそらくはiBooks Storeで公開する際に使用するものだと思います（未確認）です。
　今回の場合だと、「ibooks_auhtor_test.itmsp」というディレクトリが作成されるのですが、そのディレクトリには

　とibooksファイルとメタデータ、表紙画像が格納されています。メタデータと表紙画像はiBooks Storeの書誌画面として使用するんでしょうか（未確認）。メタデータと表紙画像は予め外部ファイルとして書き出されるですね。
　　
　ここで終わってもよいのですが、　これを書きながら感じたことを余談として2つほど以下に書いてみます。そもそも余話であるはずのこのエントリに余談が許されるのかという問題はおいていて・・・

【余談 その1】　iPad上でEPUBは今、どこまでできるのか的な話

　iBooks上ではibooksもEPUBも同じWebkitを使用しているはず。EPUBにはさすがにHTMLウィジェットは組み込めないと思いますが、同じエンジンを使用しているならば、iPad上で読む限り、ibooks形式でできることはEPUBでもできるのではないかと思ったりします（未確認）。
　そう思わせたものが、米O’Reilly社から無料で公開されている以下の電子書籍(EPUB)です。　
　
HTML5 for Publishers
By Sanders Kleinfeld
Publisher: O’Reilly Media
Released: October 2011
　この書籍では出版社を対象にしたHTML5の紹介がされているのですが、その中のCanvasの紹介で、お絵かきツールをEPUBファイルの中に組み込んでいたりするんですよね。一応、EPUB2なはずですけど。　

　仕様上はあまり推奨されませんが、iBooks上であれば、いろいろとできてしまいそうな気がします。
　　で、同じWebkitを使用しているならば、全くとは言わないまでの、それに近いことはできるのではないかと（UIは除く）。
　　時間があれば、ちょっと調べてみたいところです。
　　　

【余談 その2】　iBooksのEPUB3フル対応はいつなの？的な話（推測しか書いてません）

　
　ところで、iBooksのEPUB3のフル対応はいつなのかという問題ですが、Mobile SafariとiBooksがWebkitを（おそらく）共有している以上、iBooksのEPUB3へのフル対応はもう少し先になるかもしれません。
　EPUB3はW3Cの仕様としてまだドラフト段階のCSS3の仕様をいくつか組み込んでいます。EPUB3の仕様はすで確定し、その仕様には「-epub-」という接頭辞も用意されています。しかし、AppleはiBooksのためにだけにドラフト段階の仕様をiOSのWebkitに対応させる気がないのかもなあぁとこういうのいじってみて感じるところです。-ibooks-という接頭辞を用意して独自のプロパティを使用しているアップルさんではありますが。
　もしMoblie Safariと足並みを揃えることになるとしたら、iBooksのEPUB3フル対応はもう少し先になりそうですね。もう少しといっても次のiOSのアップデートまで、半年先とか長くて1年先ぐらいですが。
※2012/01/30 追記
iBooksはEPUB3にすでに部分的に対応しておりましたので、【余談 その2】を「対応」から「フル対応」へ変更しました。
　

　EPUB3の仕様が2011年10月に確定してから3ヶ月ほど経過して、作成ツールやEPUB3リーダーなどがちらほらと現れてきています。ちなみにEPUB3ビューアーについては、以下にすこしまとめた一覧がありますので、参考までに。
・ブラウザ・ビュアー – epubcafé
　
　しかし、あえて今回はEPUB3ではなく、HTML5電子書籍について、2回にわけて書いてみたいと思います。
　と・・・いいつつも、まずはEPUBの話から始めます。　
　　

1. EPUB3でインタラクティブな電子書籍

　EPUB2ではJavaScript自体を「実行するべきではない」とされていましたが、EPUB3になって、JavaScriptの利用が可能になりました。これによって動的でインタラクティブな電子書籍が作成できるようになります。　
　

2.4 Scripted Content Documents
EPUB Content Documents may contain scripting using the facilities defined for this in the respective underlying specifications ([HTML5] and [SVG]). When an EPUB Content Document contains scripting, it is referred to in this specification and its sibling specifications as a Scripted Content Document. This label also applies to XHTML Content Documents when they contain instances of HTML5 forms.
from EPUB Content Documents 3.0

　
　ただし、EPUBは様々なデバイスで読まれることが想定されています。例えば、デスクトップのような、何でもできてしまうデバイスから、iPadのようなタブレット型ＰＣ、サイズの小さいスマートフォン、そして、E Inkのような電子ペーパー端末まであります。特に動画に強い液晶と異なり、動的なコンテンツに弱い電子ペーパー端末はインタラクティブなコンテンツに向いているとはあまり言えません。また、全てのEPUBビュアがJavaScriptに対応しているわけではないのです。
　そもそも・・・
　EPUB3の仕様ではEPUBビュアーのJavaScriptのサポートはオプション。
なのです。
　ですので、仕様の上でもすべてのEPUB3ビュアーがJavaScriptに対応するとは限らないのです。　
　JavaScriptによる動的でインタラクティブなコンテンツの作成する場合でも、JavaScriptに対応していないビュアーでもそのコンテンツが読める範囲内で使用しなくてはなりません。JavaScriptが使用できないとコンテンツが全く読めないとか、コンテンツとして意味をなさないといったものはEPUB3の仕様上認められておりません。
　　
で、ここからが、ようやくこのエントリの本題です。
　
　そういうわけで（かどうかはわかりませんが）、より自由に作りたいという動機からEPUBではなく、HTML5で電子書籍を作ってしまおうという動きがちらほらと米国を中心に見られるようになりました。
　
　この動きを大きく分けると以下の２つの動きに分けられると思います。

• HTML5で作成したコンテンツをアプリケーションとしてパッケージ化
• Webサイトの電子書籍化　-Webサイトとの境界線が曖昧化するパッケージメディア-

　このエントリでは1のHTML5で作成したコンテンツのパッケージ化された電子書籍を紹介します。2のWebサイト化の話は次のエントリで紹介しようと思っております。　
　

2. パッケージ化されたHTML5電子書籍

　HTML5コンテンツはHTML5+CSS3+JavaScriptで構成されます。もう少し具体的に言えば、Webサイトなどで公開されているHTMLで作られたコンテンツもhtmlファイル、css、JavaScriptで構成されるファイル群です。これらを全て1つのフォルダに入れることでコンテンツとしては一応成立します。
　とはいえ・・、例えば、以下のような構成のコンテンツがあったとして、読者にはその中にあるindex.htmlファイルからアクセスしてもらって・・・となるわけです。

　これは厳しい・・。少なくとも私は気分が萎える・・・
　読者が必要のないファイルをうっかり開いてしまう可能性も高く、コンテンツのソースを変更してしまって読めなくなってしまう可能性も低くありません。そもそもこの状態では権利保護のへったくれもありません（あ、でも、不可能ではないのか。）。
　そういうわけですので、コンテンツを配布するにはやはり以下にように1つのファイルとしてに固める必要があります。

　1つのファイルとして固める。
　読者にはファイルの中身を意識させない・いじらせない。
　
　EPUBやKindle形式のようなフォーマットも、おおざっぱな見方をすれば上のようにhtmlファイルなどを固めたパッケージ用フォーマットとして見ることができます。
　EPUBやKindle形式のようなフォーマットとして固めるのではなく、HTML5として固める方法として、以下の２つを少し詳しく紹介します。

• ネイティブアプリ化
• ウィジェット化

　
　

2.1. ネイティブアプリ化

電子書籍をネイティブアプリ化することでパッケージ化する。つまりはアプリ版の電子書籍をHTML5で作るということです。iOSやAndroidのApp Store経由で流す場合はそれぞれのOSにアプリケーションとしてインストールすることになります。
ビュアーアプリを必要とせずに、単体でコンテンツを読むことができます。コンテンツと一緒にそれを読むためのビュアーアプリも一緒にバンドルされているというイメージになります（正確にはそのデバイスのもつレンダリングエンジンを使用すると思われるので、すべてがバンドルされているわけではない）。
　しかし、ネイティブアプリを作成する場合、たとえば、スマートフォンやタブレットPC向けに作成しようとすると

• iOS: Objective-C
• Android: Java
• Windows Phone: C#/VB

という感じでプラットフォームごとに別々の言語を使用しなくてはなりません。
　ちょっとそれはやってられない・・・という方のためにPhoneGapというフレームワークがあります。

PhoneGap
　
　HTML+CSS+JavaScriptで開発したアプリケーションをネイティブアプリケーション化するフレームワークです。ネイティブアプリ化させることができるだけではなく、様々なプラットフォームに対応させることが可能になります。現時点ではWebアプリではアクセスができないデバイスのネイティブな機能にアクセスするAPIも多く提供していますので、カメラをつかったインタラクティブな電子書籍などもつくることができるようになります。　

Supported Features « PhoneGap
　　
また、これはiOS専用ですが、Bakerという電子雑誌用のフレームワークもあります。

Baker

Baker Ebook Framework 3.1
・HTML5ベースを使った電子書籍フレームワーク「Baker」 – MOONGIFT
簡単にいうと、Xcodeのプロジェクトです。コンテンツをいれるbookディレクトリ以外はすでに用意されているので、このbookにコンテンツファイルであるhtmlファイルやcssなどをいれてやり、コンパイルすればそれだけでできる。
<img src=”https://code.kzakza.com/wp-content/uploads/2012/01/baker1-e1326375184227.png” alt=”XcodeでBakersを展開している図” title=”baker” width=”450″ height=”442″ class=”shadow” size-full wp-image-1331″ />
　
上のBakerをさらに利用したLakerというフレームワークもあります。より動的でインタラクティブなものがつくれるようになっているのでしょうか。デスクトップ用ブラウザでも見られるコンテンツの作成も実験的にサポートしているようです。

Laker

Laker
・jQueryやHTML5を使ってiPhoneやiPad向け電子書籍を作成する為のフレームワーク・Laker – かちびと. net　
　
　電子書籍をネイティブアプリとして作成するメリットとデメリットは以下になるかと思います。　

メリット

・1つのファイルとしてパッケージ化できる。
・iOSやAndroidのApp Storeなどのプラットフォームにコンテンツを配信し、有料化することができる。
・PhoneGap等のフレームワークを使用すれば、ハードウェアの機能にアクセスすることができる。
　

デメリット

・ネイテイブアプリなので読者に「インストール」という「読書」にあまりふさわしくない行為をさせてしまうことになる。
・プラットフォーマーの意向に左右されやすい。
・プラットフォーマーに支払う手数料のコスト
・永続性の問題(プラットフォームのOSのバージョンアップをいつまでもサポートできるのか)
　
　既存のプラットフォームに乗せて課金ができる、コンテンツを有償で配信できるというのは、コンテンツプロバイダにとってなによりの利点かもしれません。デメリットのプラットフォーマーの意向に左右されやすいというのは、その利点の裏返しとも言えます。パッケージはしたいけど、プラットフォーマーの意向には左右されてたくないぞぉという人にとってはウィジェット化という選択肢もあります。
　
　

2.2. Webウィジェット

　ウィジェットはアプリ化と同じでHTML5+CSS+JavaScriptを一つのアプリケーションとして固めたものです。W3Cでかなり検討が進んでおり、ほぼ固まったと言える状態です。
・Widget Packaging and XML Configuration（勧告）
・Widget Interface（勧告候補）
・XML Digital Signatures for Widgets（勧告案）
　これらの仕様の詳細については以下のIBMの解説が詳しいのでこちらをご覧ください。
・W3C ウィジェットの構成とパッケージ化
　
　現在、どのブラウザがWeb Wedgetに対応しているかは私が調べた範囲ではよくわかりませんでしたが、Operaは対応しているようです。あと、iOSアプリのCloudReadersもWidgetをサポートしているらしいです。
・Opera: Widget packaging and configuration support in Opera Presto 2.7
　ただし、上で紹介したIBMの解説でも紹介されていますが、HTML+CSS+JavaScriptをパッケージ化するウィジェットがすでに複数のプラットフォーマーから提供されており、W3CのWeb Wedgetで一本化とはなかなかすぐにはいかないのではないかと思われます。
　

2.3. その他

その他、以下のようなフォーマットも存在します。ブラウザが主にサイトを一纏めにして保存する際の使用されるようです。

　
• MHTML形式（Firefoxはプラグインが必要になるが、他の主要なブラウザでは読むだけなら対応しているらしい。）
• webarchive形式 (Safari)

WARC(Web ARChive) は違いますよね・・。　
　
　
　ウィジェットが選択肢になるのは、もう少し先になるのかなと思います。ただし、プラットフォーマーに左右されずにパッケージ化できるという点では非常に魅力的な方法であると思われます。一本化されるのがW3Cの仕様かどうかは分かりませんが、いずれはまとまるのではないかと思います。そうあって欲しいですね。　
　
　プラットフォーマーの意向に左右されたくない。しかし、Wedgetが使用できるのはまだ先かというところで、いっそWebサイトに移行してしまおうという動きも見られるようになっています。これについては、また次のエントリで紹介します。
　
　
※2012/01/11訂正
当初、このエントリはパッケージ化の手段としてネイティブアプリ化のみを紹介しておりましたが、W3C Webウィジェットの仕様やMHTMLなどについて、HTML5コミュニティ、EPUBコミュニティ、Twitter上でお教えいただきました(ありがとうございます！)ので、構成を変更してWebウィジェットなどの紹介も追加いたしました。
※2012/01/12訂正
Objective-Cを使わずともHTML+CSS+JSだけでXcodeを使ってiOSのネイティブアプリが作れるかもと書いていましたが、HTML+CSS+JSだけではできないと神崎渉瑠さんよりコメントにてご指摘を頂きましたので、「ネイティブアプリ化」の項を修正・加筆書しました。。そもそもiOS SDKも必要ではないか（ツッコミ）。その件をご指摘くださった神崎渉瑠さんのコメントも合わせてお読みいただけると幸いです。