texto - Agregue nombres de archivo que no sean ASCII para comprimir en Java

modificar archivos txt en java

Question

¿Cuál es la mejor manera de agregar nombres de archivos que no son ASCII a un archivo comprimido utilizando Java , de modo que los archivos se puedan leer correctamente tanto en Windows como en Linux?

Aquí hay un intento, adaptado de https://truezip.dev.java.net/tutorial-6.html#Example , que funciona en Windows Vista pero falla en Ubuntu Hardy. En Hardy, el nombre del archivo se muestra como abc-ЖДФ.txt en el archivo-rodillo.

import java.io.IOException;
import java.io.PrintStream;

import de.schlichtherle.io.File;
import de.schlichtherle.io.FileOutputStream;

public class Main {

    public static void main(final String[] args) throws IOException {

        try {
            PrintStream ps = new PrintStream(new FileOutputStream(
                    "outer.zip/abc-åäö.txt"));
            try {
                ps.println("The characters åäö works here though.");
            } finally {
                ps.close();
            }
        } finally {
            File.umount();
        }
    }
}

A diferencia de java.util.zip, truezip permite especificar la codificación de archivos zip. Aquí hay otra muestra, esta vez especificando explícitamente la codificación. Ni IBM437, UTF-8 ni ISO-8859-1 funcionan en Linux. IBM437 funciona en Windows.

import java.io.IOException;

import de.schlichtherle.io.FileOutputStream;
import de.schlichtherle.util.zip.ZipEntry;
import de.schlichtherle.util.zip.ZipOutputStream;

public class Main {

    public static void main(final String[] args) throws IOException {

        for (String encoding : new String[] { "IBM437", "UTF-8", "ISO-8859-1" }) {
            ZipOutputStream zipOutput = new ZipOutputStream(
                    new FileOutputStream(encoding + "-example.zip"), encoding);
            ZipEntry entry = new ZipEntry("abc-åäö.txt");
            zipOutput.putNextEntry(entry);
            zipOutput.closeEntry();
            zipOutput.close();
        }
    }
}

Answer 1

¿Realmente falló o solo fue un problema de fuente? (por ejemplo, fuente que tiene glifos diferentes para esos códigos) He visto problemas similares en Windows donde la traducción "se rompió" porque la fuente no era compatible con el juego de caracteres pero la información estaba intacta y era correcta.

Answer 2

Los nombres de archivo no ASCII no son confiables en las implementaciones ZIP y es mejor evitarlos. No hay ninguna disposición para almacenar una configuración de juego de caracteres en archivos ZIP; los clientes tienden a adivinar con ''la página de códigos del sistema actual'', que es poco probable que sea lo que usted desea. Muchas combinaciones de cliente y página de códigos pueden dar como resultado archivos inaccesibles.

¡Lo siento!

Answer 3

A partir de un vistazo rápido al manual TrueZIP, recomiendan el formato JAR:

Utiliza UTF-8 para la codificación y los comentarios de nombre de archivo, a diferencia de ZIP, que solo usa IBM437.

Esto probablemente significa que la API está usando el paquete java.util.zip para su implementación; esa documentación indica que todavía está usando un formato ZIP desde 1996 . La compatibilidad con Unicode no se agregó a la especificación de formato de archivo .ZIP de PKWARE hasta 2006.

Answer 4

La codificación para las entradas de archivo en ZIP originalmente se ha especificado como código IBM Página 437. Muchos caracteres utilizados en otros idiomas son imposibles de usar de esa manera.

La especificación PKWARE se refiere al problema y agrega un poco. Pero eso es una adición posterior (desde 2007, gracias a Cheeso por aclarar eso, ver comentarios). Si ese bit está configurado, la entrada de nombre de archivo debe estar codificada en UTF-8. Esta extensión se describe en ''APÉNDICE D - Codificación de idioma (EFS)'', que se encuentra al final del documento vinculado.

Para Java es un error conocido, tener problemas con caracteres que no sean ASCII. Ver error # 4244499 y la gran cantidad de errores relacionados.

Mi colega usó como solución URL la codificación para los nombres de los archivos antes de almacenarlos en el ZIP y decodificarlos después de leerlos. Si controla ambos, almacenando y leyendo, puede ser una solución.

EDITAR: En el error que alguien sugiere usar ZipOutputStream de Apache Ant como solución alternativa. Esta implementación permite la especificación de una codificación.

Answer 5

En los archivos Zip, de acuerdo con la especificación propiedad de PKWare, la codificación de los nombres de los archivos y los comentarios de los archivos es IBM437. En 2007 PKWare amplió la especificación para permitir también UTF-8. Esto no dice nada sobre la codificación de los archivos contenidos en el zip. Solo la codificación de los nombres de archivo.

Creo que todas las herramientas y bibliotecas (Java y no Java) son compatibles con IBM437 (que es un superconjunto de ASCII), y menos herramientas y bibliotecas admiten UTF-8. Algunas herramientas y libs son compatibles con otras páginas de códigos. Por ejemplo, si comprime algo utilizando WinRar en una computadora que se ejecuta en Shanghai, obtendrá la página de códigos Big5. Esto no está "permitido" por la especificación zip, pero sucede de todos modos.

La biblioteca DotNetZip para .NET hace Unicode, pero, por supuesto, eso no te ayuda si estás usando Java.

Al utilizar el soporte integrado de Java para ZIP, siempre obtendrá IBM437. Si desea un archivo con algo que no sea IBM437, utilice una biblioteca de terceros o cree un JAR.

Answer 6

Puede seguir utilizando la implementación Apache Commons de la ruta zip: http://commons.apache.org/compress/apidocs/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.html#setEncoding%28java.lang.String % 29

Llamar a setEncoding ("UTF-8") en tu transmisión debería ser suficiente.

Answer 7

De hecho, los milagros suceden, y Sun / Oracle realmente arreglaron el bug / rfe de larga duración:

Ahora es posible configurar las codificaciones de nombre de archivo al crear el archivo zip / stream ( requiere Java 7 ).