Modification de L'encodage par défaut de la sortie de PowerShell en UTF-8

• PSv5.1 ou plus, où > et >> effectivement alias Out-File vous pouvez définir le codage par défaut pour >/>>/Out-File via le $PSDefaultParameterValues variable de préférence:

  • $PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'

• PSv5.0 ou moins ne peut pas changer l'encodage pour >/>>, mais PSv3 ou supérieur, la technique ci-dessus fonctionne pour appels à Out-File.
  
  (Le $PSDefaultParameterValues la variable de préférence a été introduite dans PSv3.0).

• PSv3.0 ou plus, si vous voulez définir le codage par défaut pour applets de commande de support
  
  -Encoding paramètre (qui dans PSv5.1 + includes > et >>), utilisation:

  • $PSDefaultParameterValues['*:Encoding'] = 'utf8'

Si vous placez cette commande dans votre $PROFILE, des applets de commande exemple Out-File et Set-Content utilisera L'encodage UTF-8 par défaut, mais notez que cela en fait un session-paramètre global qui affectera toutes les commandes / scripts qui ne spécifient pas explicitement un encodage.

de Même, assurez-vous d'inclure de telles commandes dans vos scripts ou modules que vous voulez à se comporter de la même manière, de sorte qu'ils se comportent effectivement de la même façon même lorsqu'ils sont exécutés par un autre utilisateur ou une autre machine.

Avertissement: PowerShell, à partir de v5.1,invariablement crée des fichiers UTF-8 avec un (pseudo) de la NOMENCLATURE, qui est d'usage que dans le Windows - Unix - les utilitaires basés ne reconnaissent pas ce BOM (voir bas.)

automatique $OutputEncoding variable sans rapport avec, et ne s'applique qu'à la façon dont PowerShell communique avec programmes externes (ce qu'encoding PowerShell utilise lorsqu'il leur envoie des chaînes) - cela n'a rien à voir avec l'encodage que les opérateurs de redirection de sortie et les cmdlets PowerShell utilisent pour sauvegarder dans les fichiers.

lecture optionnelle: la plateforme transversale perspective:

PowerShell est maintenant de la croix-plate-forme, par l'intermédiaire de son PowerShell Core édition, dont l'encodage - raisonnablement - par défaut à BOM-less UTF-8, en ligne avec les plates-formes de type Unix.

• cela signifie que les fichiers de code source sans BOM sont supposés être UTF-8, et en utilisant >/Out-File / Set-Content par défaut à BOM-less UTF-8; Utilisation explicite de utf8-Encoding argument crée BOM-less UTF-8, mais vous pouvez choisir de créer des fichiers le pseudo-BOM avec le utf8bom valeur.

• si vous créez des scripts PowerShell avec un éditeur sur une plateforme de type Unix et même de nos jours sur Windows avec des éditeurs multiplateformes comme Visual Studio Code et Sublime Text, le résultat *.ps1 le fichier sera généralement UTF-8 pseudo-BOM:

  • Cela fonctionne bien sur PowerShell Core.
  • Il peut casser sur Windows PowerShell, si le fichier contient des caractères non-ASCII; Si vous devez utiliser des caractères non-ASCII dans vos scripts, enregistrez-les comme UTF-8 avec BOM.
    
    Sans le BOM, Windows PowerShell (mis)interprète votre script comme étant encodé dans l'ancienne page de Code "ANSI" (déterminée par la locale du système pour pré-Unicode; par exemple, Windows-1252 sur les systèmes US-English).

• à L'inverse, les fichiers qui ont le pseudo-BOM UTF-8 peut être problématique sur les plateformes de type Unix, car ils provoquent des utilitaires Unix tels que cat,sed et awk - et même certains éditeurs tels que gedit - passer le pseudo-BOM à travers, c'est à dire, de la traiter comme .

  • ceci peut ne pas toujours être un problème, mais peut certainement être, comme lorsque vous essayez de lire un fichier en une chaîne de caractères bash avec, par exemple, text=$(cat file) ou text=$(<file) - la variable résultante contiendra le pseudo-BOM comme les 3 premiers octets.