"Windows/PowerShell traps that corrupt s&box source"

• Emoji / em-dashes in .razor or comments become —, 🥚, etc.
• Multi-line search-replace reports "string not found" on a block you can clearly see.
• Bulk "fix all the files" scripts quietly destroy UI source.

PowerShell 5.1 Get-Content / Set-Content reads BOM-less UTF-8 as ANSI and re-encodes → mojibake on every non-ASCII character.

Separately: some C# files are CRLF. A \n-only old_string never matches \r\n content even when lines look identical. Mixed LF/CRLF in one repo is common: check per file.

Never bulk-edit with Get-Content/Set-Content

Use Python, or byte-safe .NET:

$c = [System.Text.Encoding]::UTF8.GetString([System.IO.File]::ReadAllBytes($f))
# … edit $c …
[System.IO.File]::WriteAllBytes($f, [System.Text.Encoding]::UTF8.GetBytes($c))

If mojibake already happened

Decode file as UTF-8, re-encode chars via cp1252 (map U+0080–U+009F straight to their byte values), decode result as UTF-8. Test on a copy first: a different corruption path needs a different inverse.

CRLF-aware edits

p = "Code/Foo.cs"
data = open(p, "rb").read()
print(b"\r\n" in data)  # True → use \r\n in literals

old = b"line1\r\nline2\r\n"
new = b"line1\r\nline2_fixed\r\n"
assert data.count(old) == 1
open(p, "wb").write(data.replace(old, new, 1))

Razor / emoji HUD

Same rule: editing-razor-byte-safe. Prefer an editor or Python over shell redirection for any file with non-ASCII.

BOM-less UTF-8 has no encoding marker; PS 5.1 guesses wrong and round-trips through the system ANSI code page. CRLF mismatch is a literal byte mismatch: visual sameness in a text view hides \r. Byte-level APIs preserve what you meant.