Saving a Japanese manuscript safely in UTF-8 means finding characters that would be unrepresentable in the wrong target before saving, then proving that the UTF-8 file kept them. Readable Japanese in an editor window alone cannot satisfy that promise. The workflow must preserve the source, count unconvertible characters, reject a lossy path, save as UTF-8, and inspect the closed file.
The STUDIO-173 synthetic manuscript contains “𠮷,” “🙂,” and “☕.” The test detected all three as unconvertible to Shift_JIS, rejected that save path, and then verified zero UTF-8 encoding errors and zero unconvertible characters after UTF-8 save. This is the same detection-and-recovery promise as the Japanese article, not merely a clean-file readback.
Define an exit value before opening the source
For this run, the accepted file had to be detected as UTF-8 with LF line endings. Its strict UTF-8 error count and UTF-8 unconvertible count both had to be zero. Three visible checkpoints—including the three target characters—also had to match. A matching character count cannot replace those checkpoints because substitutions can leave the total unchanged.
Preserve the received file. Give the working copy and the UTF-8 delivery candidate different names, and record which one was opened. If the received source already contains replacement symbols such as � or a literal question mark where a Japanese character belonged, saving it as UTF-8 will faithfully preserve the damage. Return to a source that can still be decoded correctly.
The target is therefore specific: the closed output must be independently rediscovered as UTF-8 and its controlled text must remain intact. It is not enough to report a menu choice.
Choose revealing checkpoints rather than an ASCII-only identifier. Include an author name, unusual place name, Japanese punctuation, or another expression that would expose a wrong decoder. The ending marker also detects a truncated save that a correct opening paragraph would miss.
Count the three characters that Shift_JIS cannot store
A strict character-by-character Shift_JIS preflight found three failures: “𠮷” at U+20BB7, “🙂” at U+1F642, and “☕” at U+2615. This is actual unconvertible-character evidence. Replacing the rare surname character, deleting the emoji, or substituting question marks would merely hide the failure.
Rune Studio's development CLI returned the requested Shift_JIS setting during a dry run, but it did not report those three characters as errors. The workflow therefore used the strict scan as the blocking detector and kept Rune's response as setting evidence only. It also does not claim that the red warning described in the Mac product documentation was visually observed.
Set UTF-8 in Rune Studio and name the destination
The controlled UTF-8 copy was opened in the dedicated workspace with rune tab open. After the lossy Shift_JIS path was rejected, the tab was explicitly set to UTF-8. The destination remained the numbered STUDIO-173 working file, not the preserved received source.
Rune Studio's current Mac documentation describes highlighting characters that cannot be represented in the chosen encoding and pausing automatic saves while those characters remain. The command-line evidence did not measure the color or timing of that interface behavior. Treat it as documented product behavior, not as a warning visually observed in this specimen.
When a UI warning appears, identify the exact character and the required delivery encoding. Do not silently replace it with a similar glyph. UTF-8 can represent Japanese text broadly; an unexpected warning may indicate that a different output encoding is still selected or that the source was already decoded incorrectly.
Build the handoff record from a closed file
After the file was closed, an independent Rune text inspection targeted the saved path and returned UTF-8 with LF. A strict UTF-8 validation found zero malformed sequences, a UTF-8 representability scan found zero unconvertible characters, and the decoded text matched the controlled source—including “𠮷,” “🙂,” and “☕.” These are the measured exit values supplied to the recipient.
Record the input path, destination path, detected values before and after saving, checkpoints, and inspection time. A hash can connect the inspected artifact to the file actually handed off. The recipient can then verify the file without reproducing the editor session.
This distinction matters with UTF-8 text editors: a tab can display the requested setting while a different file is delivered, or an unsaved buffer can look correct while disk still holds an older revision. Close-and-inspect removes those ambiguities.
Return to the stage that owns the failure
If text is wrong immediately after opening, return to source selection and decoding. If the tab looks correct but the closed file is not detected as UTF-8, inspect the destination and save setting. If the closed text passes but exported XHTML loses a checkpoint, investigate chapter selection or EPUB conversion rather than re-encoding the accepted manuscript.
The acceptance contract is explicit: three characters are rejected on the Shift_JIS path; the UTF-8 file returns zero malformed sequences, zero unconvertible characters, and identical decoded content. The run did not test automatic recovery of unknown legacy encodings, reconstruction of already lost characters, or rendering in every reading system.
The deliverable is not a statement that UTF-8 was selected. It is a specific saved file that another inspection recognizes as UTF-8. By separating display, tab configuration, disk persistence, and downstream packaging, the workflow protects correct Japanese text from unnecessary transformations and sends a failed unit back to the smallest responsible step.
For a multi-chapter handoff, repeat the closed-file check for every changed chapter. A passing control chapter cannot cover a newly supplied afterword or a credits page that introduces different characters. Keep accepted chapters outside the conversion set, attach each result to its revision, and combine them only after their individual paths and hashes are known.