Character encoding has two directions: decoding bytes into text and encoding text for a new save. To change text editor character encoding safely, decode the Shift_JIS source correctly first, then write an independent UTF-8 copy. Forcing a Shift_JIS byte stream to open as UTF-8 is not conversion; it is the wrong starting interpretation.
Converting the correctly decoded copy
The Shift_JIS specimen decoded to 288 characters. It was opened in the controlled workspace, assigned UTF-8 for the working copy, written as UTF-8 bytes, and independently inspected after closing. The final file reported UTF-8 with LF, and its decoded content matched the starting passage. That sequence distinguishes a genuine conversion from merely changing a label.
Warning signs include damage in a mixed kanji-and-katakana checkpoint or an unexplained character-count change. If either appears, stop saving the damaged duplicate and start again from the untouched Shift_JIS source. Manual retyping hides both omissions and the original decoding mistake.
The documented red highlight and autosave pause are interface protections for unrepresentable characters; this command-line inspection did not measure their appearance or timing. Accept the conversion when the source remains available, the new copy reopens as UTF-8 with the intended line ending, and all selected checkpoints match. OCR and recovery of already corrupted bytes are separate problems.
Three characters that make the decision concrete
The persistent UTF-8 specimen contains 𠮷, 🙂, and ☕. A strict Shift_JIS encoder rejected all three, producing an unrepresentable-character count of three. Rune's encoding dry run itself exited successfully, but its command response did not expose those character positions. That distinction matters: a successful setting request is not evidence that the proposed destination can preserve every character in the manuscript.
What the documented red warning can establish
Rune Studio documentation describes a red editor background on characters that the selected encoding cannot represent, a save warning, and a pause in automatic saving until the conflict is cleared. The command-line session did not render that interface. No screenshot was taken, so this article does not claim that the red marks or warning dialog were personally observed. The repeatable evidence is the strict three-error preflight, while the visual behavior remains a documented product boundary.
Refuse the tempting lossy shortcut
A permissive converter could replace all three characters with question marks and still produce a file named as Shift_JIS. That file would satisfy a superficial format check while corrupting a surname, an emoji, and a symbol. The measured recovery deliberately performed no lossy Shift_JIS save. It kept the source untouched and selected a separate UTF-8 delivery, because UTF-8 can represent the intended text without editorial substitutions.
Save to a separate path, then reopen it
The recovery copy was written with strict UTF-8 handling rather than by changing the only source in place. Rune then reported UTF-8 when the saved file was inspected. An independent strict encoding pass found zero errors, and decoding the copy produced text exactly equal to the input. Its SHA-256 digest is 1f5ee3a48eda919483f04c5f659916f5a249c5a52a7d0c10007447433e2d49af, which identifies the artifact used for the acceptance statement.
Decide what to tell the submission desk
The handoff note should be short and factual: Shift_JIS was tested, three characters were unrepresentable, no lossy file was produced, UTF-8 was chosen, and the reopened copy had zero UTF-8 errors with exact text equality. If the recipient truly requires Shift_JIS, the next action is an editorial decision about those three characters, not a silent technical replacement. If UTF-8 is accepted, retain both source and delivery copy until ingestion is complete.
Safe encoding changes end with a reversible choice and a reread result. They do not end at the menu selection, the color of a warning, or an exit code. The accepted copy must identify its encoding, survive decoding without error, and reproduce the source text exactly.
The evidence also keeps the code point and location for each rejected character. That detail matters during negotiation: the recipient can decide whether UTF-8 is acceptable, whether a sanctioned textual alternative exists, or whether the destination specification must change. A technician should not choose a look-alike character merely to make an encoder quiet. Any approved substitution creates a new editorial revision and needs a fresh equality baseline.
For a longer manuscript, apply this preflight to the exact submission revision, not to a short excerpt that happens to contain ordinary Japanese. Store the source digest before scanning, report the total and the distinct characters, and refuse an in-place write when the count is nonzero. After selecting UTF-8, close and reopen the actual delivery path rather than inspecting an in-memory buffer. This sequence provides evidence for the file the desk will receive.
The user-interface warning remains useful as immediate feedback, but it is not the acceptance record. A red mark might disappear because the destination changed, the character changed, or the view changed. The reopened file, strict zero-error result, equality comparison, and digest state which explanation is true. That is why the recovery remains verifiable even in an automated or headless workflow.
For recurring submissions, keep an allowlist of destination formats but run the character scan anew on every revision. Yesterday's zero count cannot cover a new proper name added today. The source digest makes that limitation visible. A changed digest triggers another strict preflight, while an unchanged digest permits reuse of the recorded decision without pretending that all future prose is safe.
Keep the original file timestamp and digest in the submission note as well. If a recipient later reports replacement characters, compare the returned artifact with the accepted UTF-8 digest before repeating conversion. That check distinguishes transit or ingestion damage from a source-side mistake and keeps the three known characters from becoming a vague encoding complaint.
The phrase safe text encoding changes means refusing the three-error lossy route and accepting only the exact UTF-8 reread.