Używanie znaków Unicode w nazwach plików wewnątrz archiwum zip

Question

ja skompresowanie nazwę pliku zawiera kilka znaków specjalnych, takich jak Péréquation LES Hopitaux NEUFS.xls do innego folderu, powiedzmy temp.

jestem w stanie spakować plik, ale problemem jest to nazwa pliku zmienia się automatycznie do P + ¬R + ¬quation LES HOPITAUX NEUFS.xls.

Jak mogę obsługiwać znaki Unicode dla nazw plików w archiwum zip?

Answer 1

To zależy trochę od tego, jakiego kodu używasz do utworzenia archiwum. Stare klasy kompresji Java nie są tak elastyczne, jak tego potrzebujesz. Możesz użyć Apache Commons Compress. Michael Simons napisał ten piękny kawałek kodu:

ZipArchiveOutputStream ostream = ...; // Your initialization code here 
ostream.setEncoding("Cp437"); // This should handle your "special" characters 
ostream.setFallbackToUTF8(true); // For "unknown" characters! 
ostream.setUseLanguageEncodingFlag(true);        
ostream.setCreateUnicodeExtraFields(
    ZipArchiveOutputStream.UnicodeExtraFieldPolicy.NOT_ENCODEABLE); 

Jeśli używasz Java 7 wtedy wreszcie mieć parametr Charset (które mogą być UTF-8) na ZipOutputStream constructor

duży problem, w każdym razie, jest to, że wiele implementacji nie rozumie kodowania Unicode, ponieważ oryginalny plik ZIP w formacie ma format ASCII i nie ma oficjalnego standardu dla Unicode. Aby uzyskać więcej informacji, patrz this post.

Answer 2

Specyfikacja Zip (historycznie) nie określa, jakie kodowanie znaków ma być stosowane w przypadku nazw i komentarzy osadzonych plików, pierwotny zestaw kodowania znaków IBM PC, zwany powszechnie kodem IBM Page 437, powinien być jedynym kodowanie obsługiwane. Specyfikacja Jar w międzyczasie jawnie określa użycie UTF-8 jako kodowania do kodowania i dekodowania wszystkich nazw plików i komentarzy w plikach Jar. Nasza implementacja java.util.jar i java.util.zip ściśle przestrzegała specyfikacji Jar, aby używać UTF-8 jako jedynego kodowania, gdy mamy do czynienia z nazwami plików i komentarzami przechowywanymi w plikach Jar/Zip.

Konsekwencja? plik ZIP utworzony przez "tradycyjne" narzędzie ZIP jest niedostępny dla narzędzia java.util.jar/zip i na odwrót, jeśli nazwa pliku zawiera znaki, które nie są kompatybilne z Cp437 (alternatywnie, narzędzia mogą po prostu użyć domyślne kodowanie platformy) i UTF-8

Dla większości Europejczyków, jesteś "szczęśliwy" :-), że musisz tylko unikać "garści" postaci, takich jak umlauty (OK, ja tylko żartuję), ale dla Japończyków i Chińczyków większość postaci ma po prostu pecha. Właśnie dlatego błąd nr 4244499 był numerem jeden wśród 25 błędów Java od tylu lat. Błąd nie jest już na liście :-) został ostatecznie "naprawiony" w OpenJDK 7, b57. Wciąż przechowuję migawkę jako rekord/kudo dla siebie :-)

Rozwiązaniem (użyłbym "rozwiązania" niż "fix") w JDK7 b57 jest wprowadzenie w nowym zestawie konstruktorów ZipOputStream ZipOutStream i ZipFile z określonym "zestawem znaków" jako parametrem, jak pokazano poniżej.

zipfile (File, Kodowanie)

ZipInputStream (InputStream, Kodowanie)

ZipOutputStream (OutputStream, Kodowanie)

Z tych nowych konstruktorów, aplikacje mogą teraz uzyskać dostęp do tych pliki ZIP w formacie innym niż UTF-8 za pomocą obiektów ZipInputStream lub ZipFile utworzonych za pomocą określonego kodowania lub utwórz pliki Zip zakodowane w formacie innym niż UTF-8 za pośrednictwem nowego ZipOutputStream (os, c harset) konstruktor, jeśli to konieczne.

zip to uproszczona wersja narzędzia Jar z opcją "-encoding" wspierającą kodowanie inne niż UTF8 dla nazwy wpisu i komentarza, może służyć jako wersja demonstracyjna do korzystania z nowych interfejsów API (użyłem to jako test jednostkowy). Nadal debatuję ze sobą, jeśli dobrze jest oficjalnie wprowadzić "kodowanie" w narzędziu Jar ...