Partager via

à_propos_de_l'encodage_des_caractères

Brève description

Décrit comment PowerShell utilise l’encodage de caractères pour l’entrée et la sortie des données de chaîne.

Description longue

Unicode est une norme d’encodage de caractères mondiale. Le système utilise exclusivement Unicode pour la manipulation de caractères et de chaînes. Pour obtenir une description détaillée de tous les aspects d’Unicode, reportez-vous à le Standard Unicode.

Windows prend en charge les jeux de caractères Unicode et traditionnels. Les jeux de caractères traditionnels, tels que les pages de codes Windows, utilisent des valeurs 8 bits ou des combinaisons de valeurs 8 bits pour représenter les caractères utilisés dans une langue ou des paramètres de région géographique spécifiques.

PowerShell utilise un jeu de caractères Unicode par défaut. Toutefois, plusieurs applets de commande ont un paramètre d’encodage qui peut spécifier l’encodage pour un jeu de caractères différent. Ce paramètre vous permet de choisir l’encodage de caractères spécifique dont vous avez besoin pour l’interopérabilité avec d’autres systèmes et applications.

Les applets de commande suivantes possèdent le paramètre d'encodage :

  • Microsoft.PowerShell.Management
    • Add-Content
    • Get-Content
    • Set-Content
  • Microsoft.PowerShell.Utility
    • Export-Clixml
    • Export-Csv
    • Export-PSSession
    • Format-Hex
    • Import-Csv
    • Out-File
    • Select-String
    • Send-MailMessage

Byte-order-mark

La marque d’ordre d’octet (BOM) est une signature Unicode dans les premiers octets d’un fichier ou d’un flux de texte qui indiquent l’encodage Unicode utilisé pour les données. Pour plus d’informations, veuillez consulter la documentation de Marqueur d’ordre d’octet.

Dans Windows PowerShell, tout encodage Unicode, sauf UTF7, crée toujours un boM. PowerShell (v6 et versions ultérieures) a la valeur par défaut utf8NoBOM pour toutes les sorties de texte.

Pour une meilleure compatibilité globale, évitez d’utiliser des BOM dans des fichiers UTF-8. Les plateformes Unix et les utilitaires hérités d’Unix utilisés également sur les plateformes Windows ne prennent pas en charge les marqueurs d’ordre d’octet.

De même, il faut éviter l'encodage UTF7. UTF-7 n’est pas un encodage Unicode standard et est écrit sans boM dans toutes les versions de PowerShell.

La création de scripts PowerShell sur une plateforme unix ou à l’aide d’un éditeur multiplateforme sur Windows, tel que Visual Studio Code, entraîne un fichier encodé à l’aide de UTF8NoBOM. Ces fichiers fonctionnent correctement dans PowerShell, mais peuvent s’arrêter dans 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 sous la forme UTF-8 avec boM. Sans le BOM, Windows PowerShell interprète incorrectement votre script comme étant encodé dans la code page "ANSI" d'ancienne génération. À l’inverse, les fichiers qui ont le boM UTF-8 peuvent être problématiques sur les plateformes de type Unix. De nombreux outils Unix tels que cat, sed, awket certains éditeurs tels que gedit ne savent pas comment traiter le boM.

Encodage de caractères dans Windows PowerShell

Dans PowerShell 5.1, le paramètre d’encodage prend en charge les valeurs suivantes :

  • Ascii utilise le jeu de caractères Ascii (7 bits).
  • BigEndianUnicode utilise UTF-16 avec l’ordre d’octet big-endian.
  • BigEndianUTF32 utilise UTF-32 avec l’ordre d’octet big-endian.
  • Byte encode un jeu de caractères en une séquence d’octets.
  • Default Utilise l’encodage qui correspond à la page de codes active du système (généralement ANSI).
  • Oem Utilise l’encodage qui correspond à la page de codes OEM actuelle du système.
  • String Identique à Unicode.
  • Unicode utilise UTF-16 avec l’ordre d’octet little-endian.
  • Unknown Identique à Unicode.
  • UTF32 utilise UTF-32 avec l’ordre d’octet little-endian.
  • UTF7 utilise UTF-7.
  • UTF8 utilise UTF-8 (avec BOM).

En règle générale, Windows PowerShell utilise l’encodage UTF-16LE Unicode par défaut. Toutefois, l’encodage par défaut utilisé par les applets de commande dans Windows PowerShell n’est pas cohérent.

Remarque

L’utilisation de tout encodage Unicode, à l’exception de UTF7, crée toujours un marqueur d’ordre d’octet.

Pour les cmdlets qui écrivent des sorties dans des fichiers :

  • Out-File et les opérateurs de redirection > et >> créent UTF-16LE, ce qui diffère notamment des Set-Content et des Add-Content.

  • New-ModuleManifest et Export-Clixml créent également des fichiers UTF-16LE.

  • Lorsque le fichier cible est vide ou n’existe pas, Set-Content et Add-Content utiliser l’encodage Default. Default correspond à l’encodage spécifié par la page de code héritée ANSI de la locale système active.

  • Export-Csv crée des fichiers Ascii, mais utilise un encodage différent lors de l’utilisation de paramètre Append (voir ci-dessous).

  • Export-PSSession crée des fichiers UTF-8 avec boM par défaut.

  • New-Item -Type File -Value crée un fichier UTF-8 sans boM.

  • Send-MailMessage utilise l’encodage Ascii par défaut.

  • Start-Transcript crée des fichiers Utf8 avec un marqueur d’ordre d’octet. Lorsque le paramètre Append est utilisé, l’encodage peut être différent (voir ci-dessous).

