文字化けを直す最後の手段より、文字化けしたファイルを作らない順序の方が重要です。テキストエディタ 文字化けの予防では、原本の形式を確定し、保存用複製で変換不能候補を解消し、開き直してからEPUBへ渡します。読めない表示のまま自動保存させないことが最優先です。
保存用複製とEPUB出力を二段階で試した
同一文のUTF-8、Shift_JIS、UTF-16LEを検査したところ、検出形式は入力と一致し、復号文字数は288、288、289でした。保存用UTF-8版を閉じた後に調べるとUTF-8・LFで、内容一致も確認できました。その複製から出したEPUBはvalid=true、spine6、navとNCXありです。
予防の失敗は、文字化けした表示を見ながら一部だけを手修正し、そのまま原本に上書きすることです。目に付く箇所を直しても、目に付かない変化や末尾欠落が残ります。復旧時は原本から新しい複製を作り、復号方式を正しく選んで再検査します。
変換不能文字の赤表示と自動保存停止は公開製品資料で確認しましたが、このCLI試験ではUIを実測していません。合格は、原本が未変更で、複製が意図した形式と改行で再読込みでき、EPUBのローカル構造検査も別途通ることです。
保存を許可する前に置換文字と末尾語を調べる
文字化けした表示を上書きしないため、開いた直後は読み取りだけを行います。冒頭、固有名詞、末尾語に加え、置換文字�の件数を検索します。0件でも誤復号がないとは限らないため、文字コード候補ごとの三地点比較を続けます。正しく読めた複製だけに保存権を与え、原本は閉じたまま残します。
保存後は別の読み取りでUTF-8、LF、文字数、末尾語を確認します。値が違えば自動保存や外部更新の履歴を調べ、原本から新しい複製を作り直します。生成EPUBのvalid値はこの保存ゲートを通った後に評価し、前段の不合格を覆しません。
自動保存が止まる前提に頼らない防護
製品資料に自動保存停止が書かれていても、すべての誤復号で同じ警告が出るとは限りません。原本を複製し、複製の権限を読み取り専用にして最初の確認を行えば、画面警告がなくても上書きを防げます。正しい復号条件が決まった時点で、新しい編集用ファイルへ内容を書き出します。
保存可能にした版では、置換文字件数、三地点の語、文字数、改行を保存前後で比べます。外部更新通知が出た場合はさらに別名へ退避し、古いタブから保存しません。複数の防護を重ねても、それぞれがどの事故を防ぐかを区別します。
EPUB出力は最後の確認です。構造がvalidでも入力の確認語が違えば差し戻し、入力が同じで構造だけ失敗したなら生成設定へ戻ります。
保存ゲートは288文字の一致で閉じる
同一文のUTF-8、Shift_JIS、UTF-16LEを検査し、方式はそれぞれ識別され、復号文字数は288、288、289でした。保存対象はUTF-8標本です。タブ設定を確認した後、ワークスペースを閉じ、再検査でUTF-8・LFと全文一致を得ました。保存SHAはa65fcb751d8c89f862ad1249c482b57f62b2e8d2ff7ab933ca7f02c63d596902です。
EPUBゲートは別の生成物で判定する
保存合格した複製だけを1章の検証本へ渡しました。出力後のローカル検査はvalid=true、spine6、画像0、navとNCXありでした。エディタで読めることはパッケージ合格を意味せず、EPUBがvalidでも入力時点の文字化けを直してはくれません。二つのゲートへ同じ合格印を流用しないことが重要です。
事故が見えたら未変更の複製へ戻る
置換文字�や固有名の崩れを発見したら、その画面で入力し直さず原本を閉じます。未変更の複製を別の復号条件で開き、冒頭、固有名、末尾確認語を比べます。今回のCLIでは赤背景や自動保存停止を目視していないため、それらが必ず救ってくれる前提にも立ちません。
公開準備の完了票には、再読込みUTF-8・LF、全文一致、保存SHA、EPUBのvalid、spine6、画像0を分けて記載します。破損済みバイトの完全復元や販売先の受理は範囲外です。元原稿は両ゲートが通るまで残します。
EPUB展開後はOPFだけでなく、生成XHTMLの冒頭・固有名・末尾も検索します。コンテナがvalidでも、正しくない入力が正しく梱包される可能性はあるためです。三つの確認語が保存複製と生成本文で一致すれば、テキストゲートからパッケージゲートへの受け渡しを説明できます。
再出力時は旧EPUBを上書きせず、保存複製SHAと生成EPUB SHAの組を新しい記録にします。どの本文からどの本ができたかを固定し、画面上の「最新」という印象に依存しません。
文字列比較では、Unicode正規化や改行正規化を行うなら規則を記載します。見た目が同じ結合文字を無断で同一扱いすると、入稿先の検索や字数が変わる可能性があります。まずバイト一致、次に必要な正規化後一致を別々に報告します。