▷Uso de la codificación UTF-8 (CHCP 65001) en el símbolo del sistema / Windows Powershell (Windows 10) ✔️ Foro Ayuda 【 2024 】

Ya no tienes que investigar más por todo internet ya que estás al espacio adecuado, contamos con la solución que deseas sin problemas.

Solución:

Nota:

Esta respuesta muestra cómo cambiar el personaje codificacion en la consola de Windows para UTF-8 (página de código 65001), así que eso conchas tal como cmd.exe y PowerShell correctamente codificar y decodificar caracteres (texto) al comunicarse con programas externos (consola) en PowerShell y en cmd.exe también para E / S de archivos.^[1]
Si, por el contrario, su preocupación es sobre el aspecto separado de las limitaciones de Carácter Unicode representación en las ventanas de la consola, vea las secciones media e inferior de esta respuesta, donde también se discuten las aplicaciones alternativas de la consola (terminal).

¿Microsoft proporciona una alternativa mejorada / completa a chcp 65001 que se puede guardar permanentemente sin alteración manual del Registro?

A partir de (al menos) Windows 10, versión 1903, tiene la opción de establecer la configuración regional del sistema (idioma para programas que no son Unicode) en UTF-8, pero el la característica está en beta al momento de escribir esto.

Para activarlo:

Correr intl.cpl (que abre la configuración regional en el Panel de control)
Siga las instrucciones en la captura de pantalla a continuación.

Esto hará todas las ventanas de la consola futura están predeterminadas en UTF-8 (chcp 65001).
- Advertencias:
  - Si estas usando Windows PowerShell, esto también hará Get-Content y Set-Content (y posiblemente otros contextos en los que Windows PowerShell está predeterminado, por lo que la página de códigos ANSI activa del sistema) predeterminado a UTF-8 (que PowerShell Centro (v6 +) siempre lo hace). Esto significa que, en ausencia de un -Encoding argumento, los archivos sin BOM que están codificados en ANSI (que es históricamente común) se leerán mal y se crearán con Set-Content tendrá codificación UTF-8 en lugar de ANSI.
  - [Fixed in PowerShell 7.1] Hasta al menos PowerShell 7.0, a insecto en la versión de .NET subyacente (.NET Core 3.1) provoca errores de seguimiento en PowerShell: un UTF-8 BOM se antepone inesperadamente a los datos enviados a procesos externos a través de stdin (independientemente de lo que establezca $OutputEncoding a), que en particular rompe Start-Job – vea este problema de GitHub.
  - No todas las fuentes hablan Unicode, así que elija una fuente TT (TrueType), pero incluso ellas suelen admitir solo una subconjunto de todos los personajes, por lo que es posible que tenga que experimentar con fuentes específicas para ver si todos los caracteres que le interesan están representados; consulte esta respuesta para obtener más detalles, que también analiza las aplicaciones de consola (terminal) alternativas que tienen una mejor compatibilidad con la representación Unicode.
  - Como señala eryksun, las aplicaciones de consola heredadas que no “hablan” UTF-8 se limitarán a Entrada solo ASCII y producirá salida incorrecta al intentar generar caracteres fuera del rango ASCII (7 bits). (En el obsoleto Windows 7 y versiones anteriores, los programas pueden incluso choque).
    Si ejecutar aplicaciones de consola heredadas es importante para usted, consulte las recomendaciones de eryksun en los comentarios.
Sin embargo, por Windows PowerShell, es decir no suficiente:
- Además debes selecciona el $OutputEncoding variable de preferencia a UTF-8 así como: $OutputEncoding = [System.Text.UTF8Encoding]::new()^[2]; es más simple agregar ese comando a su $PROFILE (solo usuario actual) o $PROFILE.AllUsersCurrentHost (todos los usuarios) archivo.
- Afortunadamente, esto ya no es necesario en PowerShell Centro, que internamente utiliza de forma predeterminada UTF-8 sin BOM.

Si configura el configuración regional del sistema a UTF-8 es no una opción en su entorno, utilice comandos de inicio en lugar de:

Nota: La advertencia sobre las aplicaciones de consola heredadas mencionadas anteriormente también se aplica aquí. Si ejecutar aplicaciones de consola heredadas es importante para usted, consulte las recomendaciones de eryksun en los comentarios.

Para PowerShell (ambas ediciones), agregue la siguiente línea a su $PROFILE (solo usuario actual) o $PROFILE.AllUsersCurrentHost (todos los usuarios) archivo, que es el equivalente a chcp 65001, complementado con la configuración de la variable de preferencia $OutputEncoding para indicar a PowerShell que envíe datos a programas externos a través de la canalización en UTF-8:
- Tenga en cuenta que correr chcp 65001 de dentro una sesión de PowerShell es no efectivo, porque .NET almacena en caché la codificación de salida de la consola al inicio y no tiene conocimiento de los cambios posteriores realizados con chcp; además, como se ha dicho, Windows PowerShell requiere $OutputEncoding para configurar: consulte esta respuesta para obtener más detalles.

