[BUG] Edit/Write tool corrupts accented characters in Windows-1252 (cp1252)

I have this issue too. As a workaround I ask claude in my CLAUDE.md to use iconv to convert my file to utf-8 to work on it and then to convert it back to cp1252.

Same root cause hits CP852 (DOS Latin-2, code page 852) as well — adding it as another data point, since this is codepage-agnostic (any non-UTF-8, non-ASCII file), not specific to cp1252.

Context: legacy Harbour / Clipper business software, very common in Poland / Central & Eastern Europe. Source files (.prg / .ch) are stored in CP852; DBF data uses codepage PL852. These are large (100k+ LOC), actively maintained codebases.

Behavior (identical to the cp1252 report): Edit/Write read/write as UTF-8 with no way to specify the file's encoding. Every non-ASCII byte (≥ 0x80) fails to decode as UTF-8, is replaced with U+FFFD (EF BF BD), and the whole file is rewritten as UTF-8 — corrupting every accented character in the file, not just the edited lines. VS Code files.encoding doesn't help because Edit/Write bypass the editor's encoding engine.

Example: editing one ASCII-only line in a file containing Błąd zapisu turns it into B<U+FFFD><U+FFFD>d zapisu. A single corrupted byte can break compilation (Harbour) or silently change displayed text.

Workaround we use (in addition to the iconv round-trip mentioned above):

• a PreToolUse hook that blocks Edit on .prg / .ch;
• a small Perl helper that edits by line number in binary (:raw) mode, preserving CP852 bytes and CRLF line endings.

It works, but it's a lot of scaffolding to avoid a single bad assumption. A real fix — preserve the file's original byte encoding (round-trip unedited bytes verbatim), or at minimum refuse/warn instead of silently transcoding, and/or add an encoding parameter on Read/Edit/Write — would help a whole class of legacy non-UTF-8 codebases (cp1252, CP852, windows-1250, ISO-8859-x, …). This has been open a while (#7134 since Sep 2025); would be great to see it prioritized.

Adding another data point from a VB6 codebase. Same root cause, slightly different manifestation.

VB6 .frm files are Windows-1252 by spec. The form designer header contains raw high bytes for symbol font characters. In my case, a CommandButton using Wingdings has a caption of 0xEC (a pop-out window icon):

Begin VB.CommandButton cmdPop
Caption = "<0xEC>"
BeginProperty Font
Name = "Wingdings"
Every time the Edit tool touches any line in the file, that single 0xEC byte gets replaced with EF BF BD (3 bytes). The form then fails to display the correct symbol at runtime. The only way to recover is a post-edit Python script that knows the original byte value and patches it back.

What makes this case particularly nasty is that the corrupted byte is in the form designer header, not in code. You can't just avoid editing near it -- any edit anywhere in the file triggers the corruption. And unlike accented text where you might visually spot garbled characters, a wrong Wingdings glyph is easy to miss.

I've confirmed the original byte via SVN history (svn cat -r <old_revision> shows 0xEC). This has been silently corrupted and re-fixed multiple times across editing sessions.

Currently working around it the same way -- detecting and replacing EF BF BD after every edit -- but it's fragile and requires knowing what the original bytes were.