EPUBの文字化けは、出力後にまとめて直すより、原稿を保存する段階で変換不能文字を解消するほうが安全です。先に文字コードを直し、そのあとEPUBの目次や画像を検査します。二種類の問題を一度に追わないことが、事故を持ち越さないコツです。
文字コードの問題か、フォントの問題か
文字が ? や四角へ変わるとき、原因は一つではありません。選んだ文字コードでその文字を表現できない場合、読み込み時の判定が違う場合、表示フォントに字形がない場合があります。まず元ファイルを複製し、既知の一文と問題文字の位置を記録します。
Shift_JIS由来の三章原稿に絵文字が二件ある例なら、絵文字がその保存形式で表現できるかを先に確認します。表現できないまま上書きすると、元の文字へ戻せない可能性があります。保存形式をUTF-8へ変えるか、意味を保つ別の文字へ置き換えるかは、配布条件に応じて決めます。
Rune Studioのステータスバーで確認する
Rune StudioはUTF-8、BOM付きUTF-8、Shift_JIS、EUC-JP、ISO-2022-JP、UTF-16LE・BEなどの読み込みに対応し、ステータスバーから文字コードと改行コードを切り替えられます。選択中の文字コードで表現できないUnicode文字は連続範囲ごとに赤い背景で示し、残っている間は自動保存を一時停止し、保存時にも警告する設計です。
原稿を開いたら、ステータスバーの文字コードを読み、問題箇所へ移動します。修正前の原本は別名で残します。問題文字を直すかUTF-8へ切り替えたら、代表文、章見出し、問題箇所を読み直し、保存して再度開きます。文字が正常でも、改行コードまで意図せず変わっていないか見ます。
文字が直ってからEPUBへ進む
三章すべてで変換不能がなくなったら、EPUBウィザードのファイル選択とチャプター順へ進みます。ここで初めて目次、表紙、章順の問題を扱います。文字コードの警告が残ったまま出力を繰り返しても、原因の層が増えるだけです。
確認用原稿では、変換失敗を起こした文字を修正したあとEPUBを生成し、ローカル構造検査で有効な結果を得ました。別の文字コード確認では、タブをUTF-8・LFへ設定し、再検査で変換不能ゼロ件を確認しています。一方、今回の操作記録では、Rune Studio画面上の赤背景と自動保存停止そのものを実画面で再確認していません。
未確認を成功手順へ混ぜない
したがって、赤表示を見たという体験談としては書けません。現行機能資料にその仕組みがあることと、変換不能文字を直した後にEPUBを出力できた実測を分けて扱います。画面表示が重要なら、本番原稿の複製で赤表示と保存警告を自分の目で確かめます。
全外部リーダーの復号や、販売先が行う再変換も別問題です。完成後は提出先のプレビューで固有名詞、絵文字、異体字を重点的に読みます。Rune Studioの文字コード対応を確認し、まず一章の複製で保存し直すところから始めてください。
固有名詞を定点にする
文字コードを変えたあと、全文を目視する前に、人名、地名、記号、絵文字、長音や波ダッシュなど、壊れやすい定点を選びます。三章それぞれに一つ以上置き、保存前後で同じ文字列になっているかを見ます。正常なひらがな一文だけでは、特殊文字の破損を発見できません。
置換する場合は、意味が変わらないか著者が判断します。技術的に保存できる文字へ変えたからといって、作品として正しいとは限りません。UTF-8へ変換できる環境でも、提出先が別条件を持つならその条件を優先します。文字コードの合格、文章内容の合格、EPUB構造の合格を三つに分けると、誰が判断すべきかも明確になります。
改行コードは別の変更として記録する
文字コードをUTF-8へ変えるとき、改行コードまで同時に変更すると差分が全行へ広がる場合があります。共同作業や版管理をしている原稿では、意図しない大量差分が校正を難しくします。ステータスバーでLF、CRLF、CRのどれかを読み、変更するなら理由を残します。
一つの保存で二つの変換を行う必要がある場合も、再読込後は文字と改行を別々に検査します。章見出しが保たれたか、行数が不自然に増減していないか、空行が変わっていないかを見ます。EPUB出力へ進む前に原稿差分を小さく理解できる状態へ戻すことが、後工程の文字化け調査を短くします。
変換前後のバックアップを残す
UTF-8へ変えたファイルが正常に見えても、旧環境で必要だった原本はすぐ削除しません。変換前、変換後、EPUBへ使った版を識別できる名前で保管します。どの版を正本に切り替えたか明示し、以後の編集を一本化します。複数版を同時に編集すると、直したはずの変換不能文字が古い原稿から戻るためです。
