Encoding control belongs at the start of book creation, before time is spent on covers, navigation, and final layout. A useful preflight does more than ask whether a chapter opens. It identifies the source representation, checks that the intended prose survived decoding, and separates technical conversion from editorial substitution.
The fixed STUDIO-244 evidence is a baseline rather than a dramatic failure demo. Rune distinguished the same passage saved in five encodings, and the opened work tab read back UTF-8. The run did not visually operate the red highlight for an unsupported character, and it did not authorize replacement of any character with a look-alike.
Put Character Decisions Before Book Design
Create a manuscript gate before configuring the publication. List every chapter with its path, digest, detected encoding, line ending, and a small set of approved phrases. A changed digest reopens the gate. This prevents a source revision from slipping into an otherwise finished book merely because the filename stayed the same.
Keep this check separate from spelling and typography. Encoding asks whether the intended characters can be represented and recovered. Editorial review asks whether those characters are correct. A technical operator should not silently change a rare name, historic glyph, or mathematical symbol just to obtain a clean converter response.
Distinguish Decoding From Target Encoding
Two questions are often collapsed. First: which encoding correctly interprets the current bytes? Second: can the resulting Unicode text be saved in the target format without loss? A file can be decoded correctly yet contain a character that Shift_JIS cannot represent. It can also be fully representable but opened under the wrong assumption.
For an EPUB workflow, normalize an approved working copy to UTF-8 only after the first question is settled. Then reopen the saved copy and compare it with the approved source. If a legacy deliverable is also required, run its convertibility check as a separate output condition rather than weakening the EPUB source.
The Five-File Baseline and Its Limits
The STUDIO-244 passage produced these inspection results: UTF-8/LF/39 characters, Shift_JIS/LF/39, EUC-JP/LF/39, UTF-16LE/LF/40, and UTF-16BE/LF/40. The selected working tab then reported encoding=UTF-8. The five files were known representations of the same controlled text, so the expected classification was established in advance.
No unresolved character was reported for that passage. Therefore the result proves detection of the specimens and tab-state readback, not a successful visual highlight of a conversion error. When documentation says the interface can identify problematic characters, treat that as product information until the named UI route is actually operated and recorded on the current build.
Use this clean baseline to test the inspection setup itself. If the tool misidentifies one of the known specimens, stop before introducing a harder manuscript. If all five results match, archive the outputs with the fixture description. The baseline then tells a later operator that a new rejection belongs to the project input, rather than to an unverified test environment.
When One Code Point Cannot Be Converted
If a target conversion rejects a character, record the code point, chapter path, line, surrounding phrase, and intended meaning. Preserve the failed revision. Then choose among three editorial outcomes: retain the character by using UTF-8, replace it with an approved equivalent, or rewrite the phrase. Only the content owner should approve the latter two.
Never replace a glyph merely because another one looks similar on your screen. Different code points can sort, search, copy, and render differently. Store the approved decision beside the new source digest. If no approved replacement exists, keep the build blocked rather than producing a book whose wording has changed without review.
Prove the Saved Revision Before Creating the EPUB
After all holds are resolved, save a new UTF-8/LF candidate. Close and reopen it, rerun the encoding inspection, and compare the recorded phrases. The candidate qualifies only when the encoding and line ending match the house format, the intended text matches the approval record, and unresolved holds are zero.
This is the practical route to create EPUB without encoding errors: admit a precise source revision, then package it. Select the approved digests in chapter order, generate a newly named EPUB, and reopen its content XHTML. Search for the approved rare characters and phrases. A structurally valid archive does not by itself prove that the prose was decoded correctly.
Recover at the Earliest Failed Layer
If the saved source fails, return to the prior approved text and create another candidate. If the source passes but generated XHTML differs, retain both artifacts and investigate conversion. Do not hand-edit the XHTML inside the package, because the repair would be detached from the manuscript and disappear during regeneration.
After correction, rerun the entire path: source digest, decoding, target save, reopen, content comparison, generation, package integrity, and XHTML sentinels. Repeating already-passed checks matters because a narrow replacement can change line endings, chapter ordering, or nearby punctuation.
Finish With a Character Decision Register
The release register should contain the five baseline results, the actual chapter candidates, every held code point, its approved disposition, the reopened UTF-8/LF values, and the generated EPUB digest. It should also name any visual step that remains unmeasured. For STUDIO-244, the graphical red-highlight behavior was not operated in the fixed run.
Retailer acceptance and identical rendering across reading applications are later gates. This preflight’s job is narrower and valuable: every selected chapter is tied to an approved textual identity, every character change is authorized, and another operator can reproduce why the source was admitted before book creation began.
