[Bug] Saving a Windows-1252 / Latin-1 or Shift JIS file replaces its non-ASCII text with U+FFFD
Description
With Auto guess encoding on (the default), opening and saving a BOM-less Windows-1252 / Latin-1 or Shift JIS file replaces every non-ASCII character with U+FFFD, and the save writes those replacement characters to disk. The original text is lost.
Since #4739, guessEncoding (packages/desktop/src/main/filesystem/encoding.ts) only consults ced after the buffer has failed UTF-8 validation. But the ced → iconv table still maps ASCII, SJS, shiftjis and MACINTOSH to utf8. ced reports Latin-1 / Windows-1252 text as ASCII and Shift JIS as SJS, so a buffer already known not to be UTF-8 is decoded as UTF-8 anyway.
The SJS/JIS → utf8 mapping was added for #3857 (a valid UTF-8 file misdetected as Shift JIS). The isLikelyUtf8 check from #4739 now covers that case before ced runs, so the mapping only affects files that really are not UTF-8.
A second, smaller problem in the same function: the fallback normalisation encoding.toLowerCase().replace(/-_/g, '') matches the literal two-character string -_, so names such as ISO-8859-15 are never normalised to iso885915.
Steps to Reproduce
- Create a Windows-1252 file without a BOM, e.g.
printf 'Gr\xfc\xdfe aus M\xfcnchen\n' > de.md, or save Japanese text as Shift JIS from another editor. - Open it in MarkText with Auto guess encoding enabled.
- Save it (make any edit, or just Ctrl+S).
- Inspect the file bytes (
xxd de.md).
Expected Behavior
The file opens as Grüße aus München, and saving keeps it byte-identical in its original encoding.
Actual Behavior
The umlauts / Japanese characters show as �, the encoding is reported as UTF-8, and after saving the file contains EF BF BD sequences in place of the original bytes.
Screenshots / Logs
Checked with guessEncoding → iconv.decode → iconv.encode on develop (b0079e1f) for German Windows-1252, sparse Latin-1 and Shift JIS samples: all three come back as utf8 with U+FFFD in the text. Not yet reproduced in a packaged build.
Operating System
Linux (Other)
MarkText Version
develop @ b0079e1f (0.20.0-dev)
OS Version
Arch Linux, kernel 7.2.7
Reproducibility
- I can reliably reproduce this issue
Source: marktext/marktext