Обработка расширенных символов в командах Windows?

Question

Я отлаживаю командный файл Windows. Сбой при использовании расширенных (> 0x7f) символов в путях или именах файлов. Кажется, проблема связана с передачей параметров в командный файл, который вызывается из другого.

Например, эта команда работает должным образом:

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

Это не:

call another.cmd "Pezuñero" 

Содержимое файла "another.cmd":

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

Синтаксис% ~ 1 расширяет параметр и удаляет кавычки. Это необходимо, поскольку в реальном командном файле пути в вызывающем или вызываемом командном файле могут иметь пробелы.

Результат второго примера (скопированного из окна CMD) таков:

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

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

Обратите внимание, что символ «-» (0xF1) был изменен на «±» (0xB1).

Может кто-нибудь объяснить, что происходит и как обойти это?

Answer 1

Сценарий должен быть написан в той же кодировке cmd.exe использует.

Введите chcp в командной строке и посмотрите, что вы получите. Затем откройте файл в редакторе, который поддерживает эту кодировку. Для меня chcp выводит кодовую страницу 850 , поэтому я редактирую свой скрипт в JEdit , выбирая IBM850 в качестве кодировки файла. Я получаю тот же результат, редактируя файл в PSPad с Формат , установленным на OEM .

PS: я проверил ваши шаги на моей машине, и символ - , который я пишу в notepad.exe (используя кодировку ANSI по умолчанию), также преобразуется в ± при чтении из командной строки, поэтому похоже, что ваша машина использует аналогичные кодировки ANSI и OEM. Чтобы быть уверенным, попробуйте заменить - на ¤ (с notepad.exe ). Это заставляет скрипт работать корректно при запуске из командной строки (потому что значение байта ANSI ¤ такое же, как у OEM - ).

Answer 2

Спасибо Макдауэллу и Ромуло за то, что они указали мне правильное направление. Я понял, что мне нужно изменить свое приложение (в Delphi), которое генерирует пакет, чтобы оно использовало надлежащую (OEM) кодовую страницу, совместимую с командным процессором в Windows. Я не нашел ничего для преобразования строк кодовой страницы, но я обнаружил функции Windows API SetFileApisToOEM и SetFileApisToANSI;

Я помещаю их в начало и конец моей программы, например:

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

Теперь пакетные файлы создаются с кодовой страницей OEM и работают правильно при запуске из приглашения CMD.

Answer 3

Я смотрю на обработку символов в cmd.exe , и я думаю, Romulo ударило по голове. По умолчанию в приглашении используются старые кодовые страницы DOS (OEM) (возможно, для совместимости с программами DOS). Вы пишете свой файл, используя (вероятно) кодовую страницу Windows по умолчанию (вероятно, 1252), которая отличается. Используйте edit.com для редактирования командного файла.

Если я наберу chcp в командной строке, он сообщит кодовую страницу 850.

Так, например, если я использую Блокнот , введите:

DIR Pezuñero

... это кодируется как 1252 с двоичными значениями:

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

Если я использую edit для записи файла, он кодируется как 850 с двоичными значениями:

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

Одна вещь, на которую я не обращал внимания, - это использование ключа cmd / U , но я уверен, что он предназначен только для встроенных команд оболочки и не поможет вам с XCOPY.

Answer 4

Кодовые страницы являются проблемой в пакетных файлах, поскольку они не могут содержать Unicode. Вероятно, проще всего вообще избежать этой проблемы - использовать WSH или Powershell. Пока я не нашел обходного пути для пакетных файлов, который действительно беспокоит меня, так как я считаю себя фанатиком Unicode:)

Answer 5

Возможно, вам понадобится установить кодовую страницу с буквой n в верхней части.