‘epubcheck’ タグのついている投稿

EPUBCheck4.2でのエラーについて

2019/05/22

 先日発表がありましたEPUBの公式データチェッカー、EPUBCheck4.2なのですが、試用してみたところ、これまでのバージョンでは出なかったエラーが表示されてしまいました。具体的には以下のようなエラーです。

ERROR(NAV-011): ./Desktop/test.epub/item/navigation-documents.xhtml(19,73): ‘toc’ nav must be in reading order; link target ‘item/xhtml/p-001.xhtml#toc-2C4CB0422A16-4C9E-B148-05A28E0A49C9’ is before the previous link’s target in spine order.

 従来のバージョンでは出ていなかったエラーが新バージョンでは出るようになったということなので、どういうことなのかちょっと策定に関わった方などに聞いてみたのですが、どうやら以下のような話のようです。

  1. もともとEPUBの仕様としては論理目次(電書協ガイド仕様の場合はnavigation-documents.xhtml)のリンクの表示順はOPFのSPINEの順番と同じでなければならないという決まりがあった
  2. ただ、これまでのEpubCheckにはそれをチェックする仕組みがなく、論理目次のリンクの表示順を自由に変えてもエラーにはならなかった
  3. 今回のアップデートで厳密にそこをチェックするようになり、エラーになるようになってしまった

 確かに規格を厳密に解釈すればエラー扱いになるのかも知れませんが、これに沿ってチェックをすると現在既に市場で流通しているEPUBファイルがかなりの確率でエラー扱いになりそうなのでちょっと困ったなという印象です。EPUB3.0.1に関してはエラー扱いにしないなどの形でもう少し既に大量に流通しているものへの後方互換性を考慮して欲しかったというのが正直なところです。

 とは言え新規に作るものはこのルールに従って作れば良いわけなのでそこまで問題はないはず。過去に作ったものへの対応は今後ファイル受け入れストア側の対応状況を見ながら考えたいと思っています。現場に大きな負担がかからない形で収束すれば良いのですが。

OPFのSPINEブロック

OPFのSPINEブロック

 なお、OPFについて少し解説しておきますと、これはそのEPUBの書誌情報や収録されているファイル等を記述するパッケージとしてのEPUBのコアになるファイルで、その中のSPINEブロックというのは「EPUB内に複数収録されているXHTMLファイルを見せる順番を決める」ことがメインの目的になるものです。ビューア上でEPUBを見ていくとここに書かれている順番通りに内容が表示されます(その他、ページめくり方向の規定や見開き時にページをどちらに配置するかの指定もここ)。今回はここの記述の順番とビューアの目次機能から呼び出す方の目次(論理目次)の記述順が同じでないとエラーになるようになった、という話になります。

(2019.5.22)

EpubCheckでID名がエラーになる問題

2016/08/03

 先日、弊社で作ったEPUBファイルが電子取次さんのチェックに引っかかって修正で戻ってきたという件がありました。EpubCheck※1のエラーとのことなのですが、弊社でのチェッカーのログはエラーになっていない。どうもEpubCheck3.0.1ではエラーとなっていたものがEpubCheck4.0.1でエラーにならなくなり、チェックに引っかからなかったということのようです。ちょっと困った事態なので突っ込んで調べてみました。

XHTMLのID名のエラー

 エラー内容は「value of attribute "id" is invalid; must be an XML name without colons」とのことだったので、まずは該当箇所を見てみます。ID名が「id="toc-001*"」のような形となっており、なるほどこれはエラーになるわけだと一旦は思いました。XMLではID名に「*」の記号を使うことを許容していないからです※2。ということでまずはEpubCheckの各バージョンでこの状態のEPUBでエラーになるかを見てみます。

 EpubCheck3.0.1だと
EpubCheck3.0.1でのチェック結果

 なるほどエラーとなるようです。

 EpubCheck4.0.1だと
EpubCheck4.0.1でのチェック結果

 エラーになりません。なるほど。

 では、ちょっとID名を変えて見てみます。「id="toc-あ001"」と、ひらがなの「あ」を入れてみました。この状態でEpubCheckをかけますと

 EpubCheck3.0.1で
EpubCheck3.0.1でのチェック結果

 おや、エラーになりませんね。

 同じくEpubCheck4.0.1だと
EpubCheck4.0.1でのチェック結果

 こちらもエラーにならないようです。

