Garbled text is a symptom, not a diagnosis. Converting the file immediately can destroy evidence and preserve the wrong characters. First determine when the problem appeared: at opening, after saving and reopening, or only in one display environment. Each timing points to a different return path.
Freeze the evidence before testing
Duplicate the problem file and keep the original untouched. Record its source, modification time, size, expected encoding, and the first known environment in which it looked correct. Capture the problem line and several surrounding lines without saving the opened document.
If automatic save may be active, work from an expendable copy and confirm where it writes. A bad decoding shown on screen can become newly saved corruption if the application updates the file before the cause is known.
If the problem appears at open, test decoding
Suppose a known Shift_JIS document is opened as UTF-8 and immediately shows implausible characters. Reopen a fresh duplicate using the known source encoding and compare passages at the beginning, middle, and end. If the trusted text returns, decoding is the leading cause.
Do not convert the garbled display. Record the successful opening choice and verify the source information. If several encodings produce plausible but different characters, stop and ask for the creation environment or an older rendering rather than choosing the most attractive result.
If the problem appears after save, test writing
A file may open correctly and lose only an emoji, circled number, or uncommon name character after save and reopen. That pattern points toward the selected output encoding or unrepresentable-character handling. Return to the last known-good duplicate and recreate the save with a tiny sample containing the affected line.
Record the manual or automatic save path, selected encoding, warning behavior, and reopened result. Do not repair the damaged copy one visible question mark at a time until the writing condition is understood.
If only one machine differs, test display
Empty boxes or different glyph shapes on one computer can result from font coverage or rendering. Copy the text and compare its Unicode code points or search behavior across environments. If the underlying characters match, changing encoding is the wrong repair.
Try an appropriate font or a second reader while preserving the data. Record the environment that differs. A display-only problem should return to font and rendering choices, not to global character replacement.
Use a timing-based decision table
For an opening-time failure, the first return point is the decoding choice and source information. For a post-save failure, return to the known-good copy, output encoding, and representability warning. For a one-environment failure with matching code points, return to fonts or rendering. For damage that appears in every backup, return to older history and the original creator.
Mark uncertainty explicitly. Not tested is not equivalent to healthy. If the source encoding and last correct version are unknown, preserve the evidence and stop before a destructive batch conversion.
Test one hypothesis on a minimal sample
Copy the problem line with three lines before and after it. Change only one condition per attempt: decoding choice, output encoding, or font. Close and reopen saved test files. Compare characters, code points, line breaks, and file behavior rather than writing only “looks better.”
When one hypothesis explains the symptom and reproduces it, plan the full repair from the known-good source. Keep the test artifacts and notes so another reviewer can understand why the repair was chosen.
Use history to narrow an unknown transition
If multiple backups exist, inspect them read-only from newest to oldest. Find the last version with correct text and the first version with corruption. List the save, transfer, conversion, or application change between those points. If file hashes remain identical across a transfer, that evidence reduces the likelihood that the transfer changed the bytes.
This diagnostic workflow stops before full conversion. A safe Shift_JIS-to-UTF-8 conversion has its own duplicate, decoding, save-as, and reopen process. Software selection by warning behavior is also a separate decision.
Map Rune Studio documentation to the diagnosis
Current Rune Studio materials describe reading multiple Japanese encodings, changing encoding and line endings, highlighting characters that cannot be represented in the selected encoding, and pausing automatic save while unresolved characters remain. Those capabilities can support decoding and save-path tests.
They do not identify the cause of a particular damaged file without evidence. Do not report a diagnosis or successful recovery unless the minimal sample and reopened result demonstrate it on the current version.
End with a cause, a return point, or a safe stop
A useful diagnostic result states the observed timing, tested hypothesis, evidence, and next return point. If the evidence is insufficient, the result should state what is missing and preserve the original rather than guess.
Begin by duplicating the file and writing three labels: before open, immediately after open, and after save and reopen. That timeline often reveals which branch to test first. Review current encoding-related features on the Rune Studio product page.