Rule request: AvoidDefaultEncoding

Apparently the default encoding -Encoding Default is removed from the cmdlet documentation that supports the -Encoding parameter. See e.g.:

• https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-content?view=powershell-5.1
• https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-content?view=powershell-7.5

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:
  • Character encoding in Windows PowerShell: UTF8 Uses UTF-8 (with BOM).
  • Character encoding in PowerShell: utf8: Encodes in UTF-8 format (no BOM).

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.

Commencez par examiner la règle PSUseCompatibleCommands et ses profils de compatibilité, puis comparez la documentation liée sur l’encodage de Windows PowerShell et de PowerShell. Définissez les diagnostics attendus pour -Encoding Default et -Encoding utf8 lorsque l’analyse de compatibilité est activée, notamment la manière dont les nouvelles valeurs Ansi et utf8NoBom doivent être traitées ; l’issue est terminée lorsque le comportement de la règle et la couverture correspondante reflètent cette décision.