#5577·marktext

[Bug] Saving a Windows-1252 / Latin-1 or Shift JIS file replaces its non-ASCII text with U+FFFD

Author: ycyc0421Created Sep 28, 2026Updated Sep 28, 2026

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

  1. 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.
  2. Open it in MarkText with Auto guess encoding enabled.
  3. Save it (make any edit, or just Ctrl+S).
  4. 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