Comment décompresser correctement une archive ZIP de fichiers avec des noms hébreux?

Quelqu'un m'a envoyé un fichier ZIP contenant des fichiers avec des noms hébreux (et créé sur Windows, je ne sais pas avec quel outil). J'utilise LXDE sur Debian Stretch. Le gestionnaire d'archives Gnome parvient à décompresser le fichier, mais les caractères hébreux sont tronqués. Je pense que j'obtiens des octets UTF-8 étendus en caractères Unicode, par exemple j'ai un fichier dont le nom a quatre caractères et un suffixe .doc, et les caractères sont: 0x008E 0x0087 0x008E 0x0085. L'utilisation de l'utilitaire de décompression en ligne de commande est encore pire - il refuse de décompresser complètement, se plaignant d'un "caractère multi-octets ou large non valide ou incomplet".

Donc, mes questions sont:

• Existe-t-il un autre utilitaire de décompression qui décompressera mes fichiers avec les noms corrects?
• Y a-t-il un problème avec la façon dont le fichier a été compressé, ou s'agit-il simplement d'une incompatibilité des implémentations ZIP? Ou même une anomalie / bogue des utilitaires Linux ZIP?
• Que puis-je faire pour obtenir les noms de fichiers corrects après avoir décompressé en utilisant les noms tronqués?

Il semble que les noms de fichiers soient encodés dans l'une des pages de codes propriétaires de Windows ( CP862 , 1255 , etc.).

• Existe-t-il un autre utilitaire de décompression qui décompressera mes fichiers avec les noms corrects? Je ne connais pas d'utilitaire zip qui prend en charge ces pages de codes de manière native. 7z a une certaine compréhension des encodages, mais je pense que ce doit être un encodage que votre système connaît plus généralement (vous le choisissez en définissant la LANGvariable d'environnement) et les pages de codes Windows ne font probablement pas partie de ceux-ci.

  unzip -UUdevrait fonctionner à partir de la ligne de commande pour créer des fichiers avec les octets corrects dans leurs noms (en désactivant toute la prise en charge Unicode). C'est probablement l'effet que vous avez déjà obtenu de l'outil GNOME. L'encodage ne sera pas correct de toute façon, mais nous pouvons corriger cela ci-dessous.

• Y a-t-il un problème avec la façon dont le fichier a été compressé, ou s'agit-il simplement d'une incompatibilité des implémentations ZIP? Ou même une anomalie / bogue des utilitaires Linux ZIP? Le fichier qui vous a été remis n'a pas été créé de manière portable. Ce n'est pas nécessairement faux pour une utilisation interne où l'encodage est fixe et connu à l'avance, bien que la spécification de format indique que les noms sont censés être UTF-8 ou cp437 et que les vôtres ne le sont pas non plus. Même entre les machines Windows, l'utilisation de pages de codes différentes ne fonctionne pas bien, mais les machines non Windows n'ont pas de concept de ces pages de code pour commencer. La plupart des outils UTF-8 codent leurs noms de fichiers (ce qui n'est pas toujours suffisant pour éviter les problèmes).

• Que puis-je faire pour obtenir les noms de fichiers corrects après avoir décompressé en utilisant les noms tronqués? Si vous pouvez identifier l'encodage des noms de fichiers, vous pouvez convertir les octets des noms existants en UTF-8 et déplacer les fichiers existants vers le bon nom. L' convmvoutil enveloppe essentiellement ce processus en une seule commande: convmv -f cp862 -t utf8 -r .essaiera de tout convertir à l'intérieur .de cp862 en UTF-8.

  Vous pouvez également utiliser iconvet findpour tout déplacer vers leurs noms corrects. Quelque chose comme:

  find -mindepth 1 -exec sh -c 'mv "$1" "$(echo "$1" | iconv -f cp862 -t utf8)"' sh {} \;
  

  trouvera tous les fichiers sous le répertoire courant et essaiera de convertir les noms en UTF-8.

  Dans les deux cas, vous pouvez expérimenter différents encodages et essayer de trouver celui qui a du sens.

Après avoir corrigé l'encodage pour vous, si vous souhaitez renvoyer ces fichiers dans l'autre sens, il est possible que vous ayez le même problème à l'autre extrémité. Dans ce cas, vous pouvez inverser le processus avant de compresser les fichiers -UU, car il sera probablement très difficile à corriger du côté de Windows.

J'ai eu du succès avec la commande 7z x <source.zip> .

Version:

p7zip Version 16.02 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,[...])

Environnement potentiellement pertinent:

LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
LC_CTYPE=UTF-8

Il a pu décompresser tous les fichiers avec des caractères 8 bits dans leurs noms de fichiers, certains de ces caractères étant sautés, d'autres tronqués.

Je viens d'avoir le même problème, et il s'avère que ma version de unzipcelui-ci est disponible dans les référentiels Ubuntu ( UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.) peut gérer le décodage automatique des noms de fichiers si vous spécifiez le -acommutateur.

unzip -a stupid.zip

J'ai eu un problème similaire avec le décodage d'une archive zip avec des caractères cyrilliques. Un script python d'une ligne a fait le travail correctement:

#!/usr/bin/python

import zipfile
import sys

zipfile.ZipFile(sys.argv[1], 'r').extractall(sys.argv[2] if len(sys.argv) > 2 else '.')

Ensuite, appelez-le unzip_encet appelez-leunzip_enc ZIP_FILE [TARGET_DIR]

Pour moi unzip -UU, unzip -ani LANG*les variables ni les variables d'environnement n'ont fait de bien.

J'ai eu de la chance avec cette combinaison:

export LANG=es_MX 
7z x file.zip
convmv -f cp437 -t utf8 -r .

ajoutez --notest à convmv pour le renommer réel. Plus tard, j'ai trouvé une version encore meilleure:

LANG=es_MX.cp437 unzip -UU file.zip
convmv -f cp437 -t utf8 -r . --notest

J'ai une archive zip compressée sous Linux (à partir de la ligne de commande) et les noms de fichiers avec des caractères diacritiques ne sont pas correctement décompressés sous Windows, mais je les ai décompressés avec succès avec le logiciel Bandizip qui peut définir charset sur la barre d'outils.