EPUB生成で文字化けを持ち越さないためには、UTF-8コピーが単独で読めることではなく、実際に選択した章がそのコピーとどうつながるかを生成前に確認します。つながりを示せない原稿は、構造検査が通っても配布候補へ進めません。epub generateの安全な完了条件は、入力の同一性と生成物の構造を別々に確認することです。
STUDIO-383の固定試行は、この入力確認で不合格になります。44文字の日本語コピーはUTF-8/LFで再読込できました。しかし、選択された三章は英語の固有標本であり、コピーと同じ本文ではありません。生成EPUBはvalid=trueでも、文字コピーが本へ流れた証拠にはならないためです。
44文字の合格だけでは本の合格にならない
文字コード検査は必要ですが、対象を明確にしなければ効きません。保存済み記録では、UTF-8とShift_JISがLF・44文字、UTF-16LEがLF・45文字として検出されています。別名コピーもUTF-8、LF、44文字で再読込されました。
この結果が答えるのは「別名コピーを正しく復号できるか」です。「生成に使った三章がそのコピーから作られたか」には答えません。前者だけを後者の合格へ流用すると、文字化けの確認対象が途中で入れ替わります。
生成前の記録には、コピーのpathとSHAだけでなく、選択章との関係を一行追加します。関係を確認していない状態は空欄ではなく、不合格として扱います。確認されていないものを「同じはず」として進めないためです。
採用コピーの中身を文字列で固定する
approved-utf8-content.txtとSTUDIO-383-converted-copy.txtのSHAは、ともにfc70e9d5760d2252f7378372e49983270531119db30cc303c7c68a0d33dab465です。内容はSTUDIO-383 章頭 漢字 カタカナ ABC 123で始まり、STUDIO-383 章尾で終わります。
rune file writeの保存済み記録にはdry-runと実行があり、後続のrune inspect text --fileはUTF-8、LF、44文字を返しました。承認用ファイルとの復号本文一致も、この二つの短文ファイル間では成立しています。
ここでは、文字数だけでなく実際の文字列を控えることが重要です。別の44文字でも、文字数検査は通ります。章頭と章尾の固有文字列を持っていれば、次の選択章に同じ本文があるかを直接調べられます。
選択された三章は別の標本だった
生成コマンドが選んだのはchapter-01.md、chapter-02.md、chapter-03.mdです。各ファイルにはCASE-START-1 STUDIO-383 dedicated sample.のような英語文と、章番号に対応する終了マーカーがあります。採用コピーの日本語本文は含まれていません。
rune epub selectとrune epub planの保存済み応答は、三パス、fileCount 3、chapterCount 3、全章includeInTOC=true、planのvalid=trueを示します。これは選択と計画の記録として有効です。しかし、選択した三章が採用コピーと同じ内容だとは示していません。
生成後のp001.xhtmlからp003.xhtmlにも、選択章と同じdedicated sampleが残っています。つまり、選択章からXHTMLへの流れは読めますが、UTF-8コピーから選択章への流れはありません。代表文一致を主張できない理由はここにあります。
valid=trueが証明したのは構造だけ
固定EPUBのSHA-256はbdae6fd52e9a27e594a570a2d2a079f98f71cfb593df9165283dff0469c1521bです。ZIP内は11項目、nav 3、NCX 3、spine 6、画像資源0、画像参照0、欠落0で、保存済み検査はvalid=trueでした。
この値から、三章の構造、ナビゲーション、収録資源の欠落がないことは確認できます。文字列が承認版と同じであることや、文字化けが起きていないことは、構造値だけでは決まりません。正しいUnicodeとして保存された別本文でもvalid=trueになり得ます。
したがって、今回のEPUBは構造標本としては合格、採用本文の引き渡しとしては不合格です。一つのvalidを本全体の合格へ広げず、何を検査した値かを分けて書きます。
この試行を不合格の引き渡し票にする
失敗版を削除すると、なぜ停止したかを次の担当者が再現できません。今回は、採用コピーSHA、三つの章SHA、EPUB SHAを残し、関係欄に「採用コピーと選択章は別本文」と記録します。構造検査の数値も消さず、統合合格だけを否定します。
不合格理由は、符号化が検出できなかったことではありません。UTF-8コピーは読めています。画像やnavが欠けたことでもありません。検査したコピーが生成入力として選ばれていないことです。戻る先が明確なら、無関係な構造設定を触らずに済みます。
この分類は、偶然読めるEPUBを成功扱いするのを防ぎます。出力ファイルが存在することと、承認本文を出力したことは別の事実です。
次の試行は選択直前で接続を作る
回復では、現在の固定EPUBを上書きしません。新しい試行番号を付け、採用コピーを実際に使う章版を別名で作ります。以下は必要な再試験の手順であり、今回の固定artifactでは未実施です。
- 採用コピーのSHAと章頭・中央・章尾の文字列を固定する。
- その本文を収録する新しい章ファイルを作り、保存後に再読込する。
rune epub selectへ渡すパスと、新しい章のSHAを記録する。rune epub planで三章の順序と目次対象を確認する。- 別名EPUBを生成し、構造検査後にXHTMLの三つの文字列を読む。
- コピー、選択章、XHTMLの関係が一つの新しい試行で確認できた場合だけ配布候補にする。
途中で差が出たら、最初に一致しなくなった境界へ戻ります。コピーと章が違えば章作成へ、章とXHTMLが違えば選択または生成へ戻します。別の符号化を順番に試すのではなく、差が生まれた場所だけを直します。
EPUB Generateで防げる範囲を決める
今回の固定証拠から「文字化けを防いだ完成EPUB」とは言えません。言えるのは、三種類の符号化を検査し、44文字のUTF-8コピーを保存・再読込したこと、そして別本文の三章EPUBが構造検査を通ったことです。接続がないため、この試行の正しい結果は配布停止です。
実際の変換不能エラー、画面上の赤い表示、自動保存停止、未保存バッファ、IME、読書アプリの表示、KDP受理は未実測です。公開資料に書かれた機能を、今回操作した結果として表現しません。
epub generateで事故を持ち越さないとは、成功応答を増やすことではありません。検査した本文が選択章へ入っていないと分かった時点で止め、次の試行へ明確な戻り先を残すことです。新しい接続試験が完了するまでは、現在のEPUBを構造標本以上に扱わないでください。
