ayi <t>Note:<br/> <br/> <br/> The next section applies primarily to Windows PowerShell.<br/> <br/> See the section after it for the cross-platform PowerShell (Core) 7 edition.<br/> <br/> <br/> In both cases, the information applies to making PowerShell use UTF-8 for reading and writing files.<br/> <br/> By contrast, for information on how to send and receive UTF-8-encoded strings to and from external programs, see this answer.<br/> <br/> <br/> A system-wide switch to BOM-less UTF-8 is possible nowadays (since recent versions of Windows 10): see this answer, but note the following caveats:<br/> <br/> <br/> The feature has far-reaching consequences, because both the OEM and the ANSI code page are then set to 65001, i.e. UTF-8; also, the feature is still considered a beta feature as of this writing (Windows 11 / Windows Server 2025 24H2).<br/> <br/> Notably, it can change the interpretation of preexisting BOM-less files, including source code, if they contain non-ASCII characters, by any application (not just PowerShell), because they are then (potentially mis-)decoded as UTF-8.<br/> <br/> <br/> Additionally, in Windows PowerShell, it takes effect only for those file-writing cmdlets that default to the ANSI code page, notably Set-Content, and therefore notably not for Out-File / >; the bottom section lists the default encoding of all cmdlets.<br/> <br/> While you can use $PSDefaultParameterValues['*:Encoding'] = 'utf8', as explained below, so as to make all cmdlets default to UTF8, file-writing cmdlets will then invariably create UTF-8 files with BOM in Windows PowerShell; this is not a concern in PowerShell 7, which consistently defaults to BOM-less UTF-8 to begin with.<br/> <br/> The Windows PowerShell perspective:<br/> <br/> <br/> In v5.1 (and also in PowerShell 7), where > and >> are effectively aliases of Out-File, you can **set<br/> <br/> (Réponse tronquée)</t>