Ich habe versucht, Robocopy in Windows 7 zu erstellen, um ein Unicode-Protokoll zu generieren, da ich Dateien mit Unicode-Zeichen habe. Der Befehl, den ich verwendet habe:

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

Datei die Kopie funktioniert und die Bildschirmausgabe ist korrekt, die Protokolldatei selbst enthält nur Kauderwelsch. Dies ist unabhängig davon, ob ich die Eingabeaufforderung oder die Powershell verwende.

Was gibt? Mache ich etwas falsch?

Fehler in XP27. Versuchen Sie ein Downgrade auf XP26.

Es scheint ein Fehler in der XP27Version von RoboCopy zu sein (die mit Windows 7 geliefert wird).

In der Version XP26(die mit Windows Vista geliefert wird) /UNILOGwird eine perfekt lesbare Unicode-Protokolldatei für mich erstellt.

Wenn Sie keine Kopie von Vista haben, wird EasyRoboCopy ebenfalls mit der XP26Version geliefert . (Ich habe EasyRoboCopy selbst noch nicht ausprobiert, sondern nur mit robocopy.exeaus der Setup-Datei extrahiert WinRAR.)

Auf einen Blick würde ich sagen, dass die von Robocopy während der Verwendung der Schalter /UNILOGund geschriebene Datei /TEEein UTF-16-Little-Endian-Byte-Bestellzeichen gefolgt von einem ISO-8859-1-Terminal-Typoskript enthält.

Um es lesbar zu machen, habe ich in Ubuntu Folgendes getan:

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

Die resultierende Datei entspricht dem, was ich in der Windows-Eingabeaufforderung gesehen habe.

Weiterführende Literatur: Mann dd, Mann iconv, Manncol

Bei der (binären) Dateiausgabe unter Win7 ist die Option / UNILOG nutzlos. Es schreibt die Standard-UNICODE-Stückliste (FFFE), schreibt dann aber alle schmalen Zeichen AUSSER für die Optionszeile (z. B. / BYTES / S / COPY: DATS ...), die der tatsächliche Unicode ist. Danach wird wieder auf ANSI-Zeichen zurückgegriffen, und es handelt sich auch nicht um UTF-8. Wenn Sie also einen Dateinamen mit einem breiten Zeichen im Pfad haben, wird dieser in ein schmales '?' Charakter.

Anscheinend kein Interesse daran, es von MSFT aus zu beheben, da dies schon seit einiger Zeit so ist und ich alle Updates habe.

Ich habe meine unlesbaren Robocopy-Protokolldateien im Unicode-Format in Windows (die versehentlich durch Anhängen der normalen Robocopy-Ausgabe an die Unicode-Ausgabe von Out-File in PowerShell erstellt wurden) wie folgt behoben:

In 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

Der obige Code funktioniert möglicherweise nicht für alle Dateigrößen!

(Gutschrift für Code: Ich habe den Code aus diesem Beitrag von Ferdinand Prantl angepasst: Stackoverflow - Lesen / Analysieren von Binärdateien mit PowerShell

Verwenden Sie die UTF-8-Codepage und führen Sie dann den Winword Converter aus

Wenn Ihre Datei- oder Verzeichnisnamen Unicode-Zeichen enthalten, /unilogverwenden Sie den chcp 65001Befehl, bevor Sie den Robocopy-Befehl mit dem Parameter ausgeben . (Codepage 65001 ist UTF-8 .)

Sobald Sie das verstümmelte Unicode-Protokoll haben, öffnen Sie es einfach in MS Word als Unicode (UTF-8)und speichern Sie es:

In Ihrem Fall lautet der Befehl in Powershell ungefähr so:

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

Die Problemumgehung besteht darin, dass Sie Out-File anstelle des integrierten / unilog-Parameters verwenden. Sie erhalten genau die gleiche Protokolldatei, aber jetzt wird sie ordnungsgemäß in Unicode geschrieben.

Führen Sie den chcpBefehl vor dem Robocopy-Befehl mit der richtigen Codepage aus.

für UTF-8 (funktioniert nicht mit Robocopy & Hebrew und möglicherweise mehr Sprachen):

chcp 65001 | Out-Null

für Hebräisch:

chcp 1255 | Out-Null 

Vollständige Codepage-Liste: https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers