¿Manejar caracteres extendidos en los comandos de Windows?

Question

Estoy depurando un archivo de comando de Windows Batch. Está fallando cuando se usan caracteres extendidos (> 0x7f) en las rutas o nombres de archivos. El problema parece estar relacionado con pasar parámetros a un archivo de comando que está LLAMADO desde otro.

Por ejemplo, este comando funciona como se esperaba:

xcopy "Pezuñero\1 - 001.wav" \temp 

Esto no significa:

call another.cmd "Pezuñero" 

contenidos de "another.cmd":

xcopy "%~1\1 - 001.wav" \temp 

El% ~ 1 sintaxis expande un parámetro y elimina las comillas. Esto es necesario porque en el archivo de comando real, las rutas en el archivo de comando llamado o llamado pueden tener espacios.

El resultado del segundo ejemplo (copiado de la ventana CMD) es la siguiente:

C:\>call another.cmd "Pezu±ero"  

C:\>xcopy "Pezu±ero\1 - 001.wav" \temp 
File not found - 1 - 001.wav 
0 File(s) copied 

Tenga en cuenta que el (0xf1) carácter "ñ" se ha cambiado a un "±" (0xB1).

¿Alguien puede explicar lo que está pasando y cómo solucionarlo?

Answer 1

Gracias a McDowell y Romulo por orientarme en la dirección correcta. Me di cuenta de que necesitaba cambiar mi aplicación (en Delphi) que genera el lote para que use la página de códigos apropiada (OEM) que es compatible con el procesador de comandos en Windows. No encontré nada para convertir cadenas de página de códigos, pero sí descubrí las funciones API de Windows SetFileApisToOEM y SetFileApisToANSI;

que poner estos al principio y al final de mi programa, así:

{main procedure} 
begin 
    SetFileApisToOEM; 
    {all the rest of the program} 
    SetFileApisToANSI; 
end. 

Ahora los archivos por lotes se generan con la página de códigos OEM, y que funcionan correctamente cuando se ejecuta desde una línea de CMD.

Answer 2

Puede necesitar establecer la página de códigos en una que tenga la n con ~ en la parte superior.

Answer 3

Las páginas de códigos son un problema en los archivos por lotes, ya que no tienen permitido contener Unicode. La forma más fácil de evitar este problema sería usar WSH o Powershell. No he encontrado una solución alternativa para los archivos por lotes hasta ahora, lo que realmente me molesta ya que me considero un fanático de Unicode :)

Answer 4

La secuencia de comandos se debe escribir en la misma codificación cmd.exe utiliza.

Escriba chcp en el indicador y vea lo que obtiene. A continuación, abra el archivo con un editor que admita esa codificación. Para mí chcp salidas de página de códigos , entonces edito mi secuencia de comandos en JEdit seleccionando IBM850 como la codificación del archivo. Obtengo el mismo resultado editando el archivo en PSPad con Formato establecido en OEM.

PD: He probado sus pasos en mi máquina y el carácter ñ que escribo en notepad.exe (utilizando la codificación ANSI predeterminado) también se convierte en un ± cuando se lee desde el símbolo del sistema, por lo que parece que su máquina utiliza codificaciones ANSI y OEM similares. Para asegurarse, intente reemplazar el ñ por un ¤ (con notepad.exe). Eso hace que el script funcione correctamente para mí cuando se ejecuta desde el símbolo del sistema (porque el valor de byte del de ANSI ¤ es el mismo que el del OEM ñ).

Answer 5

He estado looking at character handling in cmd.exe y creo que Romulo ha golpeado el clavo en la cabeza. De forma predeterminada, el mensaje usa páginas de códigos de DOS (OEM) antiguas (probablemente por compatibilidad con programas de DOS). Está escribiendo su archivo usando (probablemente) la página predeterminada de códigos de Windows (probablemente 1252), que es diferente. Use edit.com para editar el archivo por lotes.

Si escribo chcp en el indicador, se informa de la página de códigos 850.

Así, por ejemplo, si uso el Bloc de notas Para escribir esto:

DIR Pezuñero 

... este se codifica como 1252 con los valores binarios:

     ñ 
44 49 52 20 50 65 7A 75 F1 65 72 6F 

Si uso edit escribir el archivo, se codifica como 850 con los valores binarios:

     ñ 
44 49 52 20 50 65 7A 75 A4 65 72 6F 

Una cosa que no he mirado es utilizar el modificador/u cmd, pero estoy bastante seguro de que es única para comandos de shell incorporados y no lo ayudará con XCOPY.