One em-dash in a no-BOM ps1 breaks quote parsing far below it

Repro: create a .ps1 file with no BOM, save it as UTF-8 (no signature) from an editor that defaults that way. Put a Write-Host line containing an em-dash, e.g. Write-Host "build finished — ok". Save, run it in Windows PowerShell 5.1 (powershell.exe, not pwsh 7). Now add a normal double-quoted string on a later line, say 15-30 lines down, with nothing unusual in it. Run the script.

Result: a parser error pointing at that later line, something like "The string is missing the terminator" or "Unexpected token" on a line that has correctly matched quotes. The actual defect is the em-dash line above it.

Cause: PowerShell 5.1 has no reliable UTF-8 auto-detection for script files. Without a BOM, the file is read through the process's ANSI codepage (on a US/EU Windows box that's usually Windows-1252 or the OEM codepage, not UTF-8). An em-dash (U+2014) encoded as UTF-8 is the three bytes 0xE2 0x80 0x94. Read back one byte at a time under a single-byte codepage, at least one of those bytes maps to a double-quote-like or otherwise special character in that codepage's glyph table. The tokenizer sees what looks like an unbalanced quote starting at the em-dash and keeps consuming text until it finds the next quote character that closes it — which can be many lines away. Everything between the em-dash and that accidental closing quote gets treated as one string literal, so the parser only reports a problem once it runs out of matching quotes, at whatever line that happens to be. This is why the error location is misleading: it's a symptom line, not the cause line.

Same failure mode applies to any non-ASCII punctuation typed by an editor's autocorrect — smart quotes ('' ""), en-dashes, ellipsis character (…) — not just em-dash specifically, since the root cause is byte-level codepage misreading, not anything special about U+2014.

pwsh (PowerShell 7+) defaults to UTF-8 without BOM and doesn't have this problem; this is specific to Windows PowerShell 5.1 (powershell.exe), which is still the default engine invoked by Start-Process, scheduled tasks, and a lot of CI runners on Windows images.

Two fixes, pick one:

- Keep script content ASCII-only. Replace em-dash with --, smart quotes with straight quotes, ellipsis with three periods. - Force a UTF-8 BOM when saving the .ps1. In VS Code: Command Palette > "Change File Encoding" > "UTF-8 with BOM", then save. With a BOM present, PowerShell 5.1 correctly detects UTF-8 and reads the em-dash as one character, not three misinterpreted bytes.

I check for this now with a one-line grep for non-ASCII bytes in .ps1 files before running anything unattended: findstr /r "[^ -~]" file.ps1 flags any line with a byte outside the printable ASCII range.