Nota: Lo siguiente se aplica a Windows PowerShell .
Consulte la siguiente sección para conocer la edición multiplataforma de PowerShell Core (v6 +) .
En PSv5.1 o superior , donde >y >>son efectivamente alias de Out-File, puede establecer la codificación predeterminada para >/ >>/ a Out-Filetravés de la $PSDefaultParameterValuesvariable de preferencia :
$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'
En PSv5.0 o por debajo , que no se puede cambiar la codificación de >/>> , pero, en PSV3 o superior , la técnica anterior hace el trabajo para las llamadas explícitas aOut-File .
(La $PSDefaultParameterValuesvariable de preferencia se introdujo en PSv3.0).
En PSv3.0 o superior , si desea establecer la codificación predeterminada para todos los cmdlets que admiten
un -Encodingparámetro (que en PSv5.1 + incluye >y >>), use:
$PSDefaultParameterValues['*:Encoding'] = 'utf8'
Si coloca este comando en sus$PROFILE cmdlets como Out-FileySet-Content usará la codificación UTF-8 de forma predeterminada, pero tenga en cuenta que esto lo convierte en una configuración global de sesión que afectará a todos los comandos / scripts que no especifican explícitamente una codificación.
Del mismo modo, asegúrese de incluir los comandos en sus scripts o módulos que desea que se comporten de la misma manera , de modo que de hecho se comporten de la misma manera incluso cuando los ejecute otro usuario o una máquina diferente.
Advertencia : ** PowerShell, a partir de v5.1, crea invariablemente archivos UTF-8 _con una (pseudo) BOM _ ** , que es habitual solo en el mundo de Windows - las utilidades basadas en Unix no reconocen esta BOM (ver abajo); consulte esta publicación para conocer las soluciones que crean archivos UTF-8 sin BOM.
Para obtener un resumen del comportamiento de codificación de caracteres predeterminado tremendamente inconsistente en muchos de los cmdlets estándar de Windows PowerShell , consulte la sección inferior.
La $OutputEncodingvariable automática no está relacionada y solo se aplica a cómo PowerShell se comunica con programas externos (qué codificación usa PowerShell cuando les envía cadenas); no tiene nada que ver con la codificación que los operadores de redirección de salida y los cmdlets de PowerShell usan para guardar en archivos.
Lectura opcional: La perspectiva multiplataforma: PowerShell Core :
PowerShell ahora es multiplataforma , a través de su edición PowerShell Core , cuya codificación, sensiblemente, se predetermina a UTF-8 sin BOM , en línea con plataformas similares a Unix.
Esto significa que los archivos de código fuente sin una lista de materiales se supone que ser UTF-8, y el uso >/ Out-File/ Set-Contentpor defecto a BOM-menos UTF-8; El uso explícito del utf8 -Encodingargumento también crea UTF-8 sin BOM , pero puede optar por crear archivos con el pseudo BOM con el utf8bomvalor.
Si crea scripts de PowerShell con un editor en una plataforma similar a Unix y hoy en día incluso en Windows con editores multiplataforma como Visual Studio Code y Sublime Text, el *.ps1archivo resultante normalmente no tendrá una pseudo-BOM UTF-8:
- Esto funciona bien en PowerShell Core .
- Puede fallar en Windows PowerShell , si el archivo contiene caracteres que no son ASCII; Si necesita utilizar caracteres que no sean ASCII en sus scripts, guárdelos como UTF-8 con BOM .
Sin la lista de materiales, Windows PowerShell (mis) interpreta su secuencia de comandos como codificada en la página de códigos "ANSI" heredada (determinada por la configuración regional del sistema para aplicaciones pre-Unicode; por ejemplo, Windows-1252 en sistemas en inglés de EE. UU.).
A la inversa, los archivos que hacen tienen el UTF-8 pseudo-BOM puede ser problemático en Unix-como plataformas, ya que causa utilidades Unix, tales como cat, sed, y awk- e incluso algunos editores tales como gedit- para pasar el pseudo-BOM a través de , es decir, para tratarlo como datos .
- Esto no siempre puede ser un problema, pero definitivamente puede serlo, como cuando intenta leer un archivo en una cadena
bashcon, digamos, text=$(cat file)o text=$(<file)- la variable resultante contendrá la pseudo-BOM como los primeros 3 bytes.
Comportamiento de codificación predeterminado incoherente en Windows PowerShell :
Lamentablemente, la codificación de caracteres predeterminada utilizada en Windows PowerShell es tremendamente inconsistente; la edición multiplataforma de PowerShell Core , como se discutió en la sección anterior, ha puesto fin a esto de manera encomiable.
Nota:
Lo siguiente no aspira a cubrir todos los cmdlets estándar.
Al buscar en Google los nombres de los cmdlets para encontrar sus temas de ayuda, ahora se muestra la versión PowerShell Core de los temas de forma predeterminada; use la lista desplegable de versiones sobre la lista de temas de la izquierda para cambiar a una versión de Windows PowerShell .
En el momento de escribir este artículo, la documentación suele afirmar incorrectamente que ASCII es la codificación predeterminada en Windows PowerShell; consulte este problema de documentos de GitHub .
Cmdlets que escriben :
Out-Filey >/ >>crear archivos "Unicode" - UTF-16LE - por defecto - en los que cada carácter de rango ASCII (también) está representado por 2 bytes - lo cual difiere notablemente de Set-Content/ Add-Content(ver el siguiente punto); New-ModuleManifesty Export-CliXmltambién crea archivos UTF-16LE.
Set-Content(y Add-Contentsi el archivo aún no existe / está vacío) usa codificación ANSI (la codificación especificada por la página de códigos heredados ANSI de la configuración regional activa, a la que PowerShell llama Default).
Export-Csvde hecho crea archivos ASCII, como se documenta, pero vea las notas a -Appendcontinuación.
Export-PSSession crea archivos UTF-8 con BOM por defecto.
New-Item -Type File -Value actualmente crea UTF-8 sin BOM (!).
El Send-MailMessagetema de ayuda también afirma que la codificación ASCII es la predeterminada; no he verificado personalmente esa afirmación.
Start-Transcript invariablemente crea archivos UTF-8 con BOM, pero consulte las notas a -Appendcontinuación.
Re comandos que se anexan a un archivo existente:
>>/ Out-File -AppendHacer ningún intento para que coincida con la codificación de de un archivo de contenido existente . Es decir, aplican ciegamente su codificación predeterminada, a menos que se indique lo contrario con -Encoding, que no es una opción con >>(excepto indirectamente en PSv5.1 +, via $PSDefaultParameterValues, como se muestra arriba). En resumen: debe conocer la codificación del contenido de un archivo existente y agregar usando esa misma codificación.
Add-Contentes la loable excepción: en ausencia de un -Encodingargumento explícito , detecta la codificación existente y la aplica automáticamente al nuevo contenido. Gracias, js2010 . Tenga en cuenta que en Windows PowerShell esto significa que la codificación ANSI se aplica si el contenido existente no tiene BOM, mientras que en PowerShell Core es UTF-8.
Esta incoherencia entre Out-File -Append/ >>y Add-Content, que también afecta a PowerShell Core , se analiza en este problema de GitHub .
Export-Csv -Append coincide parcialmente con la codificación existente: agrega ciegamente UTF-8 si la codificación del archivo existente es ASCII / UTF-8 / ANSI, pero coincide correctamente con UTF-16LE y UTF-16BE.
Para decirlo de otra manera: en ausencia de una lista de materiales, se Export-Csv -Appendasume que UTF-8 es, mientras que se Add-Contentasume que es ANSI.
Start-Transcript -Append Coincide parcialmente con la codificación existente: Coincide correctamente con las codificaciones con la lista de materiales , pero por defecto la codificación ASCII potencialmente con pérdida en ausencia de una.
Cmdlets que leen (es decir, la codificación utilizada en ausencia de una lista de materiales ):
Get-Contenty por Import-PowerShellDataFiledefecto ANSI ( Default), que es consistente con Set-Content.
ANSI también es lo que el motor de PowerShell tiene por defecto cuando lee el código fuente de los archivos.
Por el contrario, Import-Csv, Import-CliXmly Select-Stringasumir UTF-8 en ausencia de una lista de materiales.
>/ se>>convirtió en un alias efectivoOut-Fileen 5.1?