EPUBで文字化けを見つけた後、原稿側で最初に行うのは、同じ作業用複製を「開いた直後」「別名保存した直後」「閉じて再オープンした後」の三状態で比べることです。開いた直後から期待文字と違えば読込側、開いた直後は正しく保存後の系統で差が出れば保存条件または再読込側を調べます。三状態が同じなら、この試験だけでは原因を原稿の読込・保存へ絞れません。
この記事の中心は、EPUB内部を端から端まで追うことではありません。原稿正本を守りながら、読込時に崩れたのか、保存を境に崩れたのかを一つの比較表で分けることです。原稿から生成XHTML、リーダー表示、再生成までの追跡は、この三状態で差が出ない場合に別工程で行います。
原稿正本を保全して比較条件を固定する
EPUBで崩れた章と前後の文字列から、生成に使った原稿版を特定します。ただし、正本は開いて保存せず、同じ版から作業用複製を一つ作ります。原稿版を特定できない場合は、似たファイルを選んで続けず保留にします。
比較前に、作業用複製のファイル名、SHA-256、更新日時、想定文字コード、その根拠、期待文字、期待コードポイントを記録します。想定文字コードの根拠には、納品仕様、作成者の記録、以前正常に読めた環境などを使います。候補を順番に試し、見た目が自然なものを採用する方法では、別の場所が壊れていても気づけません。
比較中に変える条件は一つです。読込指定を調べる回で保存先やフォントも変えると、どの条件が差を生んだか分からなくなります。
一つ目は「開いた直後」を記録する
想定文字コードで作業用複製を開き、まだ保存しない状態を①とします。問題箇所だけでなく、先頭・中央・末尾に置いた識別文も確認し、表示された文字列とコードポイントを記録します。
①ですでに期待文字と違う場合は、読込指定、想定文字コードの根拠、作業用複製の元版を調べます。この状態を別名保存すると、誤って読んだ結果を別ファイルへ固定する恐れがあるため、その試行はそこで止めます。
①が期待どおりなら、少なくとも「開いた直後に観察した文字」は一致しています。ただし、画面の選択値が物理ファイルのバイト列を証明するわけではありません。この違いは後で扱います。
二つ目と三つ目は保存と再オープンを分ける
①が正しい場合だけ、別名の検証ファイルへ保存します。元の作業用複製と上書きしないことが前提です。保存操作が終わり、同じタブをまだ閉じていない状態を②として、同じ文字位置を記録します。
次に②の検証ファイルを閉じ、保存した別名ファイルを新しく開きます。この状態を③とし、同じ期待文字、先頭・中央・末尾の識別文を記録します。②と③を一つの「保存後」にまとめないのが要点です。
②で変われば保存操作を境に差が現れています。②は同じで③だけ変われば、保存後のファイルを再び読む境界で差が現れています。ただし、物理バイトを確認していない段階では「保存が変換した」「再読込だけが誤った」と断定せず、保存前後のファイルを分けたまま次の検証へ渡します。
三状態の差から戻り先を選ぶ
- ①が期待文字と違う：読込側へ戻る。想定文字コードの根拠と元版を確認し、保存しない。
- ①は正しく②で変わる：保存操作の条件を調べる。元の複製を残し、別名ファイルだけを検証対象にする。
- ①と②は正しく③で変わる：保存後ファイルの再読込条件を調べる。保存成功と決めつけない。
- ①・②・③がすべて同じ：原稿の三状態では差を再現できていない。次は生成XHTMLとリーダー表示を追う。
- 途中で原稿版や想定文字コードが不明になる：判定不能として止める。
この分類で決まるのは、次に調べる境界です。原因名を自動で確定するものではありません。とくに②と③の差は、表示文字だけでなく物理ファイルの検査が必要になるため、記事内で未確認の操作結果へ繰り上げません。
「﨑」を含む最小標本で一条件だけ試す
固有例には「編集者の﨑本さんが確認した」の一文を使います。期待文字は「﨑」、コードポイントはU+FA11として記録します。この文字が特定の文字コードで必ず壊れるという例ではなく、三状態で同じ位置を見失わないための識別子です。
作業用複製には、この一文と前後数行だけを入れます。比較表の一行に、作業用ファイルID、想定文字コード、①開いた直後、②別名保存直後、③再オープン後、次の調査先を並べます。
見た目が似た「崎」へ置換して直ったことにしません。期待文字そのものを変えると、読込と保存のどちらで差が生じたかを判定できなくなるからです。
選択値と実ファイルの文字コードを分ける
Rune Studioの公開資料には、複数の日本語文字コード読込、文字コード・改行コードの選択、変換不能文字の赤背景、保存警告、自動保存停止が記載されています。これらは三状態の診断に使える機能ですが、画面の選択値だけで物理バイト変換の成功を判断してはいけません。
実際に確認した標本では、Shift_JISのタブ選択値が閉じて再オープンした後も保持された一方、実ファイルはUTF-8のままでした。つまり、UI上の選択値だけでは物理バイト変換の成功を判断できません。
赤背景、保存警告、自動保存停止、別名保存後の物理バイト変換、実際のShift_JISファイル再読込、この記事の三状態を同一標本で比べるUI操作は未確認です。本文の三状態は製品非依存の診断手順として示し、Rune Studioで完遂済みとは書きません。
三状態が同じならXHTMLとリーダーへ進む
①・②・③が同じなのにEPUBだけが崩れる場合、本記事の原稿検査は終了です。次の工程で生成XHTMLを開き、複数リーダーを比べ、再生成の戻り先を決めます。
EPUB出力前に原稿全体を整形する作業も本記事の対象外です。一括変換、全原稿置換、CSS修正、フォント診断、販売先での変換は扱わず、三状態で原稿の読込・保存境界を分けるところを終了点にします。
結論：読込か保存かを三状態で判定する
EPUBの文字化けから原稿へ戻ったら、正本を保全し、同じ版の作業用複製で①開いた直後、②別名保存直後、③閉じて再オープン後を記録します。①で差があれば読込側、②または③を境に差があれば保存・再読込側へ戻ります。
三状態が同じなら、原稿の読込・保存では差を再現できていません。その時点で本記事を終え、EPUB内部とリーダーを追う別工程へ渡します。Rune Studioを使う場合も、選択値と実バイトが一致するとは限らないことを前提にし、未確認の警告や画面操作を成功済みにしないでください。現行範囲はRune Studioの商品ページで確認できます。
