Kindle向けの原稿で文字化けと画像切れを同時に見つけると、つい文字コード、ファイル名、画像の置き場所をまとめて直したくなります。ところが、変更点を重ねるほど「どの修正が効いたのか」が分からなくなります。安全なkindle epub 作り方は、本文と画像を別々に検査し、最後に同じEPUBへ合流させる方法です。
ここでは、Shift_JISの34文字標本と、表紙・三章を持つ合成本を使います。文字側は別名のUTF-8版を再読込し、画像側はMarkdownの参照からXHTML、OPFのmanifest、ZIP内の実体まで追います。片方の合格をもう片方へ流用しないことが、入稿前点検の中心です。
修正前に二つの合格票を作る
最初に、文字用と画像用の合格票を分けます。文字票の入力はsynthetic-source-shiftjis.txt、期待値はShift_JISから別名変換した結果がUTF-8、LF、34文字で、復号後の本文が一致することです。画像票の入力は三章、本文画像三点、表紙一点。期待値はXHTMLの画像参照4件、OPFに登録された画像資源4件、alt 4件、欠落0件です。
この時点ではEPUBが作れたかどうかを合格条件にしません。生成通知が成功しても、誤った文字列が保存されたり、参照先のないsrcが残ったりする可能性があるからです。開始時のファイル名とSHA-256を両票へ記し、文字を直す試行では画像を動かさず、画像を直す試行では採用済みのUTF-8本文を変えないと決めます。
合格票を先に作る利点は、失敗時の戻り先が一つに決まることです。文字数が違えば符号化の列へ、欠落が一件でもあれば参照の列へ戻ります。「見た目が何となく直った」という判定は置きません。
34文字を原本へ上書きせず救出する
固定入力の検査では、元ファイルは59バイト、Shift_JISとして34文字、改行はLFでした。原本のSHA-256はe770d422597d8473c36ae4b93273b994b11c471b1bff5605e6155f894ac51686です。このファイルを誤った文字コードで開いたまま保存すると、再解釈に必要な元バイトを失うため、原本は読み取り用として保管します。
変換先はsynthetic-restored-utf8.txtという別名です。再読込ではUTF-8、LF、34文字を取得し、復号した本文は入力と一致しました。変換先のSHA-256は96c6c6c2ad77c5a47dbafcedbb21a045a9c2356e9640b18fdddca1546c107b33です。受入は文字数だけではなく、文字列の完全一致、改行方式、元ファイルの不変を組にします。
失敗例は、変換と文章修正を同時に行うことです。34文字のままでも一字が置き換わっているかもしれません。差が出たら作業版を採用せず、元SHAへ戻り、符号化の変換だけを新しい名前でやり直します。固有名詞や記号は目視でも読み、数だけで正しさを決めません。
三章の画像を参照から格納先までたどる
画像側の合成原稿は、chapter-1.mdからchapter-3.mdまでの三ファイルとcover.pngを使いました。本文には三つの画像参照があり、出力後はp001.xhtml、p002.xhtml、p003.xhtmlからそれぞれ../Images/p001.png、p002.png、p003.pngへ接続します。表紙はcover.xhtmlから../Images/cover.pngへ接続します。
EPUBをZIPとして開くと、manifestにはcover.pngとp001.png〜p003.pngの4資源があり、XHTMLにも4参照、altも4件ありました。各参照の相対パスを解決した結果、欠落は0件です。ここで重要なのは、「元画像が三種類ある」ことと「EPUB内の使用箇所が四つある」ことを混同しない点です。同じ合成画像を複数箇所で使っていても、検査対象は出力された各参照と各格納先です。
参照切れがあれば、まず該当XHTMLのsrc、次にmanifestのhref、最後にZIP内の実ファイル名を比べます。大文字小文字、拡張子、階層のどこで違ったかを特定し、文字側のUTF-8ファイルには触れずに直します。修正後は差分だけで済ませず、4参照すべてを再走査します。
一冊のSHAで二つの検査を結ぶ
画像検査に使った最終EPUBはstudio-408-260903.100000.epubです。SHA-256はa5a0cbbbf8c70e01da5086e8a412cb8c498b3f466008c7515dddaf2a79101f33、ZIPのentryは16件でした。Runeのローカル検査はvalid=trueで、issuesは空でした。
引き渡し票では、このEPUBのSHAに、採用したUTF-8本文のSHAと画像4経路の検査結果を結びます。文字検査が別の原稿版、画像検査が別のEPUBを指していたら、一冊としては不合格です。ファイル名が似ていても、SHAが違えば別候補として扱います。
最終確認は、文字票がUTF-8/LF/34文字・本文一致、画像票が4参照・4資源・alt 4・欠落0、ローカル検査がvalid=trueであることです。三つが同じ引き渡し候補を指したときだけ、ローカルの入稿前点検を閉じます。
失敗した側だけを戻して再出力する
文字が不合格で画像が合格なら、4画像のファイルと参照を凍結し、別名変換だけをやり直します。画像が不合格で文字が合格なら、34文字のUTF-8版を凍結し、壊れたsrcまたはmanifest行だけを修正します。両方を同じ試行で直すのは、原因を再び隠すので避けます。
たとえばp002.pngだけが欠けた場合、表紙や他章を新しい画像へ差し替える必要はありません。失敗版EPUBを消さず、修正版を別名で出し、二つのZIP一覧を比較します。期待する差は問題の一経路だけです。別の資源まで変わっていたら、合格票を更新せず原因を調べます。
復旧完了の条件も最初と同じです。修正コマンドの終了コード0ではなく、再出力した一冊を閉じて開き、34文字一致と4画像経路を最初から読めることを求めます。これにより、直した箇所が別の合格を壊していないか確認できます。
ローカル合格をKDPや実機の合格に広げない
今回の固定証拠が示すのは、文字列の別名変換と再読込、EPUB内の画像格納と参照解決、Runeのローカル構造検査までです。KDPへのアップロード、販売先の審査、Kindle端末やアプリでの描画、画像の見た目の大きさは実測していません。valid=trueや欠落0件から、それらを推測しません。
実原稿では、このローカル合格後に、同じSHAのEPUBをKDPのプレビュー工程と対象端末へ渡します。そこで文字の字形、改ページ、画像の比率や余白を確認し、結果を別の試験票へ残します。画像の著作権や利用許諾も、ZIPに入っているという技術的事実とは別の確認です。
Rune Studioの現行機能は公式サイトで、EPUBの一般構造はW3C EPUB 3.3で確認できます。製品機能、標準仕様、今回の実測を混ぜずに記録すれば、文字化けと画像切れのどちらが起きても、正常な側を守りながら原因へ戻れます。
