Décompressez les fichiers créés avec WinZIP avec les noms de fichiers I18N?

Question

De nos jours, les gens créent leurs archives ZIP avec WinZIP, ce qui permet des noms de fichiers internationalisés (c'est-à-dire non-latin: cyrillique, grec, chinois, vous l'appelez). Malheureusement, essayer de déballer un tel fichier provoque des problèmes: Unix unzip crée des fichiers et des répertoires nommés "garbage-name" comme "® £ ¤ © ¤ ¥ èì". Java et sa commande jar échoue lamentablement sur de telles archives.

Existe-t-il une manière passable de déballer de tels fichiers par programme? UNIX ou Java.

Answer 1

La solution que j'ai trouvée: Apache commons-compress peut décompresser de telles archives si elles sont fournies avec le jeu de caractères correct.

Answer 2

DotNetZip prend en charge les codages Unicode et arbitraires pour les noms de fichiers dans les fichiers zip, que ce soit pour lire ou écrire des zips.

C'est une bibliothèque .NET. Pour l'utilisation d'Unix, vous auriez besoin de Mono comme pré-requis. Si le fichier zip est correctement construit par WinZip, c'est-à-dire s'il est compatible avec the zip spec from PKWare, alors il n'y a pas de travail spécial à faire pour spécifier le codage au moment où vous le décompactez. Selon la spécification zip, il existe deux encodages pris en charge pour les noms de fichiers dans les fichiers zip: UTF-8 et IBM437. L'utilisation de l'un ou l'autre de ces codages est spécifiée dans les métadonnées zip et n'importe quelle bibliothèque zip peut le détecter et l'utiliser. DotNetZip le détecte automatiquement lors de la lecture d'un zip compatible. comme ceci:

using (var zip = ZipFile.Read("thearchive.zip")) 
{ 
    foreach (var e in zip) 
    { 
     // e.FileName refers to the name on the entry 
     e.Extract("extract-directory"); 
    } 
} 

Il existe des programmes d'archives qui produisent des fermetures éclair qui sont w.r.t. « non conformes » codage. WinRar est un - il va créer un zip qui a des noms de fichiers codés dans l'encodage par défaut en cours d'utilisation sur l'ordinateur. A Shanghai, il utilisera cp950, tandis qu'en Islande, autre chose, et à Lisbonne, autre chose. L'avantage de "non-conformité" ici est que Windows Explorer ouvrira et affichera correctement les noms de fichiers i18n-ized dans ces zips. En d'autres termes, "non-conformité" est souvent ce que les gens veulent, parce que Windows ne prend pas (encore?) En charge les fichiers zip UTF-8.

(Tout cela a à voir avec le codage utilisé dans le fichier zip, pas le codage utilisé dans les fichiers contenus dans le fichier zip)

La spécification zip ne permet pas la spécification d'un codage de texte arbitraire dans les métadonnées zip. En d'autres termes, si vous utilisez cp950 lors de la création du zip, votre logique d'extraction doit "savoir" utiliser cp950 lors de l'extraction - rien dans le fichier zip ne porte cette information. En outre, bien sûr, la bibliothèque zip que vous utilisez pour extraire par programmation doit prendre en charge des codages arbitraires. Pour autant que je sache, la bibliothèque zip de Java ne fonctionne pas. DotNetZip fait. Comme si:

using (ZipFile zip = ZipFile.Read(zipToExtract, 
            System.Text.Encoding.GetEncoding(950))) 
{ 
    foreach (ZipEntry e in zip) 
    { 
    e.Extract(extractDirectory); 
    } 
} 

DotNetZip peut également créer des fichiers zip avec codages arbitraires - fermetures éclair "non conformes".

DotNetZip est gratuit et open source.