Problema de codificación en Java

Tengo un archivo CSV que contiene los dos caracteres ASCII & Unicode. diga "ÅÔÉA". No estoy seguro del formato de codificación de este archivo, pero cuando lo abro en el Bloc de notas, muestra "ANSI" como su estándar de codificación.Problema de codificación en Java

Traigo estos contenidos de CSV en formato UTF-8 codificado.

fr = new InputStreamReader (new FileInputStream (fileName), "UTF-8");

pero cuando lo almaceno en DB estos caracteres especiales, excepto "A", no se almacenan correctamente. los personajes se codifican

Deseo que todos los caracteres se almacenen correctamente. ¿Alguna idea?

Fuente

2009-06-23 user127377

Compruebe el archivo con un editor/volcador hexadecimal ver qué bytes representan realmente esos caracteres no ASCII. – laalto

¿Su campo de base de datos es compatible con Unicode? En MSSQL, el tipo de campo debe ser nvarchar sobre varchar. ¿Qué base de datos estas usando?

Fuente

2009-06-23 06:28:10 Sam

"ANSI" en "Bloc de notas" significa cualquier página de códigos que esté usando su Windows. Pruebe ISO8859-1, funciona en la mayoría de los casos.

Fuente

2009-06-23 06:42:04

Sugiero crear un pequeño programa que lea del archivo, e imprima el valor unicode de los caracteres leídos, para que pueda asegurarse de que los valores que se muestran son correctos. Hay gráficos de códigos disponibles en http://www.unicode.org/charts/; probablemente pueda hacer con los gráficos básicos en latín y en latín-1.

Supongo que la codificación es la codificación nativa de Windows. Entonces puede evitar por completo el parámetro "UTF-8" y dejar que Java use la codificación de plataforma predeterminada.

Fuente

2009-06-23 06:42:34

Tuve este problema. Se necesitan dos cosas: columnas NVARCHAR2 y una llamada de método específico de Oracle en el PreparedStatement para notificar oráculo acerca de la serie de codificación:

/** 
* Sets a statement parameter as NCHAR. Use before setting the field value. 
* @param pstmt the prepared statement 
* @param index the parameter index 
*/ 
public static void setNChar(PreparedStatement pstmt, int index) { 
    OraclePreparedStatement opstmt = (OraclePreparedStatement)pstmt; 
    opstmt.setFormOfUse(index, OraclePreparedStatement.FORM_NCHAR); 
}

Si utiliza cadena SQL llano con caracteres Unicode, que funciona como Oracle recibe todos los comandos SQL en UTF-8: el controlador traduce automáticamente. Sin embargo, para el uso de declaraciones preparadas, debe indicarlo explícitamente al oráculo.

También puede probar PreparedStatement.setNString() si ejecuta Java 6 y tiene el controlador ojdbc6. (En mi caso tuvimos que usar Java 5 con el controlador de la versión 4 - no preguntes por qué)

(Nota: Sé que este es el bloqueo del proveedor ya que estás obligado a usar clases de Oracle concretas en lugar de las interfaces jdbc)

Fuente

2009-06-23 07:13:22 akarnokd

Antes que nada, debe conocer la codificación del archivo. Ábrelo con un editor hexadecimal. ¿Cuántos bytes ocupa un personaje? Si es solo uno, entonces el archivo no está en UTF-8, sino más bien en algunos ISO-8859 o una codificación de Windows similar (por ejemplo, Win-1252). Como se mencionó anteriormente, es probable que ISO-8859-1 sea la codificación correcta. Para los idiomas de Europa del Este, ISO-8859-2 sería la elección correcta. El segundo problema sería el conjunto de caracteres que admite su base de datos para columnas de caracteres (este parámetro se establece durante la instalación/creación de una nueva instancia) pero dado que puede insertar esos caracteres directamente, no será un problema en ese caso.

¿Qué controlador jdbc usas? El controlador delgado no debería crear ningún problema en ese sentido, mientras que el controlador OCI podría crear una capa adicional de problemas si la configuración NLS_LANG del cliente no coincide con la codificación de caracteres de la base de datos.

Fuente

2009-06-23 07:44:31

Creo que Oracle 10g le permite usar UTF-8 o UTF-16 para el formato de almacenamiento de columnas del conjunto de caracteres nacional. Por defecto es UTF-16. – akarnokd

kd304: también puede especificar UTF-8 como el conjunto de caracteres para las columnas CHAR (VARCHAR, VARCHAR2), por lo que cada cadena en la base de datos es UTF8. –

Debe codificar eso en ISO 8859-1 y no en UTF-8.

Fuente

2009-06-23 08:08:37

Si él/ella recibe datos en UTF-8 ¿por qué debería él/ella transcodificarlo en un formato menor? Oracle es bastante capaz de manejar texto unicode. – akarnokd

Puede comparar manualmente un volcado hexadecimal de salidas de caracteres con varias codificaciones (sample code), aunque esto puede ser un proceso laborioso. Alternativamente, puede usar la biblioteca ICU para intentar usar determine the encoding, aunque este no es un método infalible.

¿Cómo se produjo el archivo CSV? Si fue creado por una aplicación de Windows en un sistema operativo en inglés, entonces es probable que la codificación sea windows-1252 (canonical name "Cp1252" in Java); en un sistema polaco, podría ser windows-1250. El mejor enfoque es averiguar con certeza en qué codificación se guardó el archivo.

Fuente

2009-06-23 08:58:39 McDowell

Buena idea. Puede usar la función DUMP() de Oracle para ver cómo se almacena una cadena en la columna byte por byte y compararla con la secuencia de bytes del archivo original. – akarnokd

Lo primero que debe hacer es un System.out.println() de la cadena después de haberla cargado desde el archivo. Si está dañado en la consola, su archivo no es realmente UTF-8, si se ve bien tiene un problema con la forma en que lo está guardando en la base de datos :)

Fuente

2009-06-23 12:07:27 Spyder

Problema de codificación en Java

Respuesta

Cuestiones relacionadas