$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding

Por ejemplo, aquí hay un enfoque rápido y sucio para agregar esta línea a $PROFILE programáticamente:

'$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding' + [Environment]::Newline + (Get-Content -Raw $PROFILE) | Set-Content -Encoding utf8 $PROFILE

Para cmd.exe, defina un comando de ejecución automática a través del registro, en valor AutoRun de key HKEY_CURRENT_USERSoftwareMicrosoftCommand Processor (solo usuario actual) o HKEY_LOCAL_MACHINESoftwareMicrosoftCommand Processor (todos los usuarios):
- Por ejemplo, puede usar PowerShell para crear este valor para usted:

# Auto-execute `chcp 65001` whenever the current user opens a `cmd.exe` console
# window (including when running a batch file):
Set-ItemProperty 'HKCU:SoftwareMicrosoftCommand Processor' AutoRun 'chcp 65001 >NUL'

Lectura opcional: Por qué Windows PowerShell ISE es una mala elección:

Si bien el ISE tiene un mejor Unicode representación soporte que la consola, generalmente es una mala elección:

En primer lugar, el ISE es caído en desuso: no es compatible con PowerShell Centro, donde irá todo el desarrollo futuro, y no es multiplataforma, a diferencia del nuevo IDE principal para ambas ediciones de PowerShell, Visual Studio Code, que ya habla UTF-8 de forma predeterminada para PowerShell Centro y se puede configurar para hacerlo para Windows PowerShell.
El ISE es generalmente un entorno para desarrollando guiones, no para ejecutarlos en producción (si está escribiendo scripts (también) para otros, debe asumir que se ejecutarán en el consola); en particular, el comportamiento del ISE no es el mismo en todos los aspectos cuando se trata de ejecutar scripts.
Como señala eryksun, el ISE no admite la ejecución interactivo programas de consola externos, es decir, aquellos que requieren la intervención del usuario:

El problema es que oculta la consola y redirige la salida del proceso (pero no la entrada) a una tubería. La mayoría de las aplicaciones de consola cambian al búfer completo cuando un archivo es una tubería. Además, las aplicaciones interactivas requieren lectura desde stdin, lo que no es posible desde una ventana de consola oculta. (Se puede mostrar a través de ShowWindow, pero una ventana separada para la entrada es torpe).

Si está dispuesto a vivir con esa limitación, cambie la página de códigos activa a 65001 (UTF-8) para una comunicación adecuada con programas externos requiere una solución incómoda:
- Primero debe forzar la creación de la ventana de la consola oculta ejecutando alguna programa externo desde la consola incorporada, por ejemplo, chcp – Verá una ventana de la consola parpadear brevemente.
- Solamente luego puedes configurar [console]::OutputEncoding (y $OutputEncoding) a UTF-8, como se muestra arriba (si la consola oculta aún no se ha creado, obtendrá un handle is invalid error).

^{[1] En PowerShell, si nunca llama externo programas, no tiene que preocuparse por la configuración regional del sistema (páginas de códigos activas): los comandos nativos de PowerShell y las llamadas .NET siempre se comunican a través de cadenas UTF-16 (cadenas nativas .NET) y las E / S de archivos aplican codificaciones predeterminadas que son independientes de la configuración regional del sistema. Del mismo modo, debido a que el Unicode Las versiones de las funciones de la API de Windows se utilizan para imprimir y leer desde la consola, los caracteres que no son ASCII siempre se imprimen correctamente (dentro de las limitaciones de representación de la consola).

En cmd.exe, por el contrario, la configuración regional del sistema también es importante para la E / S de archivos (en particular, incluida la codificación que se debe asumir para el código fuente de los archivos por lotes), no solo para comunicarse con programas externos, como cuando se lee la salida del programa en un for /f círculo.}

^{[2] En PowerShell v4-, donde el static ::new() el método no está disponible, use $OutputEncoding = (New-Object System.Text.UTF8Encoding).psobject.BaseObject. Consulte el número 5763 de GitHub para saber por qué .psobject.BaseObject se necesita parte.}

Puedes poner el comando chcp 65001 en su perfil de Powershell, que lo ejecutará automáticamente cuando abra Powershell. Sin embargo, esto no hará nada para cmd.exe.

Microsoft está trabajando actualmente en un terminal mejorado que tendrá soporte completo para Unicode. Es de código abierto, y si está utilizando Windows 10 versión 1903 o posterior, ya puede descargar una versión de vista previa.

Alternativamente, puede utilizar un emulador de terminal de terceros como Terminus.

Si tienes alguna desconfianza o forma de aumentar nuestro reseña te evocamos escribir una explicación y con gusto lo observaremos.

¡Haz clic para puntuar esta entrada!

(Votos: 0 Promedio: 0)

Uso de la codificación UTF-8 (CHCP 65001) en el símbolo del sistema / Windows Powershell (Windows 10)

Solución:

Lectura opcional: Por qué Windows PowerShell ISE es una mala elección:

Utiliza Nuestro Buscador

Preguntas Relacionadas: