Apparently the default encoding -Encoding Default is removed from the cmdlet documentation that supports the -Encoding parameter. See e.g.:
Which makes sense in a way that this might cause compatibility issues when something is e.g. written (using -Encoding Default in Windows PowerShell 5.1 and read back in PowerShell 7 (e.g. after a PowerShell update migration). Yet, afaik, this isn't captured by any of the UseCompatibleCommands profiles either (probably because the default value is still accepted.
Also note:
- that using any of the newer encoding values as
Ansi and utf8NoBom in PowerShell 7 might cause an incompatibility issue with older versions of PowerShell.
- the implementation of the
-Encoding utf8 value also differs between Windows PowerShell and newer versions of PowerShell:
Therefore I think that it is wise to avoid the default and utf8 encoding (-Encoding Default and -Encoding utf8) when PSUseCompatibleCommands is enabled in the PSScriptAnalyzer settings.
Apparently the default encoding
-Encoding Defaultis removed from the cmdlet documentation that supports the-Encodingparameter. See e.g.:Which makes sense in a way that this might cause compatibility issues when something is e.g. written (using
-Encoding Defaultin Windows PowerShell 5.1 and read back in PowerShell 7 (e.g. after a PowerShell update migration). Yet, afaik, this isn't captured by any of the UseCompatibleCommands profiles either (probably because thedefaultvalue is still accepted.Also note:
Ansiandutf8NoBomin PowerShell 7 might cause an incompatibility issue with older versions of PowerShell.-Encoding utf8value also differs between Windows PowerShell and newer versions of PowerShell:UTF8Uses UTF-8 (with BOM).utf8: Encodes in UTF-8 format (no BOM).Therefore I think that it is wise to avoid the
defaultandutf8encoding (-Encoding Defaultand-Encoding utf8) whenPSUseCompatibleCommandsisenabledin the PSScriptAnalyzer settings.