Find Characters Shift_JIS Cannot Represent Before Saving

To find characters that Shift_JIS cannot represent, test actual characters and positions instead of treating every “legacy” or unusual character as one category. In the 1,000-character specimen, two failures were recorded: 😀 at index 23 and 🚀 at index 24. Approved substitutions reduced the count to zero, and separately named UTF-8 and Shift_JIS copies reopened with matching repaired text. If the process fails, return to the untouched 1,000-character working copy and the substitution-approval record, not to a partially saved output.

The article-specific status is partial. The numerical run verified two findings, zero after repair, and matching reopened copies. It did not identify or classify the three legacy-character candidates anticipated in the test material. Rune Studio’s red highlighting, pre-save warning, and autosave stop/resume behavior were not verified through the CLI.

Decide representability character by character

Shift_JIS representability is a property of a specific character in the target encoding. A character should not be declared unsafe merely because it is described as machine-dependent or visually unusual.

For each candidate, record the character, code point, source index, Shift_JIS result, and approved substitute. The evidence available here identifies 😀 and 🚀. It does not establish why the three anticipated legacy candidates were absent from the result, so their status remains unresolved.

Starting values and measured result

The requested and observed source lengths were both 1,000 characters. Shift_JIS was the target for the representability check.

These values support the two recorded characters. They do not prove that five candidates were all tested or that the three legacy candidates were safe. Missing evidence stays missing.

A product-independent pre-save workflow

1. Duplicate the source and freeze its character count, encoding, and line ending.
2. List every character that cannot be represented in Shift_JIS, including its position.
3. Compare each location with the source and approve only substitutions that preserve meaning.
4. Apply substitutions to the copy and rerun the same check until the recorded count is zero.
5. Save separate UTF-8 and Shift_JIS copies, close them, reopen them, and compare the complete repaired text.

A disappearing warning is not a sufficient exit condition. The evidence chain is position, approved decision, zero remaining findings, and matching reopened text.

The article’s endpoint is the Shift_JIS save decision

This guide asks whether the manuscript can be saved as Shift_JIS after resolving the recorded characters. A missing-character article for EPUB conversion has a different delivery point: it closes a conversion gate around the generated artifact. Here, the decision is whether to accept Shift_JIS as the target or choose another encoding.

Do not force the count to zero if the substitute damages the sentence. Switching the target to UTF-8 is a valid result when no acceptable Shift_JIS replacement exists.

Rune Studio’s documented Stage 3 scope

Current Rune Studio documentation states that the Mac app handles major Japanese encodings, marks Unicode characters that the selected encoding cannot represent with a red background, pauses autosave while such characters remain, and warns on manual save. Those are Stage 3 product capabilities.

The title-specific Stage 4 run verified two positions in the 1,000-character specimen, zero findings after approved substitutions, the detected encodings of two separately named copies, LF, and matching repaired text. It did not verify the visual warning, its wording, a deliberately mis-decoded display, or the autosave pause and resume sequence.

A separate common Stage 4 run inspected a short text as UTF-8, Shift_JIS, and EUC-JP with 39 characters and as UTF-16LE and UTF-16BE with 40, all using LF. The working tab read back UTF-8. That run supports encoding inspection but is not evidence for the two findings in this specimen.

Keep the partial boundary visible

The following remain unverified:

• the identities, code points, and Shift_JIS behavior of the three anticipated legacy candidates;
• Rune Studio’s visual pre-save warning and red highlight;
• the full UI sequence in which autosave pauses and resumes;
• the appearance of a deliberately mis-decoded file and overwrite behavior;
• acceptance by another application or submission service.

Complete recovery of damaged data, OCR, and binary repair are also outside scope. None of these open items is converted into a success claim.

Rollback points

• If a reported index does not match the source, keep the encoding fixed and return to detection.
• If a substitution is not approved, return to the untouched working copy and approval record.
• If one or more findings remain, return to the remaining-position list and stop the save.
• If the reopened copies differ, discard both outputs and return to the zero-finding repaired copy.
• If no meaning-preserving substitute exists, abandon Shift_JIS for this delivery and evaluate a different encoding such as UTF-8.

Conclusion: report the two findings and the unresolved candidates separately

In this 1,000-character specimen, 😀 at index 23 and 🚀 at index 24 were recorded as unrepresentable in Shift_JIS. Approved substitutions reduced the count to zero, and the UTF-8 and Shift_JIS copies reopened with matching repaired text. The three anticipated legacy candidates are absent from the evidence, so the correct overall status remains partial.

This article covers Shift_JIS representability and the save decision. CR/LF comparison, UTF-8 conversion reconciliation, and selecting BOM plus line-ending settings have different operations and different conclusions. The current Mac feature scope is available on the Rune Studio product page.