EPUB編集アプリで出力前の事故を防ぐなら、文字化けと画像切れを同じ「表示崩れ」にまとめないでください。文字は、原稿の文字コードで保存できるかを確認します。画像は、Markdownなどの参照文字列が原稿から実ファイルへ届くかを確認します。戻る正本が違うため、二つの検査表を別々に完了してからEPUB生成へ進みます。
この記事は、原稿段階の二系統チェックを扱います。第三者が作ったEPUBの直接修復、DRM、ストア受理は対象外です。生成後XHTMLから文字化け原因を追う作業や、Markdown画像を挿入して移動後のパスを直す詳しい手順は別に行います。
文字検査は「読める」ではなく「選択中の文字コードで保存できるか」
画面に文字が見えても、その文字コードへ保存できるとは限りません。UTF-8では扱える絵文字が、Shift_JISの作業用コピーでは表現できない場合があります。フォントが字形を表示できない問題と、文字コードが値を保存できない問題も別です。
二章の複製へ、既知の検査文字を二件置きます。一件は絵文字、一件は互換文字です。文字ごとに章ID、前後五文字、期待する扱いを記録します。目的は問題文字を削ることではなく、採用する文字コードで表現できない位置を出力前に特定することです。
検出されたら、まず原稿の正本を退避し、問題箇所を一件ずつ判断します。意味を保つ代替文字へ変える、注記へ移す、UTF-8の複製へ保存するなど、作品の要件に合う方法を選びます。複数箇所を一括変更すると、どの修正で警告が消えたか分かりません。
別名保存した後は閉じて再読込し、章ID、問題位置、総文字数を照合します。警告が消えたことだけでなく、意図しない代替文字や欠落がないことを確認します。
画像検査は参照文字列と実ファイルを一対一で照合する
画像側では、二章に三枚の相対画像を置き、そのうち一件だけパスを意図的に切ります。たとえばchapters/ch02.mdが../images/map.pngを参照しているのに、実ファイルをimages/maps/map.pngへ移した状態です。
画像表には、原稿ID、記法中のパス、原稿起点で解決した場所、実ファイルの有無、画像の役割を記録します。「map.pngがどこかにある」では不十分です。同名ファイルが別フォルダにあれば、誤った一枚を表示する場合があります。
切れた一件を直すときは、原稿側の記法を直すのか、画像を戻すのかを先に決めます。正本の配置が正しいなら記法を直し、誤って画像を動かしたなら画像を戻します。両方を同時に変えると、次の出力で正しい配置を説明できません。
修正後は古いパスを検索して0件、新しいパスを検索して想定件数、実ファイルを開いて画像内容が正しいことを確認します。代替テキストも画像の内容と一致させます。
二つの検査を一枚に混ぜると戻り先を誤る
文字エラーは原稿の文字値または保存文字コードへ戻ります。画像エラーは参照記法または資産配置へ戻ります。EPUBを生成してから両方を「表示できない」とだけ記録すると、生成設定を何度変えても原稿側の問題が残ります。
出力許可は、文字表が未解決0件、画像表が実在不明0件になったときだけ出します。二つの表を一つの合計点にせず、片方に未解決があれば生成を保留します。これで「文字は直ったが画像は切れた」という状態を見逃しません。
説明用標本はUTF-8原稿二章、変換不能文字二件、相対画像三枚、切れた参照一件です。これは検査方法の例であり、この記事内でRune Studioを使って全件を完遂した実測結果ではありません。
確認済みの範囲と未確認の警告を分ける
Rune Studioの現行Mac版について、主要な日本語文字コードの読み込み、表現できないUnicode文字の赤背景、保存警告、自動保存の一時停止、画面通知が公開資料に記載されています。実際に確認できたのは、タブの文字コード選択値をShift_JISとして保存し、開き直した後も同じ選択が残ることまでです。実ファイルはUTF-8のままでした。赤背景、保存警告、自動保存停止、別名保存後の物理バイト変換は未確認なので、選択値だけで変換成功とは判断しません。
画像参照では、表紙.pngを参照する2ファイル・2箇所を使って確認しました。画像名だけを変えてもMarkdown参照は旧名のままで、新名の利用箇所は0件でした。その後、参照書換え機能で2ファイル・2箇所を新名へ更新し、外部URLとページ内リンクが変化しないことを開き直して確認しました。名前変更と同時の自動追従とは考えず、「利用箇所を数える→名前変更→旧参照を確認する→明示的に書き換える→新旧名を再検索する」の順で進めます。
文字コードの警告類は公開資料で確認できる機能、参照書換えは上記2ファイル・2箇所で確かめた結果として分けます。削除前の画面警告、閉じたShift_JIS原稿の文字コード保持、第三者EPUBの直接修復、すべての画像形式、ストア受理へは広げません。重要な原稿では複製を使い、文字と画像を別々に確認してください。
向く人と別記事へ譲る範囲
向くのは、Markdownやテキスト原稿からEPUBを作り、出力前に原稿と資産の入口検査をしたい人です。すでに壊れたEPUBしか手元にない場合、DRM付きファイルを扱う場合、販売先固有の審査を確認したい場合は別の道具や公式検査が必要です。
文字化けが生成後XHTMLのどこで起きたかを切り分ける場合は、原稿・生成XHTML・リーダー表示を順に追います。画像の挿入記法と原稿移動を詳しく試す場合は、相対パスを原稿位置から計算してください。本記事は文字と画像の二系統を出力前に閉じる入口です。
EPUB工程へ渡すときは二つの証拠を残す
検査が終わったら、生成担当へ原稿ファイルだけを渡さず、文字表と画像表の確定版を添えます。文字表には採用文字コード、修正した二件の位置、再読込後の文字数を残します。画像表には三枚の相対パス、実ファイルの場所、利用章、代替テキストを残します。
生成後に問題が出た場合、この二つが比較基準になります。原稿段階で0件だった文字がXHTMLで崩れたなら、生成処理以降を調べます。画像表の解決先は正しいのにEPUB内で欠けるなら、収録資源やpackage側の検査へ進みます。入口の証拠がなければ、同じ原稿検査を何度も繰り返すことになります。
表の版も成果物名と結び付けます。原稿を一字直したり画像を差し替えたりした場合は、以前の0件を新しい生成物へ流用せず、影響する表を更新します。文字修正だけなら文字表、画像移動だけなら画像表を再確認し、どちらを再検査したかを明記します。
生成担当が別の人なら、口頭で「確認済み」と渡さず、未解決0件になった表の保存場所を伝えます。生成物の名前にも原稿版を含め、古い表と新しいEPUBを組み合わせないようにします。入口の版が一致していれば、出力後の差を生成工程へ限定できます。
結論：文字表と画像表を別々に0件へする
二章の複製を作り、文字表には問題文字二件、画像表には相対画像三枚と切れた参照一件を登録します。文字は保存可能性と再読込、画像は原稿起点の解決先と実ファイルを確認します。未解決が両方0件になるまでEPUB生成へ進みません。
Rune Studioの文字コード警告と参照パス機能は、Rune Studioの商品ページで現行Mac版の対象範囲を確認できます。最初の一歩は、文字エラーと画像エラーを同じメモへ書かず、戻る正本の違う二枚の表を作ることです。
