web-dev-qa-db-fra.com

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. I pensez J'obtiens des octets UTF-8 étendus en caractères Unicode, par ex. 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?
character-encodingzipunicodefile-format
19
einpoklum

Il semble que les noms de fichiers soient codé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 qu'il doit s'agir d'un encodage que votre système connaît plus généralement (vous le choisissez en définissant la variable d'environnement LANG) et les pages de codes Windows ne font probablement pas partie de ceux-ci.

    unzip -UU devrait fonctionner à partir de la ligne de commande pour créer des fichiers avec les bons octets 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é donné 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 le vôtre ne l'est ni l'un ni l'autre. Même entre les machines Windows, l'utilisation de différentes pages de code 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 dans les noms existants dans UTF-8 et déplacez les fichiers existants vers le bon nom. L'outil convmv enveloppe essentiellement ce processus dans une seule commande: convmv -f cp862 -t utf8 -r . va essayer de tout convertir à l'intérieur . de cp862 à UTF-8.

    Vous pouvez également utiliser iconv et find pour déplacer tout 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 avec -UU, car il sera probablement très difficile à corriger du côté de Windows.

17
Michael Homer

J'ai réussi 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 contenant des caractères 8 bits dans leurs noms de fichiers, certains de ces caractères étant ignorés, d'autres tronqués.

8
vszakats

Je viens d'avoir le même problème, et il s'avère que ma version de unzip qui est disponible à partir des 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 -a commutateur.

unzip -a stupid.Zip
6
Igor Zinov'yev

J'ai eu de la chance avec cette combinaison:

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

ajoutez --notes à convmv pour un changement de nom 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
2
asdjfiasd

J'ai eu un problème similaire avec le décodage d'une archive Zip avec des caractères cyrilliques. Un script d'une ligne python 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 '.')

Appelez-le simplement unzip_enc et appelez-le unzip_enc Zip_FILE [TARGET_DIR]

Pour moi, ni le unzip -UU, unzip -a ni LANG* les variables d'environnement ont fait du bien.

2
Iskren Ivov Chernev

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.

0
Miro Junker