入稿後の手戻りを防ぐ！EPUBのファイル作り方、変換不能文字を保存・出力前に見つける

EPUB用ファイルの作り方で最初に避けたいのは、「同じフォルダだから文字コードも同じ」と決めつけることです。章と奥付を一件ずつ開き、検出された文字コード、変換の要否、次に確認する内容を表へ残します。一件でも判定が違えば、そのファイルだけを保留します。

例はMarkdownの五章とテキストの奥付一件です。実際に個別確認すると、五章はUTF-8、奥付だけがShift_JIS系でした。この時点で六件をまとめてEPUB対象にせず、奥付を別の行として扱うのが安全です。

六件をファイル名で管理する

「本文はUTF-8だった」というメモでは足りません。どのファイルを見たか、変換が必要か、変換後に何を見るかまで一行にします。

ここで「候補」は出力済みという意味ではありません。検出値がそろい、次の確認へ進める状態です。奥付は文字コードが違うため、UTF-8へ別名で用意して開き直すまで保留します。元のcolophon.txtへ上書きしないのが判断ルールです。

検出だけを先に終わらせる

六件の入口確認は、次の順なら混ざりません。

1. chapters/の五件とcolophon.txtを一覧にし、件数を6と固定します。
2. 一件ずつ開き、検出された文字コードと改行コードを記録します。隣のファイルの結果をコピーしません。
3. 選択中の文字コードで表現できない文字が示されたら、ファイル名と位置を別欄へ残します。意味が分からない文字を自動で置換しません。
4. UTF-8の五章は「変換なし」、Shift_JIS系の奥付は「変換あり」とします。ここまでで入口確認は終了です。
5. 奥付の変換、別名保存、再読込、文字数・発行者名・日付の一致は次の作業として実施します。それが終わるまでEPUB対象6件とは記録しません。

この順番なら、変換作業が途中でも「六件のうち、どれが違ったか」は失いません。フォルダ全体を先にUTF-8へ一括変換するより、誤って触る範囲を一件に絞れます。

改行コードは文字コードとは別欄に残します。たとえば五章がUTF-8でも、ある章だけCRLF、ほかがLFということはあります。改行が違うだけで文字コード変換の対象にせず、逆に改行が同じだから奥付もUTF-8だとは判断しません。六行の表で「検出文字コード」「改行」「変換不能文字」を独立させると、奥付一件の問題をフォルダ全体の問題へ広げずに済みます。変換後も、この三列を再び埋めてから採用します。

変換後の採用条件

奥付をUTF-8へ変えるときは、colophon-utf8.txtのような別名を使います。採用条件は、UTF-8として開き直せること、変換不能文字が0件であること、文字数と発行者名・発行日が元の意図と一致することです。

すべてそろった後で、上表の奥付を「候補」へ変えます。六件をEPUB対象として選ぶのはその後です。変換後の文字数や採用結果が記録できていない状態で「奥付も直った」と扱わないでください。

Rune Studioで個別検出した結果

Rune Studioの現行Mac版は、UTF-8、Shift_JIS、EUC-JP、ISO-2022-JP、UTF-16などを読み込み対象にし、変換不能文字を示し、その間は自動保存を止めると公開資料に記載されています。

今回の六ファイルでは、五つのMarkdown章がUTF-8、テキストの奥付一件がShift_JIS系と個別に判定されました。一つの章の結果をフォルダ全体へ流用していません。この事実が、六行の表を使う理由です。

一方、Shift_JIS系の奥付をUTF-8へ変換した結果、再読込後の文字数、代表文字、最終的なEPUB対象6件は確認していません。本文で示したcolophon-utf8.txtと採用条件は、次に実行する手順です。破損済みデータの完全復元、OCR、バイナリ修復も扱いません。

一件だけ違えば、一件だけ止める

EPUB用ファイルは、フォルダ単位で同じ文字コードだと仮定せず、一件ずつ入口を確認します。五章がUTF-8でも、奥付がShift_JIS系なら奥付だけを保留する。これで、問題のない五章を不用意に変換せずに済みます。

まず五章と奥付を六行へ並べ、検出値と変換要否を埋めてください。Rune Studioの文字コード機能を候補にする場合は、現行Mac版について詳しくはこちらで確認できます。