¿Cómo puedo abrir archivos que contienen acentos en Java?

Question

(edición de aclaración y adición de un código)

Hola, Tenemos un requisito para analizar los datos enviados por los usuarios en todo el mundo. Nuestros sistemas Linux tienen una configuración regional predeterminada en_US.UTF-8. Sin embargo, a menudo recibimos archivos con marcas diacríticas en sus nombres como "special_á_ã_è_characters.doc". Aunque el sistema operativo puede tratar bien estos archivos, y una cadena muestra que el sistema operativo transfiere el nombre de archivo correcto al programa Java, Java ordena los nombres y lanza una excepción de "archivo no encontrado" para tratar de abrirlos.

Este sencillo programa puede ilustrar el tema:

import java.io.*; 
import java.text.*; 

public class load_i18n 
{ 
    public static void main(String [] args) { 
    File actual = new File("."); 
    for(File f : actual.listFiles()){ 
     System.out.println(f.getName()); 
    } 
    } 
} 

La ejecución de este programa en un directorio que contiene el archivo special_á_ã_è_characters.doc y el valor predeterminado de EE.UU. Inglés locale da:

special_�_�_�_characters.doc

Configuración del idioma a través de la exportación LANG = es_ES @ UTF-8 imprime el nombre de archivo correctamente (pero es una solución inaceptable ya que todo el sistema se está ejecutando en español). Establecer explícitamente la configuración regional el programa como el siguiente tampoco tiene ningún efecto. A continuación he modificado el programa para a) intente abrir el archivo y b) imprimir el nombre en ASCII y como una matriz de bytes cuando no puede abrir el archivo:

import java.io.*; 
import java.util.Locale; 
import java.text.*; 

public class load_i18n 
{ 
    public static void main(String [] args) { 
    // Stream to read file 
    FileInputStream fin; 

    Locale locale = new Locale("es", "ES"); 
    Locale.setDefault(locale); 
    File actual = new File("."); 
    System.out.println(Locale.getDefault()); 
    for(File f : actual.listFiles()){ 
     try { 
     fin = new FileInputStream (f.getName()); 
     } 
     catch (IOException e){ 
     System.err.println ("Can't open the file " + f.getName() + ". Printing as byte array."); 
     byte[] textArray = f.getName().getBytes(); 
     for(byte b: textArray){ 
      System.err.print(b + " "); 
     } 
     System.err.println(); 
     System.exit(-1); 
     } 

     System.out.println(f.getName()); 
    } 
    } 
} 

Esto produce la salida

es_ES 
load_i18n.class 
Can't open the file special_�_�_�_characters.doc. Printing as byte array. 
115 112 101 99 105 97 108 95 -17 -65 -67 95 -17 -65 -67 95 -17 -65 -67 95 99 104 97 114 97 99 116 101 114 115 46 100 111 99 

Esto muestra que el problema NO es solo un problema con la visualización de la consola, ya que los mismos caracteres y sus representaciones se envían en bytes o en formato ASCII. De hecho, pantalla de la consola funciona incluso cuando se utiliza LANG = en_US.UTF-8 para algunas utilidades como eco de fiesta:

[mjuric@arrhchadm30 tmp]$ echo $LANG 
en_US.UTF-8 
[mjuric@arrhchadm30 tmp]$ echo * 
load_i18n.class special_á_ã_è_characters.doc 
[mjuric@arrhchadm30 tmp]$ ls 
load_i18n.class special_?_?_?_characters.doc 
[mjuric@arrhchadm30 tmp]$ 

¿Es posible modificar este código de tal manera que cuando se ejecuta en Linux con LANG = en_US.UTF-8, lee el nombre del archivo de tal manera que se puede abrir con éxito?

Answer 1

La propiedad del sistema Java file.encoding debe coincidir con la codificación de caracteres de la consola. La propiedad se debe establecer cuando se inicia java en la línea de comandos:

