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?
Odpowiedzi:
Błąd w XP27. Spróbuj obniżyć do XP26.
Wygląda na to, że jest to błąd w
XP27
wersji RoboCopy (która jest dostarczana z Windows 7).W wersji
XP26
(dostarczanej z Windows Vista)/UNILOG
tworzy dla mnie doskonale czytelny plik dziennika Unicode.Jeśli nie masz kopii Visty wokół EasyRoboCopy, dołączona jest również
XP26
wersja. (Właściwie nie próbowałem sam EasyRoboCopy, po prostu wyodrębniłemrobocopy.exe
go z pliku instalacyjnego za pomocąWinRAR
.)źródło
Na pierwszy rzut oka powiedziałbym, że plik napisany przez Robocopy podczas używania przełączników
/UNILOG
i/TEE
zawiera 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:
Wynikowy plik jest zgodny z tym, co zobaczyłem w wierszu polecenia systemu Windows.
Dalsza lektura: mężczyzna
dd
, mężczyznaiconv
, mężczyznacol
źródło
([System.Text.Encoding]::Unicode).GetString([System.Text.Encoding]::Convert([System.Text.Encoding]::GetEncoding(28591), [System.Text.Encoding]::Unicode, ([System.Text.Encoding]::GetEncoding(28591)).GetBytes($_)))
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.
źródło
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:
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
źródło
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
/unilog
parametrem użyjchcp 65001
polecenia. (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:źródło
W twoim przypadku polecenie w programie Powershell wygląda mniej więcej tak:
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.
źródło
Uruchom
chcp
polecenie 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):
dla hebrajskiego:
Pełna lista stron kodowych: https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers
źródło