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-File
través de la $PSDefaultParameterValues
variable 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 $PSDefaultParameterValues
variable 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 -Encoding
parámetro (que en PSv5.1 + incluye >
y >>
), use:
$PSDefaultParameterValues['*:Encoding'] = 'utf8'
Si coloca este comando en sus$PROFILE
cmdlets como Out-File
ySet-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 $OutputEncoding
variable 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-Content
por defecto a BOM-menos UTF-8; El uso explícito del utf8
-Encoding
argumento también crea UTF-8 sin BOM , pero puede optar por crear archivos con el pseudo BOM con el utf8bom
valor.
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 *.ps1
archivo 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
bash
con, 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-File
y >
/ >>
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-ModuleManifest
y Export-CliXml
también crea archivos UTF-16LE.
Set-Content
(y Add-Content
si 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-Csv
de hecho crea archivos ASCII, como se documenta, pero vea las notas a -Append
continuación.
Export-PSSession
crea archivos UTF-8 con BOM por defecto.
New-Item -Type File -Value
actualmente crea UTF-8 sin BOM (!).
El Send-MailMessage
tema 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 -Append
continuación.
Re comandos que se anexan a un archivo existente:
>>
/ Out-File -Append
Hacer 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-Content
es la loable excepción: en ausencia de un -Encoding
argumento 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 -Append
asume que UTF-8 es, mientras que se Add-Content
asume 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-Content
y por Import-PowerShellDataFile
defecto 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-CliXml
y Select-String
asumir UTF-8 en ausencia de una lista de materiales.
>
/ se>>
convirtió en un alias efectivoOut-File
en 5.1?$PSDefaultParameterValues
Para ser breve, use:
write-output "your text" | out-file -append -encoding utf8 "filename"
fuente