Korean literals in a BOM-less `.ps1` come out garbled

Symptom

Script saved as UTF-8 without BOM. Run under powershell.exe, the Korean strings embedded in the source print as garbage. Korean inside comments is harmless; what dies is output strings and paths containing Korean.

Cause

With no BOM, the PS 5.1 parser reads the *script source itself* as system ANSI (949). The previous entry is about *data file I/O*; this one is about the *source file being parsed*. Different layer, same root.

Why this bites non-ASCII users

"Save as UTF-8 without BOM" is standard hygiene in most editors and linters, and the correct default for practically every other toolchain. PowerShell 5.1 is the one that punishes it, and only when the source has non-ASCII in it. An ASCII-only script never notices.

Fix

Adding a BOM fixes it but collides with a "no BOM" rule. If you must keep the rule:

• Keep the source pure ASCII and decode the non-ASCII strings at runtime.

```powershell

function U($b64) { [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($b64)) }

```

• Never write a path containing non-ASCII as a literal. Assemble it from $env:USERPROFILE and friends.

Verification

LC_ALL=C grep -n '[^ -~]' script.ps1 — no output means pure ASCII.

---

---