A source can open on a Mac and still be unsafe to edit. The application may have guessed the wrong encoding, a second copy may carry different line endings, or an older tab may later overwrite a newer disk version. A dependable Mac EPUB editing workflow therefore starts by identifying the bytes, not by trusting the way the first screen happens to look.
The controlled STUDIO-229 test used the same short Japanese passage in five encodings. Rune’s text inspection identified each file, and an opened working tab reported UTF-8 after its setting was applied. The test did not deliberately display a mis-decoded file or overwrite it, so this article keeps those visual and destructive scenarios outside the measured claim.
The First Risk Is Choosing the Wrong Original
Begin with an inventory before opening anything for correction. Record the path, modification time, byte size, and SHA-256 digest of every plausible source. If Finder shows chapter.txt, chapter copy.txt, and a download with the same visible name, the digest prevents a familiar label from becoming false proof of identity.
Mark one file as the untouched source. Do not use it as the experiment. The editing candidate should be a separately named copy whose intended encoding and line ending are written in the work receipt. This creates a return point if the application’s interpretation is wrong or if another program changes the disk copy during the session.
Let the Bytes Name the Encoding
In the measured run, inspect text --file was applied to five representations of one passage. The results were UTF-8/LF/39 characters, Shift_JIS/LF/39, EUC-JP/LF/39, UTF-16LE/LF/40, and UTF-16BE/LF/40. The extra character in the UTF-16 readings reflects the inspected representation; it is a reason to compare the named results rather than expect every encoding to report the same count.
These values show that the detector distinguished the five specimens. They do not show what a deliberately wrong decoding would look like in Rune Studio’s graphical editor. If a real file produces replacement symbols or implausible punctuation, preserve it, inspect its bytes, and choose the decoding from evidence. Do not resave it merely to see whether the screen improves, because that can turn a reversible interpretation problem into permanent data loss.
Make One UTF-8/LF Editing Copy
After identifying the original correctly, create a working copy in the project’s house format. For this workflow that format is UTF-8 with LF. Open that copy as a tab, apply UTF-8, and read the setting back. STUDIO-229 reached that last measured point: the working tab returned encoding=UTF-8.
Then check three sentinels from different parts of the manuscript—a heading near the start, a rare character in the middle, and the final line. A setting value alone says how the tab is configured; the sentinels say whether the intended prose survived. Compare them with the untouched source, and keep the working-copy digest beside the encoding result.
A Tab Setting Is Not a Saved-File Receipt
The tab response is an application-state observation, not proof of bytes written to disk. To establish persistence, save only the named working copy, close it, reopen the file from disk, and inspect it again. The acceptance row should contain the reopened encoding, line ending, character count, sentinels, and new digest.
That save-and-reopen sequence was not executed as a destructive wrong-decoding test in the fixed evidence. Treat it as the operator’s release procedure, not as a claim that the dangerous case has already been demonstrated. If the reopened copy differs, retain both versions and return to the last verified source instead of repeatedly saving over the same path.
Handle External Changes Without Overwriting Evidence
Mac editors often coexist with sync clients, scripts, or another application. If the disk file changes while an older tab remains open, stop before saving. Give the disk version and the unsaved tab content separate names, compute both digests, and compare the three sentinels. Only then decide which edits should be carried into a third candidate.
This is a synchronization conflict, not necessarily an encoding failure. Keeping those diagnoses separate matters: changing the character set cannot restore sentences that were overwritten by an old buffer. The fixed run did not operate this conflict in the UI, so any warning dialog, button label, or automatic backup behavior must be verified in the actual app version before it is documented as a fact.
Export Only From the Admitted Copy
The file admitted to EPUB generation should be the reopened UTF-8/LF candidate, identified by digest. Do not select a source merely because it is the newest item in a folder. Record the selected path and digest in the export note, then inspect the generated content XHTML for the same sentinels. Package validity and correct prose are different gates: a well-formed EPUB can faithfully contain garbled input.
If any sentinel fails after generation, keep the EPUB for diagnosis and trace the first divergence. When the reopened source is correct but XHTML is wrong, investigate conversion. When the source itself is wrong, repair a new source copy and generate a newly named EPUB. Avoid patching the packaged XHTML, since that breaks the source-to-output chain and will be lost on the next export.
Close With a Mac-Specific Handoff
The handoff should identify the untouched original, the accepted working copy, and the exported candidate separately. For each, include a path, digest, and role. Add the five measured encoding results, the working tab’s UTF-8 readback, the sentinel comparison, and any save-and-reopen result performed for the real manuscript.
Finally, list what remains unmeasured. In this evidence set, a visually mis-decoded editor state and a dangerous overwrite were not operated. Reader rendering and storefront ingestion are also separate from source safety. A careful Mac EPUB editing receipt is complete when another operator can locate the same revision, explain why it was admitted, and repeat the checks without relying on the first editor’s memory.