日本よ、これがKindle Format 8だ！

これはKF8ですか？

ろす

よっしゃ、sample.epubって名前のEPUB 3ファイルをKindleGen v2.7／Kindleプレビューツールv2.7を使って変換したらsample.mobiってファイルができたぞ。

さて、これが2011年10月に発表されたKindleの最新フォーマット KF8（Kindle Format 8）なのだろうか？

てゆうか KF8 って何なんだろう。以前から使われてきた Mobipocket とどう区別したらいいの？

電書ちゃん

そのファイルを Kindle プレビューツールで表示してみなさいよ。そしてメニューから[表示]-[本に関する情報]を選択するの。

ろす

ところどころ変な日本語だけど、File Formatの欄はKF8になってる。なるほどね。ファイル拡張子は従来のMobipocketと同じ「.mobi」のままだけど、これはKF8なんだ。

電書ちゃん

ちなみにAmazonからダウンロードしたKF8だと拡張子が「.AZW3」になるから注意ね。

それからツールで変換したときにも、KF8に関するメッセージが表示されていたはずよ。

ろす

げ、スルーしてた。もう一回変換してみよう。

*********************************************************
Amazon.com kindlegen（MAC OSX） V2.7 build 1019-d6e4792
コマンドライン電子書籍コンパイラ
Copyright Amazon.com 2012
*********************************************************
……
情報(prcgen):I1047: metadata が追加されました dc:Title "sample"
情報(prcgen):I1047: metadata が追加されました dc:Creator "author"
……
情報(prcgen):I1017: PRC ファイルを構築、カウントを記録します: 0000025
情報(prcgen):I1039: 最終的な統計情報 - テキストは以下に圧縮されました（元のサイズの％）: 50.65%
情報(prcgen):I1040: 文書の識別子は以下の通りです: "sample"
情報(prcgen):I1041: ファイルフォーマットのバージョンは V 6
情報(prcgen):I1031: PRC ファイルを保存します
情報(prcgen):I1032: PRC が正常に構築されました
情報(prcgen):I1016: 強化 PRC ファイルを構築します
情報(prcgen):I1007: mediaidlinks を解決します
情報(prcgen):I1011: mediaidlinks を書き込みます
情報(prcgen):I1009: ガイド項目を解決します
情報(prcgen):I1017: PRC ファイルを構築、カウントを記録します: 0000024
情報(prcgen):I1039: 最終的な統計情報 - テキストは以下に圧縮されました（元のサイズの％）: 54.53%
情報(prcgen):I1041: ファイルフォーマットのバージョンは V 8
情報(prcgen):I15000: おおよその標準 Mobi 送信可能ファイルサイズ: 0000108KB
情報(prcgen):I15001: おおよその KF8 配信可能ファイルサイズ: 0000112KB
情報(prcgen):I1036: mobi ファイルが正常に構築されました

ふむ、「KF8 配信可能ファイルサイズ」って語句が見えるね。

でもちょっと待ってよ。その前にある「標準Mobi送信可能ファイルサイズ」って何だ？
変換された.mobiファイルは1つしかないのに、まるで複数のファイルに変換されているみたいじゃないか。

電書ちゃん

なかなかいい着眼点ね。でも、それを理解するにはKF8の中身を覗いてみなくちゃ難しいと思うわ。

Mobi_unpackで覗いちゃえ

ろす

ねえ、KF8の中身を覗くことなんてできるの？　EPUBみたいにZIPを展開すると人間に読める形式でデータが入っているわけじゃないんだよ。

バイナリですよ、バ・イ・ナ・リ。

さすがのおいらも機械と2進数で小粋なトークを交わすのは御免こうむるね。

電書ちゃん

あら、あんたMobi_unpackを知らないの？　DRMの掛かってないmobiファイルからソースファイルを生成してくれるリバースエンジニアリングツールよ。

ろす

そ……そんな裏ツールが存在するなんて……

いや、以前こんな話を聞いたことがある。電子出版の世界にも、表の社会と裏の社会があるという。つまり君は間違いなく裏社会の住人だッ！

電書ちゃん

楽しげな妄想はあとにしてちょうだい。

