The safest response to garbled text is to stop before saving. Preserve the original bytes, identify a plausible encoding, convert into a separately named UTF-8 file, and reopen that result before creating an EPUB. This guide tests missing characters in EPUB with a three-line, 36-character Shift_JIS specimen. Red highlighting and autosave suspension are documented product behavior; their pixels and timing were not observed in this deterministic file test.
Preserve the Original Byte Sequence
When squares, replacement glyphs, or nonsensical punctuation appear, do not “fix” the visible text and overwrite the file. Saving through the wrong decoder can destroy the byte sequence that another encoding would interpret correctly. Keep the source read-only and create a dated working copy.
The controlled source here is legacy-source-sjis.txt. It contains three lines and 36 decoded characters, including a Japanese heading and sentence. Record its SHA and size before inspection. Every repair is written elsewhere so the original remains available for another interpretation.
Record Encoding, Newlines, and Decoded Length
Inspection identified the source as Shift_JIS with LF line endings and 36 characters. Character count refers to the correctly decoded Unicode string, not bytes or columns on screen. Keeping newline style beside encoding helps distinguish a text change from a line-ending conversion.
Detection is a candidate, not an editorial verdict. Read the heading, names, punctuation, and a representative sentence. If two decoders produce plausible output, preserve both views without saving and ask which content is authoritative.
Convert Into a Separately Named UTF-8 File
The accepted string was saved as repaired-utf8.md. Reinspection returned UTF-8, LF, and the same 36 characters. Compare the two decoded strings line by line, including the final newline, before treating the conversion as successful.
Equal appearance can conceal different code points. Inspect names and sensitive symbols such as wave dashes, quotation marks, and combining marks individually. A replacement character or undecodable byte keeps the item blocked until its intended character is established.
Reopen the EPUB and Search Its XHTML
Generate from the repaired file, close the result, and open the EPUB package again. Search the chapter XHTML for the expected three-line specimen and inspect the resource list. The controlled repaired EPUB reopened without missing resources and retained the intended text.
Tie the OPF, spine, XHTML, and inspection report to one EPUB SHA. A completion notification cannot prove which trial file was inspected. Zero matches usually points to the wrong source or excluded chapter; altered text points back to decoding, normalization, or export transformation.
Keep Red Warnings in a Separate Interface Test
Rune Studio’s public material describes red indication and autosave suspension around encoding problems. This run read file content and encoding settings through a deterministic command path. It did not deliberately open a mis-decoded document and measure the warning color or autosave timer.
A future UI test should record the application version, input SHA, selected encoding, exact warning text, and file timestamps before and after a save attempt. A visible warning and preservation of the original bytes are separate acceptance checks. Documentation does not substitute for observed screen behavior.
Compare Content, Not Just Character Totals
Two strings can each contain 36 characters while differing in one crucial name. Approve the repair by line equality and selected code-point checks, not by total alone. Japanese variants, punctuation width, and composed versus decomposed marks deserve explicit attention.
When a difference appears, place the original bytes, a known-good edition, and the author’s intended spelling side by side. Record the chosen character, create a new repaired file, and repeat the EPUB inspection. Do not silently normalize uncertain text.
Hand Off Three Identified Artifacts
The handoff should identify the original Shift_JIS/LF/36-character file, repaired UTF-8/LF/36-character file, and reopened EPUB with no missing resources. Mark red highlighting, autosave timing, complete recovery of corrupted data, OCR, and binary repair as outside this measured result.
Preserve, convert separately, reopen, and compare: that order prevents an uncertain display from becoming irreversible damage. The next operator should use the recorded SHAs to identify all three artifacts and make the editorial decision about adopting the repaired version.
Run a Small Character-Risk Inventory
Before converting a full book, search a copy for characters that deserve explicit review: uncommon names, compatibility ideographs, combining marks, emoji, and punctuation imported from older software. Select a handful of specimens and record their expected code points. This inventory does not predict every failure, but it gives the reviewer known anchors in addition to the 36-character control sentence.
After conversion, compare these anchors in the UTF-8 file and in exported XHTML. A font may lack a glyph even when the character survived correctly, so distinguish a missing code point from a display-font problem. The former changes text data; the latter requires a rendering or font-support decision.
Keep Backups Outside the Adoption Decision
Do not delete the legacy source after the UTF-8 repair is approved. Store it with its original SHA and a note that it is archival, not the editing master. The repaired file can become the new master only after the project owner accepts the comparison report.
When more chapters are converted, maintain a durable ledger with source encoding, source SHA, repaired SHA, reviewer, and adoption date. This prevents a later batch from being decoded again with different assumptions. It also makes a safe rollback possible without asking which similarly named copy was the last trustworthy one.