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

Question

Les gens ces jours-ci créent leurs archives ZIP avec Winzip, qui permet internationalisé (à savoir non-latin: cyrillique, grec, chinois, vous nommez) les noms de fichier

.

Malheureusement, en essayant de décompresser ce fichier provoque des problèmes: Décompressez UNIX crée les fichiers nommés garbage-et dirs comme "® £ ¤ © ¤ ¥ Ei". Java et sa commande jar échoue lamentablement sur ces archives.

est-il un moyen passable pour décompresser ces fichiers par programme? UNIX ou Java.

Answer 1

La solution que j'ai trouvé: commons-Apache peut compress décompressez ces archives très bien, si elles sont fournies avec charset correct fallback.

Answer 2

DotNetZip supporte unicode et codages arbitraires pour les noms de fichiers au sein de zipfiles, soit pour des fermetures à glissière de lecture ou d'écriture.

Il est une bibliothèque .NET. Pour un usage Unix, vous devez Mono comme une condition préalable.

Si le fichier zip est construit correctement par WinZip, autrement dit si elle est conforme aux la spec zip à partir PKWare, alors il n'y a pas de travail spécial que vous devez faire pour spécifier l'encodage au moment où vous déballez. Selon la spécification zip, il y a deux codages pris en charge des noms de fichiers dans zipfiles: UTF-8 et IBM437. L'utilisation de l'un ou l'autre de ces codages est spécifié dans les métadonnées zip et une bibliothèque zip peut détecter et l'utiliser. DotNetZip détecte automatiquement lors de la lecture d'une fermeture à glissière conforme. 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 crée un fichier zip qui a codé les noms de fichiers dans le codage par défaut utilisé sur l'ordinateur. A Shanghai, il utilisera cp950, alors qu'en Islande, quelque chose d'autre, et à Lisbonne, quelque chose d'autre. L'avantage de « non conformité » est ici que Windows Explorer ouvrir et afficher correctement les noms de fichiers i18n-isée dans de telles fermetures éclair. En d'autres termes, « non conformité » est souvent ce que les gens veulent, parce que Windows n'a pas (encore?) Support des 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'extrait doit « savoir » à utiliser lors de l'extraction cp950 - rien dans le fichier zip porte cette information. En outre, bien sûr, la bibliothèque zip que vous utilisez pour extraire programme doit prendre en charge les codages arbitraires. Pour autant que je sache, la bibliothèque zip de Java ne fonctionne pas. DotNetZip fait. Comme ceci:

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 à glissière « non conformes ».

DotNetZip est libre et open source.