Pour les commandes qui s’ajoutent à un fichier existant :

  • Out-File -Append et l’opérateur de redirection >> ne tentent pas de faire correspondre l’encodage du contenu du fichier cible existant. Au lieu de cela, ils utilisent l’encodage par défaut, sauf si le paramètre d’encodage est utilisé. Vous devez utiliser l’encodage d’origine des fichiers lors de l’ajout de contenu.

  • En l’absence d’un paramètre d’encodage explicite, Add-Content détecte l’encodage existant et l’applique automatiquement au nouveau contenu. Si le contenu existant n’a pas de BOM, l'encodage ANSI Default est utilisé. Le comportement de Add-Content est le même dans PowerShell (v6 et versions ultérieures), sauf que l’encodage par défaut est Utf8.

  • Export-Csv -Append correspond à l’encodage existant lorsque le fichier cible contient un boM. En l'absence d'un BOM, il utilise l'encodage Utf8.

  • Start-Transcript -Append correspond à l’encodage existant des fichiers qui incluent un boM. En l'absence d'un BOM, il est encodé par défaut en Ascii. Cet encodage peut entraîner une perte de données ou une altération des caractères lorsque les données de la transcription contiennent des caractères multioctets.

Pour les cmdlets qui lisent les données de chaîne en l’absence d’un BOM :

  • Get-Content et Import-PowerShellDataFile utilise l’encodage ANSI Default. ANSI est également ce que le moteur PowerShell utilise lorsqu’il lit le code source à partir de fichiers.

  • Import-Csv, Import-Clixmlet Select-String supposent Utf8 en l'absence de BOM.

Encodage de caractères dans PowerShell

Dans PowerShell (v7.1 et versions ultérieures), le paramètre Encodage prend en charge les valeurs suivantes :

  • ascii: utilise l’encodage pour le jeu de caractères ASCII (7 bits).
  • ansi: Utilise l’encodage de la page de codes ANSI de la culture actuelle. Cette option a été ajoutée dans PowerShell 7.4.
  • bigendianunicode: encode au format UTF-16 avec primauté des octets de poids fort.
  • bigendianutf32: encode au format UTF-32 avec primauté des octets de poids fort.
  • oem: utilise l’encodage par défaut pour les programmes MS-DOS et console.
  • unicode: encode au format UTF-16 avec primauté des octets de poids faible.
  • utf7: encode au format UTF-7.
  • utf8: encodé au format UTF-8 (sans BOM).
  • utf8BOM: encode au format UTF-8 avec un Byte Order Mark (BOM).
  • utf8NoBOM: encode au format UTF-8 sans marque d’ordre d’octet (BOM)
  • utf32: encode au format UTF-32 avec primauté des octets de poids faible.

PowerShell a la valeur par défaut utf8NoBOM pour toutes les sorties.

À compter de PowerShell 6.2, le paramètre d’encodage autorise également des ID numériques de pages de codes inscrites (comme -Encoding 1251) ou des noms de chaînes de pages de codes inscrites (comme -Encoding "windows-1251"). Pour plus d’informations, consultez la documentation .NET pour Encoding.CodePage.

À partir de PowerShell 7.4, vous pouvez utiliser la valeur ANSI pour le paramètre d'encodage afin de passer l'ID numérique de la page de codes ANSI de la culture actuelle sans avoir à le spécifier manuellement.

Modification de l’encodage par défaut

PowerShell a deux variables par défaut qui peuvent être utilisées pour modifier le comportement d’encodage par défaut.

  • $PSDefaultParameterValues
  • $OutputEncoding

Pour plus d’informations, veuillez consulter la section about_Preference_Variables.

À compter de PowerShell 5.1, les opérateurs de redirection (> et >>) appellent l’applet de commande Out-File. Par conséquent, vous pouvez définir l’encodage par défaut de ceux-ci à l’aide de la variable de préférence $PSDefaultParameterValues, comme illustré dans cet exemple :

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

Utilisez l’instruction suivante pour modifier l’encodage par défaut pour toutes les applets de commande qui ont le paramètre d’encodage .

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

Important

Si vous placez cette commande dans votre profil PowerShell, la préférence est un paramètre global de session qui affecte toutes les commandes et scripts qui ne spécifient pas explicitement un encodage.

De même, vous devez inclure ces commandes dans vos scripts ou modules que vous souhaitez comporter de la même façon. À l’aide de ces commandes, assurez-vous que les applets de commande se comportent de la même façon, même lorsqu’elles sont exécutées par un autre utilisateur, sur un autre ordinateur ou dans une autre version de PowerShell.

La variable automatique $OutputEncoding affecte l’encodage que PowerShell utilise pour communiquer avec des programmes externes. Il n’a aucun effet sur l’encodage que les opérateurs de redirection de sortie et les applets de commande PowerShell utilisent pour enregistrer dans des fichiers.

Voir aussi

  • Last updated on