文字化けと画像切れは同じプレビュー画面に現れても、原因も戻る場所も違います。文字化けは原稿の復号、保存文字コード、または変換時のテキスト処理を調べます。画像切れは原稿から画像への参照、画像ファイルの所在、EPUBへの収録を調べます。二つを別の合格票で先に通すと、出力後に原因不明の修正を繰り返さずに済みます。
STUDIO-152の合成ワークスペースでは、同じ原稿の三符号化を検査してUTF-8/LF/288字へ揃え、2画像を含むEPUBを出力しました。パッケージ検査はspine 6、画像2、valid=trueでした。確認できた実値だけを使って手順を組みます。
文字と画像を二本の検査線へ分ける
作業開始時に「原稿票」と「画像票」を作ります。原稿票には受領パス、検出文字コード、改行、字数、冒頭・中間・末尾の文字列を記録します。画像票には参照元原稿、相対パス、実ファイル、用途、出力後の収録名を書きます。
一つの「見た目OK」欄へまとめると、本文が正しいのに画像の修正で原稿を再保存したり、画像はあるのに文字コードを変えたりします。異常が出た側だけを差し戻せるようにします。原本と画像の元データは上書きせず、専用作業領域へ複製します。
画像を扱う前に原稿を正しく復号する
今回の入力は source-utf-8.txt、source-shift_jis.txt、source-utf-16le.txt です。rune inspect text の検出値はUTF-8/LF/288字、Shift_JIS/LF/288字、UTF-16LE/LF/289字でした。UTF-16LEの差はBOMの扱いを確認し、三地点の可読性で本文欠落と区別します。
表示が崩れた候補をそのままUTF-8保存してはいけません。誤復号した文字列を新しい形式で固定するだけだからです。検出値と三地点が一致する原稿を入力に選び、納品仕様がUTF-8なら作業用複製を明示的にUTF-8へ設定します。
保存したUTF-8原稿を閉じて再読込する
専用ワークスペースで対象を rune tab open し、dry-run後に rune tab set-encoding --encoding UTF-8 を実行しました。保存後にワークスペースを閉じ、別の rune inspect text で保存先を検査しました。結果はUTF-8、LF、288字で、制御用本文とのdecoded text一致も確認できました。
Rune Studioの製品資料には、選択した文字コードで表せない文字を赤く示し、自動保存を止める機能が説明されています。ただし今回のCLI検証は警告色と停止タイミングを実測していません。画面で見たと断定せず、保存後ファイルの検査値を合格根拠にします。
画像参照は原稿から相対パスをたどる
画像票では、画像フォルダに2枚あることだけを数えません。どの章がどの相対パスを参照し、そのパスが実ファイルへ解決するかを確認します。移動や改名をした場合は、旧参照件数、新参照件数、保存後原稿の再読込を記録します。
同名の代替画像を古い場所へ置くと、一時的に欠落が隠れても正しい画像か分かりません。参照文字列と画像の識別を一対一にします。画像が外部URLの場合は、配信条件やオフライン閲覧が別問題になるため、ローカル収録画像と同じ合格にしません。
EPUB内部の2画像とspine 6を検査する
UTF-8原稿と画像票が通った後にテストEPUBを出力しました。保存先のEPUBへ rune inspect epub --path <epub> を実行した実測では、spineは6、画像は2、navあり、NCXあり、valid=true でした。欠落画像は報告されませんでした。
spine 6は画像数ではなく読書順に並ぶ項目数です。画像2も、二つの章で必ず正しく表示されるという意味までは含みません。EPUBを展開し、manifestの画像項目、XHTMLの参照、実ファイル名を照合します。さらに表紙、最初の本文画像、最後の本文画像を対象確認環境で開きます。
二系統の失敗を正しい戻り先へ返す
保存原稿の冒頭から文字が崩れているなら復号へ戻ります。保存後だけ崩れるなら文字コード設定と保存先を調べます。原稿は正しいのにXHTMLが崩れるなら、章選択または変換処理を調べます。画像の実ファイルがないなら素材管理へ、原稿のパスが古いなら参照更新へ、EPUBに収録されないなら出力選択やmanifestへ戻します。
両方が同時に失敗しても、全作業をやり直しません。原稿票と画像票の最後に通った地点から再開します。正常な画像を再圧縮したり、合格済み原稿を再変換したりしないことが、二次事故の防止になります。
Rune Studioが向く範囲と別手段を分ける
ワークスペース内で原稿、章選択、画像、書誌、EPUB出力をまとめて追う場合、Rune Studioは作業記録をつなげやすい選択肢です。一方、破損バイトから文字を復元する作業、OCR、画像の高度な修復、各ストア固有の最終審査は別の専門手段が必要です。
ローカル検査のvalid=trueは配信ストアの受理や全リーダーの同一表示を保証しません。対象ストアのチェックと実機確認を別の出口試験として残します。未実測の警告画面や端末挙動を、今回の実値へ混ぜません。
出力前カードで二軸を同時に閉じる
epub 電子書籍 作り方 の出力許可カードには、文字側として保存先UTF-8、LF、288字、三地点一致、decoded text一致を記録します。画像側として参照解決、収録画像2、欠落報告なしを記録します。パッケージ側はspine 6、nav、NCX、valid=trueです。
どれかが欠ければ、その値を所有する工程だけを戻します。文字の再読込と画像の収録を別々に合格させ、最後に一つのEPUB番号へ結び付ける。この順序なら、文字化けも画像切れも「出してから気づく問題」ではなく、保存と出力の境界で止められる検査項目になります。