Mobi_unpackは海外のeBook ギークたちが集まるMobile Readってサイトのwikiページに公開されているの。現在のバージョンは47で、ページ下部にダウンロードリンク（Version 47 download）があるはずよ。動作させるには Python 2.X系が必要だわ。

ダウンロードリンクからZIPファイルを入手できたら、展開して“Mobi_Unpack.pyw”ってファイルを実行してね
Mobi eBook Unpack Toolってウインドウが立ち上がるから
- (1) 最初の欄に対象となる.mobiファイル、
  
  (2) 2番目の欄に出力先ディレクトリを指定して、
  
  (3) Startを押すのよ。

ろす

えいっ、ポチっとな。

eBook successfully unpacked

これでいいのかな。さっそく出力先のディレクトリを見てみよう。

「kindlegensrc.zip」ってファイルと「mobi7」「mobi8」という2つのディレクトリがあったよ。

kindlegensrc.zip

電書ちゃん

はじめに、kindlegensrc.zipを展開してみなさい。

ろす

うおっ、びっくりした！

　これ、僕が作ったEPUBファイルの中身そのものじゃないか。それに「kindlegensrc.zip」のファイル名を「kindlegensrc.epub」にしたらEPUBのビューワで普通に読めたよ。

電書ちゃん

どうやら変換元のファイルが「kindlegensrc.zip」という名前で入ってるみたいね。

ポイント:

KF8の中には、変換前のEPUBファイルが「kindlegensrc.zip」としてまるごと入っている

mobi7ディレクトリ

電書ちゃん

次はmobi7ディレクトリの中身を見てみましょうか。

ろす

中身はこんな感じだったよ。「images」ってディレクトリに「image00001.jpeg」と「image00003.jpeg」という2つの画像ファイル。あとはsample.html、sample.ncx、sample.opfだね。

最初に気になったのは、画像ファイルが2つあること。「image00001.jpeg」と「image00003.jpeg」はいずれも表紙画像だった。前者は大きな画像で、後者は小さいからサムネイルかな。元のEPUBにはサムネイルは入れていないんだけど。

電書ちゃん

うん。KindleGen v2.7やKindleプレビューツールではEPUBの表紙画像を元に本棚用のサムネイルを生成するわ。

補足になるけど、Amazon KDP（Kindleダイレクト・パブリッシング）で変換した場合には商品画像として別途アップロードしたファイルが、元のEPUBに入っていた表紙画像の代わりに利用されるから注意ね。

KDPでは変換対象となるファイルとは別に商品画像をアップロードする。この画像はKF8の表紙画像にも使われる

まとめるとこんな感じになるわね。

ポイント:

KF8には表紙画像のほかに、そのサムネイルが含まれている
EPUBをKindleGenなどで変換した場合には、EPUB内の表紙画像からサムネイルが生成される
ただしKDPで変換した場合には、EPUB内の表紙画像は、別途アップロードした商品画像に差し替えられる。サムネイルも商品画像から生成される

ろす

残りのファイルも見てみよう。コンテンツが記述されているのは「sample.html」だけだね。

こりゃまた、随分古臭い感じのHTMLファイルだな。詳細に解説するとキリがないから端折るけど、すごく簡素なレイアウトだよ。元のEPUBが縦書きだったのにこのファイルは横書きになってる。

電書ちゃん

パッケージ文書（sample.opf）も見てみましょうよ。

ろす

version="2.0だから基本的にEPUB 2のパッケージ文書がベースになってる感じだね。

おや、さっきの「sample.html」のmedia-type が text/x-oeb1-document になってる。

これ Open eBook^[1] だよ、EPUB のご先祖様だよ！

電書ちゃん

ということは、このディレクトリにあるのはMobipocket用の表示データね。懐かしいものを見た気分だわ。

ポイント:

mobi7ディレクトリにはEPUBを旧来のMobipocket形式に変換したデータが入っている

mobi8ディレクトリ

ろす

最後にｍobi8ディレクトリの中を見てみよう。きっとここに新しいKF8としてのデータが入っているんだろうな。

なんだよこれ！　EPUBのディレクトリ構成そのままじゃないか。挙句の果てに、sample.epubなんてEPUBファイルまで入ってる。元のEPUBの構成と比べてみよう。