HTML5ではID名に何を使ってもよい

 困った話だなと思ったのですが、さらに調べるとどうもHTML5では途中にスペースが入らない限りID名に何を使ってもよいとの話もあるようで※3、これに従うと挙動としては実はEpubCheck3.0.1でエラーになるのが間違いだったということになるのでしょうか。
 ただ、EPUB3を内部的にXMLなどに変換して表示しているビューアも存在しますので、XMLのID名使用可能文字の制限に従っておくのが無難なのは間違いないと思います。ということでどうやらこの件ではEpubCheckを当てにできませんので、独自にPerlでチェッカーを作ってみました。

 こんな感じでしょうか。一応これでチェックは可能となりました。ターミナルで引数にEPUBファイルを指定してやることでログファイルを出力します。環境によってはArchive::Extractモジュールのインストールは必要かもしれません。

 EpubCheckはIDPFが配布している公式なEPUBの構造チェッカーですので、まずはこれを通るデータであることが市場流通させられるEPUBの最低条件であることは言うまでもありませんが、各パラメータチェックの細かな部分を見ていくと、必ずしもEpubCheckだけで十分というわけでもないようです。現場サイドでの対応も必要といったところでしょうか。

*1 IDPFの提供している公式なEPUBデータチェック用バリデータ。これでエラーとならないことが市場に流通させられるEPUBの最低条件。

*2 半角の英数字および「.」「:」「_」「-」のみ使用できる

*3 参考:https://www.marguerite.jp/Nihongo/WWW/RefHTML/Attrs/id.html

追記:XML関係の有識者の方にコメントいただきまして、どうやら規格としてはHTML5およびそれを内包しているEPUB3ではID名にはどんな文字を使ってもよい、ということで確定のようです。ただ、実際には古いXML規格で回っているシステムは多数あるかと思いますので、ID名にひらがなや漢字、旧規格で認可されていた以外の記号類を混ぜるようなことはしない方が無難だろうとは思います。規格と実装はまた別です。

(2016.8.3)

epubcheckの日本語文字化け対策

2013/10/28

 以前、このブログで発表して現在配布中の「EPUB3トータルデータチェッカー」なのですが、どうも日本語のパス名が化けて表示されるようで少々気になっていました。エラーメッセージ自体は英語ですのでそこまでの問題ではないのですが、JEPAがepubcheckの日本語化バージョンを発表したなどというニュースもありましたし、これが標準になってくるとエラーメッセージそのものが文字化けして読めないというような事態になってきます。これでは少々寝覚めが悪いのも確かですのでちょっと調べてみました。

.bash_profileを書き換えてみたけれど・・・

 「java mac 文字化け」などで検索すると、事例がそれこそ星の数ほど引っかかるのですが、要はjavaの内部処理コードのデフォルトがShift_JISなため、そのままでUTF-8環境に書き出すと日本語部分が文字化けしてしまうということのようです。「ターミナルの文字コードをShift_JISに設定すれば化けない」なんて情報もあったのですが、そこは諸般の事情で変えたくないので却下です。で、このあたりこのあたりの情報をもとにまずは.bash_profileに設定を追記してみました。

 まずはターミナルを立ち上げて以下のコマンドを入力し、.bash_profileを編集できるようにします。

cd ~
vi .bash_profile

viが立ち上がったら、iキーを入力して挿入モードにし、以下のコマンドを入力します。

alias javac=’javac -J-Dfile.encoding=UTF-8′
alias java=’java -Dfile.encoding=UTF-8′

.bash_profileを編集 コマンドを入力し終えたらESCキーを押して「:wq」を入力してファイルを閉じます。viとか普段使わないのでこことかでコマンド調べながらの作業です。

 これでターミナルを再起動し、

-java -jar epubcheckのパス epubファイルのパス

 などと打ち込めば、例えパスに日本語が含まれていても正しくチェック結果が表示されるはずです。

ターミナル出力結果が文字化けせずに表示された 実際試してみると、確かに正しく表示されました。

 ただ、この方法だと(まあbashの設定を変えただけなので当たり前なんですが)ログ出力したテキストファイルにまでは効力が及ばないようで、相変わらずログテキスト内では文字が化けてしまっています。

「export _JAVA_OPTIONS=-Dfile.encoding=UTF-8;」を追記して文字化け解消

ログファイルが文字化けせずに出力された そこで、ここの情報をもとに、「-java -jar epubcheckのパス epubファイルのパス」の前に「export _JAVA_OPTIONS=-Dfile.encoding=UTF-8;」を追記してみました。
 つまりjavaを実行する前に出力文字コードをUTF-8にするオプションを連続実行するようにしてみたわけです。

 はい、ちゃんと日本語になってくれました。

改訂済の「EPUB3トータルデータチェッカー 1.2.1」こちらからダウンロードしていただけます。

 なお、今回はJEPAの日本語化バージョンの元バージョンが「3.0」(英語最新版は3.0.1)であることから、内包するepubcheckのパッケージを差し替えることは見送りました。従いまして、エラーメッセージ自体は従来通り欧文で表示されます。将来的に日本語化バージョンがバージョンアップした場合には、適宜差し替えを考えております。

 epubcheckのエラーメッセージの内容につきましてはここが参考になります。
 なお、こちらのTIPSやアプリケーションを利用された結果生じた損害につきまして私は一切の責任は負いかねますので、あくまで自己責任にてご利用ください。

(2013.10.29)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。