Próbowałem uzyskać robocopy w systemie Windows 7, aby wygenerować dziennik Unicode, ponieważ mam pliki ze znakami Unicode. Polecenie, którego użyłem:

robocopy C:\mysource D:\mydest /mir /unilog:backup.log /tee

Plik kopii działa, a wynik na ekranie jest poprawny, sam plik dziennika zawiera tylko bełkot. Jest to niezależne od tego, czy korzystam z wiersza polecenia, czy z programu Powershell.

Co daje? czy robię coś źle?

Błąd w XP27. Spróbuj obniżyć do XP26.

Wygląda na to, że jest to błąd w XP27wersji RoboCopy (która jest dostarczana z Windows 7).

W wersji XP26(dostarczanej z Windows Vista) /UNILOGtworzy dla mnie doskonale czytelny plik dziennika Unicode.

Jeśli nie masz kopii Visty wokół EasyRoboCopy, dołączona jest również XP26wersja. (Właściwie nie próbowałem sam EasyRoboCopy, po prostu wyodrębniłem robocopy.exego z pliku instalacyjnego za pomocą WinRAR.)

Na pierwszy rzut oka powiedziałbym, że plik napisany przez Robocopy podczas używania przełączników /UNILOGi /TEEzawiera znak kolejności bajtów endianu UTF-16, po którym następuje terminal maszynowy ISO-8859-1.

Aby było czytelne, wykonałem następujące czynności w 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

Wynikowy plik jest zgodny z tym, co zobaczyłem w wierszu polecenia systemu Windows.

Dalsza lektura: mężczyzna dd, mężczyzna iconv, mężczyznacol

Patrząc na (binarne) wyjście pliku Win7, opcja / UNILOG jest bezużyteczna. Zapisuje standardowy UNICODE BOM (FFFE), ale następnie zapisuje wszystkie wąskie znaki Z WYJĄTKIEM linii opcji (np. / BYTES / S / COPY: DATS ...), która jest faktycznym unicode. Następnie wraca do znaków ANSI i nie jest też UTF-8; tzn. jeśli masz nazwę pliku z szerokim znakiem na ścieżce, jest ona konwertowana na wąskie „?” postać.

Najwyraźniej nie jest zainteresowany naprawieniem go z MSFT, ponieważ tak było od jakiegoś czasu i mam wszystkie aktualizacje.

Naprawiłem moje nieczytelne pliki dziennika Robocopy w formacie Unicode w systemie Windows (które zostały przypadkowo utworzone przez dołączenie normalnego wyjścia Robocopy do wyjścia Unicode z pliku wyjściowego w programie PowerShell) w następujący sposób:

W 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

Powyższy kod może nie działać dla wszystkich rozmiarów plików!

(Kredyt na kod: Dostosowałem kod z tego postu przez Ferdinanda Prantla: Stackoverflow - Odczytywanie / Parsowanie plików binarnych za pomocą programu PowerShell

Użyj strony kodowej UTF-8, a następnie uruchom konwerter winword

Jeśli nazwy plików lub katalogów zawierają znaki Unicode, to przed wydaniem polecenia Robocopy z /unilogparametrem użyj chcp 65001polecenia. (Strona kodowa 65001 to UTF-8 .)

Po utworzeniu zniekształconego dziennika Unicode po prostu otwórz go w MS Word jako Unicode (UTF-8)i zapisz:

W twoim przypadku polecenie w programie Powershell wygląda mniej więcej tak:

robocopy C:\mysource D:\mydest /mir | Out-File backup.log

Obejściem tego problemu jest użycie Out-File zamiast parametru wbudowanego / unilog. Otrzymasz dokładnie ten sam plik dziennika, ale teraz zostanie poprawnie zapisany w standardzie Unicode.

Uruchom chcppolecenie przed poleceniem robocopy, używając właściwej strony kodowej.

dla UTF-8 (nie działa z robocopy i hebrajskim i może więcej językami):

chcp 65001 | Out-Null

dla hebrajskiego:

chcp 1255 | Out-Null 

Pełna lista stron kodowych: https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers