EPUBの文字化けを防ぐ要点は、読める原本とUTF-8へ変換した複製を同じファイルだと思わないことです。まず原本の文字コードを確定し、編集上の置換を済ませた内容だけを別名のUTF-8ファイルへ書きます。その複製を閉じて再検査し、符号化、改行、本文がそろった時点で初めてEPUBの入力にします。
この手順なら、表示が崩れたファイルを「直ったように見える」状態で上書きする事故を避けられます。ここでは epub 文字化け を調べている人に向け、実際に保存した検証標本と命令、戻り方、合格条件を一本につなげます。
文字化けが起きた場所を先に二分する
最初の問いは「原稿を開いた時点で崩れているか」「EPUBにしてから崩れたか」です。前者は読み込み時の符号化が疑わしく、後者は生成に渡した入力やパッケージ内の本文を調べます。両方を同時に直そうとすると、原因が保存なのか生成なのか分からなくなります。
作業対象は原本ではなく複製です。検証では source-UTF-8.txt、source-Shift_JIS.txt、source-UTF-16LE.txt を別々に用意しました。三つは同じ短い日本語を持ちますが、バイト列は異なります。「画面で読めた」という感想ではなく、ファイル名と検査結果を対応させるための標本です。
原稿の一部にだけ異常がある場合も、その行をすぐ削除しません。人名、外字、記号の前後を控え、正しい文字が何かを編集判断として決めます。符号化の選択と文章の置換を一操作にすると、後からどちらが内容を変えたのか説明できません。
三つの入力を同じ命令で検査した実値
永続化した検証記録では、UTF-8標本に rune inspect text --file /private/tmp/rune-g2c3-studio-276-qfiw6clt/source-UTF-8.txt --json を実行しました。Shift_JISとUTF-16LEもファイル名だけを変え、命令の形は同じです。全命令の終了コードは0でした。
再取得した値は、UTF-8が encoding=UTF-8、lineEnding=LF、44文字、Shift_JISが encoding=Shift_JIS、LF、44文字、UTF-16LEが encoding=UTF-16LE、LF、45文字です。UTF-16LEだけ一文字多いのは、この検査結果そのものとして記録し、別形式の44文字へ無理に合わせません。どの標本をどの復号器で読んだかが、最初の合否です。
ここで失敗値は三種類あります。検出符号が想定と違う、改行が意図せず変わる、復号した本文が承認原文と一致しない、です。どれか一つでも出たら変換へ進まず、読める原本をもう一度選び直します。崩れた表示を手がかりに原本を上書きするのが最も危険な近道です。
承認本文を別名のUTF-8複製へ書く
変換先は STUDIO-276-converted-copy.txt としました。先に実行したのは rune file write --path /private/tmp/rune-g2c3-studio-276-qfiw6clt/STUDIO-276-converted-copy.txt --content-file /private/tmp/rune-g2c3-studio-276-qfiw6clt/approved-utf8-content.txt --dry-run --json です。dry-runで対象パスを確認してから、同じ命令から --dry-run だけを外して書き込みました。原本のパスは一度も出力先にしていません。
保存直後の成功応答はまだ合格ではありません。rune inspect text --file /private/tmp/rune-g2c3-studio-276-qfiw6clt/STUDIO-276-converted-copy.txt --json で別名ファイルを読み直したところ、UTF-8、LF、44文字でした。さらにSHA-256は承認本文と同じ a0c4bad89b08523b704e04e7dbdee7e141327cfe719f993d59919e351ffbdbea、復号後の文字列も一致しました。
もし44文字でも本文が違えば不合格です。文字数は同じでも、別の同じ長さの記号へ置き換わることがあります。その場合は変換済みファイルを残したまま、別の名前で二回目を作り、承認本文との差を調べます。失敗結果を消さないほうが、誤った置換を特定しやすくなります。
UTF-8複製だけをEPUBへ渡して確かめる
検証では承認済みの複製を含む三章を選び、rune epub series set で --writing-mode horizontal --language ja を設定しました。続いて rune epub volume set --number 0 --version 3.1、rune epub select、rune epub plan、rune epub export の順に実行し、最後に生成物を rune inspect epub で開きました。
生成した studio-276-260903.120000.epub はSHA-256が 078c961833b1b9d179f3da1ffaf8d545cc2cd3a23f63468cfa200771ec0e4fc8 です。構造検査は valid=true、目次は3項目、欠落資源の報告はありませんでした。OPFの言語はjaで、三章がspineとnav、NCXへ入っていることも確認しています。
ここでの合格条件は、UTF-8複製の再検査が通り、その同じ内容から作ったEPUBの構造検査が通ることです。valid=trueだけを先に見ても、原稿の選択を誤っていれば文字化けの予防にはなりません。入力のSHAと生成物のSHAを別々に残すと、どの版から作った本かを追えます。
画面の警告と販売先の結果は別の確認にする
Rune Studioの公開資料には、主要な日本語文字コードの判定、変換不能文字の赤表示、問題が残る間の自動保存停止が案内されています。一方、今回のCLI実測はファイルの検査、別名保存、再読込、EPUB生成までです。赤い背景の画素、IME入力、自動保存が止まる時刻、未保存バッファは測っていません。そのため、それらを「操作で確認した」とは扱いません。
販売先が受理するか、すべてのリーダーで同じ字体になるかも、このローカル検査の結果には含まれません。破損済みバイナリの復元やOCRも対象外です。この記事が保証するのは、読める原本を守り、承認済みUTF-8複製を再読込し、その複製をEPUB入力として構造確認するところまでです。
最後に残すべきものは三つです。触らない原本、44文字で再読込できたUTF-8複製、SHAを記録したEPUBです。この三つを同じ名前で上書きしなければ、異常が見つかっても一段前へ戻れます。現行Mac版の対応範囲はRune Studioの商品ページで確認し、まず短い章の複製で合格線を作ってから長編へ広げてください。