acentos - Cambiar la codificación de salida predeterminada de PowerShell a UTF-8

powershell acentos

Question

De forma predeterminada, cuando redirige la salida de un comando a un archivo o lo canaliza a otra cosa en PowerShell, la codificación es UTF-16, lo que no es útil. Estoy buscando cambiarlo a UTF-8.

Se puede hacer caso por caso reemplazando la sintaxis >foo.txt con | out-file foo.txt -encoding utf8 | out-file foo.txt -encoding utf8 pero esto es incómodo de tener que repetir cada vez.

La forma persistente de configurar cosas en PowerShell es ponerlas en /Users/me/Documents/WindowsPowerShell/profile.ps1 ; Verifiqué que este archivo se ejecuta de hecho al inicio.

Se ha dicho que la codificación de salida se puede establecer con $PSDefaultParameterValues = @{''Out-File:Encoding'' = ''utf8''} pero he intentado esto y no tuvo ningún efecto.

https://blogs.msdn.microsoft.com/powershell/2006/12/11/outputencoding-to-the-rescue/ que habla de $OutputEncoding parece a primera vista como si fuera relevante, pero luego habla de salida estar codificado en ASCII, que no es lo que realmente está sucediendo.

¿Cómo se configura PowerShell para usar UTF-8?

Answer 1

Nota: Lo siguiente se aplica a Windows PowerShell . Consulte la siguiente sección para la edición multiplataforma de PowerShell Core .

• En PSv5.1 o superior , donde > y >> son efectivamente alias de Out-File , puede establecer la codificación predeterminada para > / >> / Out-File través de la variable de preferencia $PSDefaultParameterValues :

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

• En PSv5.0 o inferior , no puede cambiar la codificación para > / >> , pero, en PSv3 o superior , la técnica anterior funciona para llamadas a Out-File .
  (La variable de preferencia $PSDefaultParameterValues se introdujo en PSv3.0).

• En PSv3.0 o superior , si desea establecer la codificación predeterminada para todos los cmdlets que admitan
  un parámetro de -Encoding (que en PSv5.1 + incluye > y >> ), usa:

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

Si coloca este comando en su $PROFILE , los cmdlets como Out-File y Set-Content usarán 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 especifique explícitamente una codificación.

Del mismo modo, asegúrese de incluir dichos comandos en sus scripts o módulos que desee que se comporten de la misma manera , de modo que 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).

Para obtener un resumen del comportamiento de codificación de caracteres predeterminado muy inconsistente en muchos de los cmdlets estándar de Windows PowerShell , consulte la sección inferior.

La variable automática $OutputEncoding no está relacionada , y solo se aplica a cómo PowerShell se comunica con programas externos (qué codificación utiliza PowerShell al enviar 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, con sensatez, se predetermina a UTF-8 sin BOM , en línea con plataformas similares a Unix.

• Esto significa que se supone que los archivos de código fuente sin una lista de materiales son UTF-8, y que el uso de > / Out-File / Set-Content predeterminado en BOM-less UTF-8; El uso explícito del argumento utf8 -Encoding también crea UTF-8 sin BOM , pero puede optar por crear archivos con pseudo-BOM con el valor utf8bom .

• 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 archivo *.ps1 resultante generalmente no tendrá un pseudo-BOM UTF-8 :

  • Esto funciona bien en PowerShell Core .
  • Puede romperse en Windows PowerShell , si el archivo contiene caracteres no ASCII; si necesita usar caracteres no ASCII en sus scripts, guárdelos como UTF-8 con BOM .
    Sin la lista de materiales, Windows PowerShell (incorrecto) interpreta que su secuencia de comandos está codificada en la página de códigos "ANSI" heredada (determinada por la configuración regional del sistema para aplicaciones anteriores a Unicode; por ejemplo, Windows-1252 en sistemas de EE. UU.

• Por el contrario, los archivos que tienen el pseudo-BOM UTF-8 pueden ser problemáticos en plataformas similares a Unix, ya que hacen que las utilidades de Unix como cat , sed y awk , e incluso algunos editores como gedit , pasen el pseudo-BOM a través , es decir, tratarlo como datos .

  • Esto puede no ser siempre un problema, pero definitivamente puede serlo, como cuando intentas leer un archivo en una cadena en bash con, por ejemplo, text=$(cat file) o text=$(<file) - la variable resultante contendrá el pseudo-BOM como los primeros 3 bytes.

Comportamiento de codificación predeterminado inconsistente en Windows PowerShell :

Lamentablemente, la codificación de caracteres predeterminada utilizada en Windows PowerShell es muy inconsistente; la edición multiplataforma de PowerShell Core , como se discutió en la sección anterior, ha puesto fin a esto.

Nota:

• Lo siguiente no aspira a cubrir todos los cmdlets estándar.

• Buscar en Google los nombres de cmdlet para encontrar sus temas de ayuda ahora muestra la versión PowerShell Core de los temas de forma predeterminada; use la lista desplegable de versiones sobre la lista de temas a la izquierda para cambiar a una versión de Windows PowerShell .

• Al momento de escribir esto, la documentación frecuentemente afirma incorrectamente que ASCII es la codificación predeterminada en Windows PowerShell; consulte este problema de documentos de GitHub .

Cmdlets que escriben :

Out-File y > / >> crean "Unicode" - UTF-16LE - archivos por defecto - en los que cada carácter de rango ASCII (también) está representado por 2 bytes, que difiere notablemente de Set-Content / Add-Content (ver siguiente punto); New-ModuleManifest y Export-CliXml también crean archivos UTF-16LE.

Set-Content (y Add-Content si el archivo aún no existe / está vacío) usa la codificación ANSI (la codificación especificada por la página de códigos heredados ANSI del entorno local del sistema, que PowerShell llama Default ).

Export-Csv hecho crea archivos ASCII, como se documenta, pero vea las notas que se vuelven a -Append continuación.

Export-PSSession crea archivos UTF-8 con BOM por defecto.

New-Item -Type File -Value actualmente crea BOM-less (!) UTF-8.

El tema de ayuda Send-MailMessage también afirma que la codificación ASCII es la predeterminada: no he verificado personalmente esa afirmación.

Re comandos que se agregan a un archivo existente:

>> / Out-File -Append no intente hacer coincidir la codificación del contenido existente de un archivo. Es decir, aplican ciegamente su codificación predeterminada, a menos que se les indique lo contrario con -Encoding , que no es una opción con >> (excepto indirectamente en PSv5.1 +, a través de $PSDefaultParameterValues , como se muestra arriba). En resumen: debe conocer la codificación del contenido de un archivo existente y agregarla utilizando esa misma codificación.

Add-Content es la laudable excepción: en ausencia de un argumento explícito de -Encoding , 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 se aplica la codificación ANSI si el contenido existente no tiene BOM, mientras que es UTF-8 en PowerShell Core.

Esta inconsistencia entre Out-File -Append / >> y Add-Content , que también afecta a PowerShell Core , se discute en este tema de GitHub .

Export-Csv -Append coincide parcialmente con la codificación existente: agrega ciegamente UTF-8 si la codificación del archivo existente es cualquiera de 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 supone UTF-8, mientras que Set-Content / Add-Content predeterminado en ANSI.

Cmdlets que leen (codificación utilizada en ausencia de una lista de materiales):

Get-Content e Import-PowerShellDataFile predeterminado en ANSI ( Default ), que es coherente con Set-Content .

Por el contrario, Import-Csv , Import-CliXml y Select-String asumen UTF-8 en ausencia de una lista de materiales, a diferencia de Get-Content e Import-PowerShellDataFile