java -Dfile.encoding=UTF-8 … 

Normalmente esto ocurre de forma automática, ya que la codificación de la consola suele ser la plataforma de codificación por defecto, y Java utilizará la codificación predeterminada plataforma si no lo hace especifica uno explícitamente

Answer 2

En primer lugar, la codificación de caracteres utilizada no está directamente relacionada con la configuración regional. Así que cambiar la configuración regional no ayudará mucho.

En segundo lugar, el � es típico para el Unicode replacement character U+FFFD� impreso en ISO-8859-1 en lugar de UTF-8. Aquí hay una evidencia:

System.out.println(new String("�".getBytes("UTF-8"), "ISO-8859-1")); // � 

Así que hay dos problemas:

1. Su JVM está leyendo esos caracteres especiales como �.
2. Su consola está utilizando ISO-8859-1 para mostrar los caracteres.

Para una JVM de Sun, el argumento de VM -Dfile.encoding=UTF-8 debería solucionar el primer problema. El segundo problema se debe solucionar en la configuración de la consola. Si está utilizando, por ejemplo, Eclipse, puede cambiarlo en Ventana> Preferencias> General> Espacio de trabajo> Codificación de archivo de texto. Configúrelo en UTF-8 también.

---

actualización: Según su actualización

byte[] textArray = f.getName().getBytes(); 

que debería haber sido el siguiente excluir la influencia de codificación predeterminado de la plataforma:

byte[] textArray = f.getName().getBytes("UTF-8"); 

Si eso sigue mostrando la misma , entonces el problema es más profundo. ¿Qué JVM exactamente estás usando? Haz un java -version. Como se dijo anteriormente, el argumento -Dfile.encoding es específico de Sun JVM. Algunas máquinas Linux se envían con JVM de GNU o JVM de OpenJDK y este argumento puede no funcionar.

Answer 3

Es un error en JRE/JDK que existe desde hace años.

How to fix java when if refused to open a file with special charater in filename?

File.exists() fails with unicode characters in name

estoy ahora volver a presentar un nuevo informe de error a ellos como LC_ALL = en_US va a arreglar algunos casos, por su parte se producirá un error algunos otros casos.

Answer 4

Bueno, ¡estuve estrangulado con este problema todo el día! Mi (mal) código anterior era el mismo que usted:

for(File f : dir.listFiles()) { 
String filename = f.getName(); // The filename here is wrong ! 
FileInputStream fis = new FileInputStream (filename); 
} 

y no funciona (estoy usando Java 1.7 Oracle en CentOS 6, LANG y LC_CTYPE = fr_FR.UTF-8 para todos los usuarios excepto zimbra => LANG y LC_CTYPE = C - que por cierto es la causa de este problema, pero no puedo cambiar esto sin el riesgo de que Zimbra deje de funcionar ...)

Así que decidí usar las nuevas clases de Java Paquete .nio.file (Archivos y rutas):

DirectoryStream<Path> paths = Files.newDirectoryStream(Paths.get(outputName)); 
for (Iterator<Path> iterator = paths.iterator(); iterator.hasNext();) { 
    Path path = iterator.next(); 
    String filename = path.getFileName().toString(); // The filename here is correct 
    ... 
} 

Si está utilizando Java 1.7 , deberías probar nuevas clases en el paquete java.nio.file: ¡me salvó el día!

creo que sirve

Answer 5

En el uso DirectoryStream entonces no se olvide de cerrar la secuencia (Try-con-recursos puede ayudar aquí)

Answer 6

Se trata de un error en la vieja escuela de Java API de archivos, tal vez solo en un mac? De todos modos, la nueva API java.nio funciona mucho mejor. Tengo varios archivos que contienen caracteres Unicode que no se pudieron cargar usando clases java.io ... Después de convertir todo mi código para usar java.nio.Path TODO comenzó a funcionar. Y reemplacé Apache FileUtils (que tiene el mismo problema) con java.nio.Files ...