The safest UTF-16 conversion begins by refusing to overwrite the source. Identify a readable UTF-16 file, approve the Unicode text that should survive the conversion, write that text to a new UTF-8 filename, and reopen the result. The conversion passes only when the original remains available and the reopened copy matches the approved text.
This UTF-16 text editor convert to UTF-8 workflow uses a measured UTF-16LE source of 45 characters and a separately named UTF-8 copy of 44 characters. The different counts are recorded rather than concealed. Exact commands, input roles, failure states, and return points make the result auditable.
Establish the UTF-16 authority
Record the original path, creating application, expected encoding, and a readable reference before changing anything. Do not guess little-endian or big-endian from a corrupted screen. A wrong decoder can produce editable-looking garbage, and saving that display may destroy the byte sequence needed for recovery.
The controlled authority was source-UTF-16LE.txt, with SHA-256 f37fc7485e4b8679e16aa0211fc7146a9e145f31d5134bbf0a4a357906eb1f09. It was a synthetic file, not a production manuscript. All later changes target new files.
The intended Unicode string was also frozen separately as approved-utf8-content.txt. That file represents an editorial decision. Encoding conversion changes the representation of approved text; it should not silently decide which characters the manuscript ought to contain.
If the authority cannot be identified, stop. Creating multiple guesses and overwriting the same source makes a later comparison impossible. Preserve each attempt under a new name until one can be tied to reliable text.
Inspect three formats before selecting the input
The sample set included UTF-8, Shift_JIS, and UTF-16LE. The exact UTF-16 command was rune inspect text --file /private/tmp/rune-g2c3-studio-303-i_ds9byi/source-UTF-16LE.txt --json. The two other inspections used the same command shape with their own paths.
The results were UTF-8/LF/44 characters, Shift_JIS/LF/44 characters, and UTF-16LE/LF/45 characters. All commands exited with code 0. The 45-character UTF-16LE result is not rewritten to match the two 44-character observations. It is the actual readback of that synthetic source and must be explained by the approval comparison.
Three conditions stop the workflow at this stage: detected encoding differs from the source record, line endings change unexpectedly, or the decoded string does not match a trustworthy reference. In each case, return to source selection rather than writing an output.
An encoding label alone cannot establish semantic correctness. A correctly detected UTF-16LE file can still be the wrong revision of the manuscript. Source identity and encoding are separate checks.
Approve the text independently of the output format
Before conversion, resolve any character decision in context. A personal name, historic character, or punctuation mark should not be deleted merely because a target encoding cannot represent it. The editor must decide whether to retain it, replace it with an approved form, or select a different output encoding.
For the controlled run, the approved UTF-8 input was 64 bytes with SHA-256 354980a66eef4fc53e93f1a7527407bcc6f898fc7599e0e2679d552f48413a2c. Fixing that expected value before the write gives the later readback a meaningful comparator.
When approval is incomplete, pause with the original readable. A delayed conversion is safer than a fast save that replaces an unresolved character with ? and removes the context required for restoration.
This editorial checkpoint also prevents a tool from appearing to make a literary decision. The application can report encodings and store bytes. The author or editor owns the intended wording.
Verify the destination with a dry run
The recorded preflight was rune file write --path /private/tmp/rune-g2c3-studio-303-i_ds9byi/STUDIO-303-converted-copy.txt --content-file /private/tmp/rune-g2c3-studio-303-i_ds9byi/approved-utf8-content.txt --dry-run --json.
Read the command as a two-file contract. The content source is the approved Unicode text. The target is a new converted-copy path. source-UTF-16LE.txt is not the destination. If it appears after --path, the preflight fails even if the command itself would exit successfully.
The dry-run response is not a saved file. It confirms scope and path before mutation. A useful production filename includes a revision or timestamp so reviewers do not confuse it with the authority.
Write to the new filename and preserve failures
After the target was confirmed, the run repeated the same write without --dry-run. It created STUDIO-303-converted-copy.txt and left the UTF-16LE authority untouched. The command exited with code 0.
If the write is interrupted or produces a bad result, keep that output as a failed artifact and start another named attempt. Do not overwrite the source while “trying again.” The failed copy shows whether the problem came from the approved content, the command input, or the storage step.
This separation also supports rollback. Removing an unsuccessful output is optional; recovering the source is unnecessary because it was never changed.
Reopen and compare decoded text
The closing command was rune inspect text --file /private/tmp/rune-g2c3-studio-303-i_ds9byi/STUDIO-303-converted-copy.txt --json. The result reported UTF-8, LF, and 44 characters.
The copy's SHA-256 was 354980a66eef4fc53e93f1a7527407bcc6f898fc7599e0e2679d552f48413a2c, identical to the approved content. The evidence record also reports decoded_text_equal=true. Those comparisons make the output acceptable; the write response by itself would not.
Character count alone is insufficient. A substitution can preserve length while changing a name or symbol. Require the expected encoding, expected line ending, and decoded-text equality. If any fails, return to the preflight and identify which input changed.
Finish with two independent acceptance conditions
Public Rune Studio documentation describes detection of major Japanese encodings, graphical marking of unrepresentable characters, and preventing automatic save while unresolved characters remain. This CLI run did not inspect warning pixels, IME behavior, selection state, autosave timing, or unsaved memory. Documentation and measured file operations remain separate evidence classes.
The workflow also does not recover already corrupted binary data, perform OCR, or guarantee an external publishing service's behavior. Its bounded claim is that a UTF-16LE authority was preserved while approved text was written to and reopened from a separate UTF-8 file.
Review the current Rune Studio feature scope. Before continuing to editing or EPUB production, record two facts: the source checksum did not change, and the UTF-8 copy decodes exactly to the approved text. Those conditions, not a convenient Save response, complete the conversion.