Partager via

about_Character_Encoding

  • Article

Description courte

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 à la norme 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 ont le paramètre 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, consultez la documentation sur les marques de commande d’octets.

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

Pour une meilleure compatibilité globale, évitez d’utiliser des machines virtuelles dans des fichiers UTF-8. Les plateformes Unix et les utilitaires unix-heritage également utilisés sur les plateformes Windows ne prennent pas en charge les machines virtuelles.

De même, UTF7 l’encodage doit être évité. 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 UTF8NoBOMde . 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 mal votre script comme étant encodé dans la page de codes « ANSI » héritée. À 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 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 dans 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’aide de n’importe quel encodage Unicode, à l’exception UTF7de , crée toujours un boM.

Pour les applets de commande qui écrivent une sortie dans des fichiers :

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

  • New-ModuleManifest et Export-CliXml créez également des fichiers UTF-16LE.

  • Lorsque le fichier cible est vide ou n’existe pas, Set-Content et Add-Content utilisez Default l’encodage. Default est l’encodage spécifié par la page de codes héritée ANSI des paramètres régionaux système actifs.

  • Export-Csv crée des Ascii fichiers, mais utilise un encodage différent lors de l’utilisation du 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 Ascii l’encodage par défaut.

  • Start-Transcript crée des Utf8 fichiers avec un boM. 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 n’essaient pas de 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, Default l’encodage ANSI est utilisé. Le comportement est Add-Content 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 Utf8 l’encodage.

  • Start-Transcript -Append correspond à l’encodage existant des fichiers qui incluent un boM. En l’absence d’un boM, il est par défaut encodage 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 applets de commande qui lisent les données de chaîne en l’absence d’un boM :

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

  • Import-Csv, Import-CliXmlet Select-String supposez Utf8 en l’absence d’un boM.

Encodage de caractères dans PowerShell

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

  • ascii: utilise l’encodage pour le jeu de caractères ASCII (7 bits).
  • ansi: utilise l’encodage pour 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 à l’aide de l’ordre d’octet big-endian.
  • bigendianutf32: encode au format UTF-32 à l’aide de l’ordre d’octet big-endian.
  • oem: utilise l’encodage par défaut pour les programmes MS-DOS et console.
  • unicode: encode au format UTF-16 à l’aide de l’ordre d’octet little-endian.
  • utf7: encode au format UTF-7.
  • utf8: encode au format UTF-8 (sans boM).
  • utf8BOM: encode au format UTF-8 avec marque d’ordre d’octet (BOM)
  • utf8NoBOM: encode au format UTF-8 sans marque d’ordre d’octet (BOM)
  • utf32: encode au format UTF-32 à l’aide de l’ordre d’octet little-endian.

PowerShell est défini par défaut pour toutes les sorties utf8NoBOM .

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

À compter de PowerShell 7.4, vous pouvez utiliser la Ansi valeur du paramètre Encodage pour 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, consultez about_Preference_Variables.

À compter de PowerShell 5.1, les opérateurs de redirection (> et >>) appellent l’applet Out-File de commande. Par conséquent, vous pouvez définir l’encodage par défaut de ceux-ci à l’aide de la $PSDefaultParameterValues variable de préférence, 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 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 $OutputEncoding automatique 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