Cela se produit parce que certains outils Windows utilisent apparemment des barres obliques inverses (\ ) comme séparateurs où ils doivent utiliser des barres obliques (/ ). La barre oblique inverse sous Unix peut faire partie du nom de fichier ou de répertoire.
La spécification du format de fichier .ZIP (version 6.3.5 au moment où j'écris ceci, révisée le 20 novembre 2018) indique :
4.4.17.1 Le nom du fichier, avec chemin relatif facultatif. Le chemin stocké NE DOIT PAS contenir de lettre de lecteur ou de périphérique, ni de barre oblique. Toutes les barres obliques DOIVENT être des barres obliques
/par opposition aux barres obliques inversées\pour la compatibilité avec les systèmes de fichiers Amiga et UNIX, etc. Si l'entrée provient de l'entrée standard, il n'y a pas de champ de nom de fichier.
Ce fichier est mentionné par Microsoft dans un document Mitigation :ZipArchiveEntry.FullName Séparateur de chemin :
À partir des applications qui ciblent le .NET Framework 4.6.1, le séparateur de chemin utilisé dans le
ZipArchiveEntry.FullNamepropriété a changé à partir de la barre oblique inverse (\) utilisé dans les versions précédentes du .NET Framework par une barre oblique (/). [...]Incidence
La modification met l'implémentation de .NET en conformité avec la section 4.4.17.1 de la spécification du format de fichier .ZIP et permet de décompresser les archives .ZIP sur des systèmes autres que Windows.
La décompression d'un fichier zip créé par une application qui cible une version précédente du .NET Framework sur des systèmes d'exploitation autres que Windows tels que Macintosh ne permet pas de conserver la structure de répertoires. Par exemple, sur le Macintosh, il crée un ensemble de fichiers dont le nom de fichier concatène le chemin du répertoire, ainsi que toute barre oblique inverse (
\) et le nom du fichier. Par conséquent, la structure des répertoires des fichiers décompressés n'est pas conservée.
Notez que le problème peut exister si l'archiveur a utilisé une ancienne version de .NET Framework ou s'il ne l'a pas du tout utilisé mais a implémenté sa propre approche (indépendante) des fichiers zip.
On peut rencontrer le même problème avec rar :Unrar crée des fichiers avec des barres obliques inverses dans les noms au lieu de la hiérarchie de répertoires appropriée.
Vous pouvez trouver cette question sur Unix &Linux SE utile :Convertir un ZIP créé par Windows en Linux (problème de chemins internes). Mon approche (quelque peu expérimentale) est dans cette réponse.
Il s'agit en fait d'un bogue dans Microsoft.PowerShell.Archive :
https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/48
...qui sera résolu dans ce PR, prévu pour la version 1.2.3 :
https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/62
En attendant, voici une solution rapide (crédit) :
for file in *\\*; do target="${file//\\//}"; mkdir -p "${target%/*}"; mv -v "$file" "$target"; done