KDP向けEPUBで文字化けと画像切れが同時に見えても、原因は一つとは限りません。文字は「どの符号化の原稿をEPUBへ渡したか」、画像は「本文の参照先が実ファイルとして収録されたか」を別々に調べます。二本の検査を混ぜず、両方が合格してから入稿候補にするのが安全です。
ここでは kdp epub の不具合を、文字レーンと画像レーンに分けます。検証に使ったのは短い合成原稿、三種類の文字コード、三章、二枚の本文画像です。KDPの受理や端末の表示を推測せず、ローカルで測れた値だけを合否へ使います。
最初の五分で文字と画像を別の事件にする
文字レーンの記録には章名、元ファイル、検出した文字コード、承認したUTF-8複製を置きます。画像レーンにはMarkdownに書かれたパス、元画像の存在、EPUB内の格納名を置きます。プレビューのスクリーンショットだけでは、どちらの証拠にもなりません。
たとえば第一章の人名が崩れ、同じ章の挿絵も見えないとします。そこで章ファイルを丸ごと作り直すのではなく、人名はUTF-8複製の再読込、挿絵は参照とmanifestの対応で追います。一方が直っても、もう一方の合格票は空欄のままです。
EPUBが開くことも合格条件にしません。ZIPとして開けても、誤った文字列を含むXHTMLや欠けた画像参照を持つ本は作れます。症状ではなく、入力と収録結果を読むのが出力前の予防です。
画像レーンは参照元からパッケージへ向かう
検証用の三章には二枚の小さな画像を参照させました。元画像を figure-1.png、figure-2.png として固定し、各章のMarkdownに書かれた相対パスを確認してから生成へ進めています。ここで古いパスが一件でも残れば、文字レーンの作業をやり直す必要はありません。画像の参照だけを直します。
生成後に見るのは画像の見た目ではなく、EPUB内のmanifestとXHTML参照です。実測した三章のパッケージでは、本文側の画像参照は合計6件でした。各章が二枚ずつ参照したためです。manifestにも対応する6画像が入り、欠落資源は0件でした。
失敗値は、参照パスに対応するファイルがない、EPUB内の格納名とXHTMLが食い違う、画像を表紙と本文で取り違える、の三つです。失敗したら生成したEPUBを残し、元Markdownの該当パスへ戻ります。画像を別名へコピーして偶然表示させると、後でどの資産が正本か分からなくなります。
文字レーンは保存後の読戻しで閉じる
文字側では rune inspect text を使い、UTF-8、Shift_JIS、UTF-16LEの三標本を調べました。結果は順にUTF-8/LF/44文字、Shift_JIS/LF/44文字、UTF-16LE/LF/45文字です。検出値が入力の想定と一致することを確認してから、承認した本文を別名のUTF-8複製へ書きました。
書き込みは rune file write --path /private/tmp/rune-g2c3-studio-281-mvvhqyk4/STUDIO-281-converted-copy.txt --content-file /private/tmp/rune-g2c3-studio-281-mvvhqyk4/approved-utf8-content.txt --dry-run --json で対象を確かめ、同じ命令からdry-runだけを外して実行しました。次に rune inspect text で複製を開き直し、UTF-8、LF、44文字、復号本文一致を得ています。
ここで変換不能候補の意味をRune Studioへ決めさせてはいけません。削るか代替するかは著者・編集者の判断です。原文の意味が未確定なら、別名保存へ進まず保留します。原本を崩れた表示のまま上書きした場合は、同じファイル上で復旧せず、バックアップから新しい検証レーンを作ります。
三章のEPUB内部で二本の結果を合流させる
検証では rune epub series set にhorizontalとjaを渡し、volume 0をversion 3.1として設定しました。三章を rune epub select で選び、planを確認してからexportし、rune inspect epub --path /private/tmp/rune-g2c3-studio-281-mvvhqyk4/EPUB/studio-281-260903.120000.epub --json で生成物を検査しています。
EPUBのSHA-256は 9858bc0e5532190a0b64313584a22731f9af93d2a4d88c552d6360cebe1d299f でした。valid=true、navとNCXは各3項目でラベルが一致し、画像参照6件、欠落報告0件です。この内部値によって、文字用の承認入力と画像用の収録確認を一冊の結果へ結び付けられます。
ただし、画像6件が「美しく表示された」ことは測っていません。1ピクセルの合成画像を使った構造標本なので、確認したのは参照と収録です。文字も同様に、UTF-8で復号できることと、すべてのフォントで同じ字形になることは別です。
KDPで確認することをローカル検査へ混ぜない
KDPの公式プレビューや受理判定は今回のCLI実測に含まれません。販売先へ渡した後は、端末別プレビュー、表紙の扱い、ナビゲーション、権利要件などを別の確認票で扱います。ローカルの valid=true を「KDPで承認された」と言い換えることはできません。
Rune Studioの公開資料には文字コード判定、変換不能文字の赤表示、自動保存停止が案内されています。今回、赤い表示や停止タイマーの画面は測っていません。CLIで確認したのは入力の符号化、別名保存、再読込、EPUB内部です。資料上の機能と実測値を同じ主語で混ぜないことが、過剰な保証を防ぎます。
この記事はKDPのMetadata入力や価格設定を扱いません。破損済みファイルの完全復元、OCR、すべてのリーダーでの同一表示も範囲外です。入稿前のEPUB本体に文字入力と画像資源の欠落を残さないことだけに集中します。
二枚の合否票をそろえてから渡す
文字票は「原稿の符号化が判明」「承認済みUTF-8複製が44文字で再読込」「本文一致」の三欄です。画像票は「元画像が存在」「参照パスが一致」「EPUB内画像6件・欠落0」の三欄です。どちらかが未記入なら、もう一方の成功で埋めません。
失敗時の戻り先も別です。文字が崩れたら原本選定か承認本文へ、画像が欠けたらMarkdownの参照かmanifestへ戻ります。二本を分けておけば、直っている側を壊さずに済みます。
両票とEPUBのSHAを一緒に残してから、KDP側のプレビューへ進んでください。現行Mac版の対象機能はRune Studioの商品ページで確認できます。まず三章程度の複製で検査を完成させ、長編への拡大は原因を説明できる状態になってから行うのが安全です。