Assumes Windows PowerShell 5.1. Most of these raise no error at all; the output just comes out quietly broken.
Why this chapter bites non-ASCII users
Nearly every entry here is about text crossing an encoding boundary. If your data, paths, and string literals are pure ASCII, PowerShell 5.1's legacy defaults mostly pass through unnoticed. If they contain Korean, Japanese, Chinese, accented Latin, or emoji, the same defaults silently corrupt them. Every trap below was hit on a Korean-locale Windows box (code page 949), but the mechanism applies to any locale whose ANSI code page is not UTF-8.
Every time text crosses a tool boundary, the encoding rules change. Neither side raises an error. Only the output comes out quietly broken.