Я попытался получить robocopy в Windows 7 для создания журнала Unicode, так как у меня есть файлы с символами Unicode. Команда, которую я использовал:
robocopy C:\mysource D:\mydest /mir /unilog:backup.log /tee
Файл копии работает, и вывод на экран правильный, сам файл журнала просто содержит бред. Это независимо от того, использую ли я командную строку или Powershell.
Что дает? Я делаю что-то неправильно?
Похоже, это ошибка в версии RoboCopy для XP27 (которая поставляется с Windows 7).
В версии XP26 (которая поставляется с Windows Vista) /UNILOG создает отлично читаемый файл журнала Unicode для меня.
Если у вас нет копии Vista, лежащей вокруг EasyRoboCopy, также поставляется версия XP26 . (Я на самом деле не пробовал сам EasyRoboCopy, просто извлекается robocopy.exe из его установочного файла с помощью WinRAR
На первый взгляд, я бы сказал, что файл, написанный Robocopy при использовании /UNILOG и /TEE содержит метку порядка байтов в порядке байтов UTF-16, за которой следует машинописный код терминала ISO-8859-1.
Чтобы сделать его читабельным, я сделал в Ubuntu следующее:
dd if=robocopy.log ibs=1 skip=2 obs=512 | # Strip the byte order mark
iconv --from-code ISO-8859-1 --to-code UTF-8 | # Convert to UTF-8
col -b > robocopy_utf-8.log # Interpret control characters
Полученный файл соответствует тому, что я видел в командной строке Windows.
Если имена ваших файлов или каталогов содержат символы Unicode, перед выполнением команды Robocopy с параметром /unilog используйте команду chcp 65001 . (Кодовая страница 65001 - UTF-8 .)
Получив искаженный журнал Unicode, просто откройте его в MS Word как Unicode (UTF-8) и сохраните его:
Если посмотреть на вывод (двоичного) файла на Win7, опция /UNILOG бесполезна. Он записывает стандартную UNICODE BOM (FFFE), но затем переходит к записи всех узких символов, КРОМЕ для строки параметров (например, /BYTES /S /COPY:DATS ...), которая является фактическим Unicode. После этого, он возвращается к ANSI символов, и это не UTF-8, либо; то есть, если у вас есть имя файла с широким символом в пути, оно преобразуется в узкий '?' персонаж.
Очевидно, нет никакого интереса к его исправлению из MSFT, так как это было в течение некоторого времени, и у меня есть все обновления.
Я исправил свои нечитаемые файлы журнала Robocopy в формате Unicode в Windows (которые были случайно созданы путем добавления нормального вывода Robocopy к выводу Unicode из Out-File в PowerShell) следующим образом:
В PowerShell:
$bytes = [System.IO.File]::ReadAllBytes('C:\Temp\RoboCopyLog.txt')
$len = $bytes.Length
#Remove the Unicode BOM, and convert to ASCII
$text = [System.Text.Encoding]::ASCII.GetString($bytes,2,$len -2)
$text
Приведенный выше код может не работать для всех размеров файлов!
(Кредит за код: я адаптировал код из этого поста от Фердинанда Прантля: Stackoverflow - чтение / анализ двоичных файлов с помощью PowerShell
Выполните команду chcp перед командой robocopy с правильной кодовой страницей.
для UTF-8 (не работает с robocopy и ивритом и, возможно, с другими языками):
chcp 65001 | Out-Null
для иврита:
chcp 1255 | Out-Null
Полный список кодовых страниц:https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers
В вашем случае команда в Powershell выглядит примерно так:
robocopy C:\mysource D:\mydest /mir | Out-File backup.log
Обходной путь заключается в том, что вы используете Out-File вместо встроенного /unilog параметра. Вы получите точно такой же файл журнала, но теперь он будет правильно записан в юникоде.