When you find a garbled manuscript, the first thing to do is not save it. If it is only garbled, the file is intact and reopening with the correct encoding restores it. Saving in the garbled state is the moment it actually breaks.
This article covers the reopening procedure and what it means when reopening does not help. Detection internals, and finding unrepresentable characters, are covered separately.
Garbled files are not damaged files
An encoding maps characters to numbers. Saving converts characters to numbers; opening converts them back.
Open with the wrong table and different characters appear. That is garbling.
The key point is that the sequence of numbers has not changed. The file is intact, and the correct table restores the original characters.
What saving does
A garbled state means wrong characters are on screen. Save, and those wrong characters are converted to numbers and written out.
The original numbers are overwritten. After that, no encoding will bring them back.
So when you find garbling, stop. Do not touch it, do not edit, do not save.
Why “just reopen it” often fails
The procedure is simple; guessing the right encoding is not.
For Japanese, the candidates are Shift_JIS, UTF-8, EUC-JP, and ISO-2022-JP. Try each and keep whichever reads correctly.
Two things go wrong.
One: none of them read correctly. The file may be in another language, or not be a text file at all.
Two: more than one reads correctly. The Japanese encodings share structural similarities, so a wrong guess can render most characters correctly. You adopt it without noticing that only the symbols are wrong.
rune Studio reports what it detected, and halts risky saves
rune Studio detects the encoding on read: byte-order mark first, then system detection, then the major Japanese encodings in turn.
I verified this by driving the development build from the command line. A file saved as Shift_JIS reported Shift_JIS, along with the line-ending style, character count, and line count. A UTF-8 file reported UTF-8.
Look at the detection result first, then judge whether it is plausible. That is where reopening starts.
Which encodings are tried
UTF-8, UTF-8 with a byte-order mark, Shift_JIS, EUC-JP, ISO-2022-JP, both byte orders of UTF-16, and a final fallback. The encodings Japanese manuscripts actually use are all present.
The encoding and line-ending style can be switched at the bottom of the window, which is where you choose differently when the detection looks wrong.
Spotting the case where only symbols are wrong
One practical finding. I wrote a wave dash into a Shift_JIS file, saved it, and read it back — it returned as a full-width tilde, a visually similar but different character.
That is a long-known mapping issue rather than a detection failure. The lesson is that prose reading correctly does not mean the symbols survived. After reopening, compare the symbols.
Some saves are halted
When a character cannot be represented in the chosen encoding, saving halts. I confirmed this: no file was written, and the result reported one unrepresentable character.
To be precise about scope: this refusal to write is what I confirmed when saving from the command line. For saving from the application window, the documentation describes a warning at save time, automatic saving being paused, and an on-screen notice. What actually happens when saving from the window was not verified in this pass. What was verified is the command-line path only.
One route to a permanently damaged file is closed. Note the limit: that applies to unrepresentable characters. A merely garbled file will still save, so that part is on you.
Who this suits, and who is fine without it
It suits people opening old or received files on a Mac. If you regularly open files of unknown encoding, having the detection reported matters.
If you only ever open your own UTF-8 files, this situation barely arises.
Scope note: what was verified is that detection is reported and that some saves halt. Not every garbled file is recoverable by reopening — one already saved in a broken state is not.
Summary
- Garbling is a misread; the file is intact and reopening correctly restores it
- Saving in the garbled state is when the damage becomes permanent, so do not touch it
- rune Studio reports the detected encoding and lets you choose differently at the bottom of the window
- Prose can read correctly while symbols do not, so compare symbols after reopening
For a first step, when you find a garbled file, check the detected encoding before saving anything. Every later decision follows from that result.
See the current product scope on the Rune Studio product page.