画像、XHTMLファイル、CSSファイル、フォントファイルなどのリソースは、それぞれ専用のディレクトリに分類して格納されている
各リソースのファイル名は機械的に番号が振られた形に変更されている
表紙画像とサムネイルはmobi7ディレクトリ配下のものと同じ
先頭に配置していたはずの表紙ページが、一番最後のページ（part0016.xhtml）になっている
sample.epubはmobi8ディレクトリ以下のリソースをEPUBファイルとしてまとめたもの

分かったのはこんなところかな。

XHTMLとCSSにはHTML5とCSS3が使われているんだけれど、内容は元のEPUBから、ほとんど変更されていなかった。Chromeブラウザで表示しても縦書きになったよ。

電書ちゃん

こっちのパッケージ文書（content.opf）はどんな感じ？

ろす

やっぱりEPUB 2がベースだね。内容はmobi7ディレクトリのものとたいして変わらなかった。

電書ちゃん

どうやらKF8の本質は、Amazonが独自にEPUB 2を拡張してHTML5／CSS3に対応させたものと言えそうね。Amazon版EPUB 3とでもいうべきかしら。

ポイント:

mobi8ディレクトリの中にはEPUB 2を拡張してHTML5／CSS3に対応させたデータが入っている

すきの生じぬ二段構えにござる

電書ちゃん

長くなっちゃったから、もう一度整理するわよ。

KF8の中には、

kindlegensrc.zipの中に変換元のEPUBファイル
mobi7ディレクトリの中にMobipocket用の表示データ
mobi8ディレクトリの中にEPUB 2を拡張してEPUB 3相当の表現力を持たせた表示データ

が入っているの。

ろすちゃんが気にしていた.mobiファイルに変換した時のメッセージに絡めて考えてみると、「標準Mobi送信可能ファイルサイズ」はmobi7ディレクトリの、「KF8 配信可能ファイルサイズ」はmobi8ディレクトリのサイズをそれぞれ表しているんじゃないかしらね。

ろす

mobi7ディレクトリ内のMobipocket用データは何のためにあるんだろう？

電書ちゃん

フォールバック用でしょ。古いKindle端末みたいにKF8に対応していない環境ではこちらのデータを代わりに表示するのよ。

ろす

すきの生じぬ二段構えにござる、ってことか。“Buy Once, Read Everywhere”を実現するのも楽じゃないんだね。

電書ちゃん

元のEPUBが入っている理由はよく分からないけど、DRMの掛かっていないKF8からオリジナルのEPUBを簡単に取り出せるとしたら、ちょっと面白いかも。

ろす

それにしても冗長な構成だなあ。要するに1つのファイルに3～4冊分のデータが入っているわけじゃないか。

電書ちゃん

ファイルサイズを比較してみると、元のEPUBが84Kバイトなのに比べて、変換した.mobiファイルは275Kバイトになったわ。サイズの肥大化は避けられないわね。

でもストアで購入したコンテンツがこの形で配信されているとは限らないわよ。あんたがストアにアップしたコンテンツのファイルサイズをチェックしてみて。

ろす

ホントだ。手元にあるプレビューファイルのサイズよりもスリムになってるね。どうしてだろう。

電書ちゃん

元のEPUBが取り除かれてるのかもしれないし、端末を識別してMobipocketかKF8のどちらを配信しているのかも。日を改めて検証しましょう。

ろす

ひとまず今回で、KF8の中ではEPUBの技術が大きく使われていることは分かったよ。

でもさ、Amazonってズルくね？　EPUBの策定に関わってるわけでもないのに、EPUBの成果を取り入れて独自フォーマットにしちゃってるんだよ。しかも圧倒的なシェアを持ってる。

電書ちゃん

あら、EPUBは誰もが制約なく使える技術よね。Amazonだけは使っちゃダメなんて言ってないわよ。

それにEPUBにDRM掛けて暗号化している企業はAmazonの独自フォーマット路線を非難できるのかしら。暗号化されたEPUBなんて結局は独自フォーマットと変わらないんだから。出版社からEPUBで受け取ったデータをDRM掛けて配信しようが、独自フォーマットに変換して配信しようが、やってることは同じじゃないの？

ろす