すでに崩れたEPUBは観測結果から戻り先を選ぶ
EPUBで画像が欠けたときは、同じ旧パスを機械的に直す前に、実ファイル、原稿の相対パス、EPUB内のmanifestという三層のどこで対応が切れたかを調べます。診断の答えは「旧パスを0件にする」ではなく、最初に不一致が見つかった層を修正先にすることです。
今回のStage 4で実測したのは、二章・画像2枚の原稿に古い相対パスが1件残る分岐です。実ファイル欠落とmanifest未登録を意図的に発生させた検証ではありません。また、修正前の崩れたEPUBを生成して表示症状を観測した記録でもありません。この証拠境界を保ったうえで、三層の判別方法を診断表として使います。
診断表は「ある／ない」の組み合わせで読む
三つの原因は、観測結果の組み合わせで分けます。
| 実ファイル | 原稿参照が実在先を指す | manifestに資源がある | 診断 | 戻り先 |
|---|---|---|---|---|
| ない | 問わない | 問わない | 画像ファイル欠落 | 元画像または正しい保管先 |
| ある | いいえ | 問わない | 古い・誤った相対パス | 該当する原稿行 |
| ある | はい | ない | パッケージ未登録 | 出力設定とmanifest生成 |
| ある | はい | ある | パス以外の原因候補 | 画像形式、CSS、閲覧環境を別診断 |
この表の中心は、上から順に確認して最初の「ない」で止めることです。実ファイルがないのに原稿を置換しても直りません。原稿参照が実在先を指していないのにmanifestだけを調べても、原因の入口を飛ばしてしまいます。
実ファイル層では画像正本の所在を確定する
最初に、原稿が想定する画像ファイルが存在するかを確認します。ファイル名、拡張子、大文字小文字、保管フォルダを見ます。ここで画像がなければ、診断は実ファイル層で終了です。元画像を戻すか、原稿が参照すべき正しい保存先を決めます。
今回のStage 4はこの欠落故障を投入していないため、「Rune Studioで欠落画像を復旧できた」とは書けません。一般診断として戻り先を示すだけです。復旧後は、次の原稿参照層から確認を再開します。
原稿参照層では解決先を一行ずつ確認する
実ファイルがある場合は、章原稿の相対パスを原稿位置から解決します。専用標本では、一方の参照が正しく、もう一方が../old/figure02.pngを指していました。検索結果はfileCount 1、occurrenceCount 1で、該当箇所はchapters/01.mdの3行目です。
この一行を../images/figure02.pngへ明示的に変更し、replacedCount 1を確認しました。再検索はfileCount 0、occurrenceCount 0です。この結果が証明するのは、古い相対パス分岐で原因行を一つに絞り、その参照文字列を除去できたことです。自動追跡や他の二分岐の修復を証明するものではありません。
manifest層では原稿と正本が正しいことを前提にする
実ファイルが存在し、原稿参照も実在先を指すのに画像が欠ける場合は、EPUBを展開してmanifestへの登録を調べます。登録がなければ、戻り先は章原稿ではなく、出力設定とパッケージ生成です。生成済みEPUBへ直接ファイルを足すと、正本との対応が切れるので避けます。
今回のStage 4ではmanifest未登録の故障を意図的に作っていません。修正後の生成物で画像2件とmissing 0件を確認しただけです。したがって、manifest分岐は診断条件として示し、修復成功の実測には数えません。
実測した古いパス分岐は修正後の再生成まで確認した
相対パスを1件修正した後、二章をplanし、fileCount 2、chapterCount 2、valid trueを確認しました。生成物studio-445-260831.120000.epubは5,629 bytesで、SHA-256はdddd98で始まります。
inspectはentryCount 12、spineItemCount 5、imageCount 2、missing 0、nav.xhtmlあり、NCXあり、各章項目2件、valid true、issues空でした。この結果は、古いパスを直した専用標本が二章・画像2枚のローカル構造へ戻ったことを示します。修正前の崩れた生成物や表示回復を比較した結果ではありません。
passedを三原因すべてへ広げない
記事固有statusのpassedは、古い相対パス1件を明示修正し、旧パス0件、生成物の画像2件、missing 0件を確認した経路だけに適用します。実ファイル欠落とmanifest未登録の分岐は未検証です。
画像の見た目、Finderやクラウドストレージの自動追跡、KDPなど外部サービスの受理、実機や全閲覧アプリでの表示も未確認です。EPUBのmanifestとspineの一般的な役割はEPUB 3.3で確認できますが、ローカル構造の検査を外部結果の保証へ広げないでください。
Rune Studioは原因層を調べる手段として限定する
Rune Studioの公開機能には、txt、text、md、markdown内の相対画像・リンク参照を更新する機能と、Markdown原稿からEPUB 3を出力する機能があります。../を含む相対参照を扱い、外部URLとページ内アンカーは更新対象外です。出力ではcontent.opfのmanifestとspine、nav.xhtml、NCXが構成されます。
今回の操作は専用コピーに対する明示的な検索、一箇所置換、再生成、構造検査です。製品機能は実ファイル・原稿・生成物を調べる候補になりますが、どの原因だったかは各層の観測値から判断します。
結論：最初に不一致が出た層だけを直す
EPUBが崩れたら、実ファイルの存在、原稿参照の解決先、manifest登録の順に観測します。ファイルがなければ画像正本、参照だけが古ければ原因行、両方正しく登録だけなければ出力設定へ戻ります。三層すべてが正しければ、パス以外の原因へ進みます。
今回実測できたのは、古い相対パス1件を原因行として特定し、修正1件、旧パス0件、再生成後の画像2件・missing 0件を確認した分岐です。旧パス修正をすべての事故へ当てはめず、最初に不一致が出た層を診断結果にしてください。
