J'ai essayé d'obtenir robocopy dans Windows 7 pour générer un journal Unicode, car j'ai des fichiers avec des caractères Unicode. La commande que j'ai utilisée:

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

Fichier la copie fonctionne et la sortie à l'écran est correcte, le fichier journal lui-même contient juste du charabia. Cela indépendamment du fait que j'utilise l'invite de commande ou le PowerShell.

Ce qui donne? Est-ce que je fais quelque chose de mal?

Bug dans XP27. Essayez de revenir à XP26.

Il semble s'agir d'un bogue dans la XP27version de RoboCopy (fournie avec Windows 7).

Dans la version XP26(qui vient avec Windows Vista) /UNILOGproduit un fichier journal Unicode parfaitement lisible pour moi.

Si vous n'avez pas de copie de Vista, EasyRoboCopy est également livré avec la XP26version. (Je n'ai pas réellement essayé EasyRoboCopy lui-même, juste extrait robocopy.exede son fichier d'installation à l'aide de WinRAR.)

En un coup d'œil, je dirais que le fichier écrit par Robocopy lors de l'utilisation des commutateurs /UNILOGet /TEEcontient un repère d'ordre d'octets UTF-16 petit-boutien suivi d'un script typographique de terminal ISO-8859-1.

Pour le rendre lisible, j'ai fait ce qui suit dans 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

Le fichier résultant correspond à ce que j'ai vu dans l'invite de commande Windows.

Pour en savoir plus: homme dd, homme iconv, hommecol

En regardant la sortie du fichier (binaire) sur Win7, l'option / UNILOG est inutile. Il écrit la nomenclature UNICODE standard (FFFE), mais procède ensuite à l'écriture de tous les caractères étroits SAUF pour la ligne d'options (par exemple, / BYTES / S / COPY: DATS ...), qui est unicode réel. Après cela, il revient aux caractères ANSI, et ce n'est pas non plus UTF-8; c'est-à-dire, si vous avez un nom de fichier avec un caractère large dans le chemin, il est converti en un "?" étroit personnage.

Apparemment, aucun intérêt à le réparer à partir de MSFT, car il en est ainsi depuis un certain temps, et j'ai toutes les mises à jour.

J'ai corrigé mes fichiers journaux Robocopy illisibles au format Unicode dans Windows (qui ont été créés accidentellement en ajoutant la sortie Robocopy normale à la sortie Unicode de Out-File dans PowerShell), comme suit:

Dans 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

Le code ci-dessus peut ne pas fonctionner pour toutes les tailles de fichier!

(Crédit pour le code: j'ai adapté le code de cet article de Ferdinand Prantl: Stackoverflow - Lire / analyser des fichiers binaires avec PowerShell

Utilisez la page de codes UTF-8, puis exécutez le convertisseur de mots clés

Si vos noms de fichier ou de répertoire contiennent des caractères Unicode, puis avant d'exécuter la commande Robocopy avec le /unilogparamètre, utilisez la chcp 65001commande. (La page de codes 65001 est UTF-8 .)

Une fois que vous avez le journal Unicode tronqué, ouvrez-le simplement dans MS Word sous Unicode (UTF-8)et enregistrez-le:

Dans votre cas, la commande dans Powershell ressemble à ceci:

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

La solution de contournement est que vous utilisez Out-File au lieu du paramètre intégré / unilog. Vous obtiendrez exactement le même fichier journal, mais maintenant il sera correctement écrit en unicode.

Exécutez la chcpcommande avant la commande robocopy, avec la bonne page de codes.

pour UTF-8 (ne fonctionne pas avec robocopy et l'hébreu et peut-être plus de langues):

chcp 65001 | Out-Null

pour l'hébreu:

chcp 1255 | Out-Null 

Liste complète des pages de codes: https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers