java - acentos - Codificación UTF-8; Solo algunos caracteres japoneses no se están convirtiendo

java acentos utf-8

Question

Obtengo el parámetro value como parámetro del Jersey Web Service , que está en caracteres japoneses.

Aquí, ''japaneseString'' es el parámetro del servicio web que contiene los caracteres en idioma japonés.

   String name = new String(japaneseString.getBytes(), "UTF-8");

Sin embargo, puedo convertir algunos literales de picadura con éxito, mientras que algunos de ellos crean problemas.

Los siguientes fueron convertidos exitosamente:

 1) アップル
 2) 赤
 3) 世丕且且世两上与丑万丣丕且丗丕
 4) 世世丗丈

Mientras que estos no:

 1) ひほわれよう
 2) 存在する

Cuando investigué más, descubrí que estas 2 cadenas se están convirtiendo en algunos caracteres JUNK.

 1) Input: ひほわれよう        Output : �?��?��?れよ�?�
 2) Input: 存在する            Output: 存在�?�る

¿Alguna idea de por qué algunos de los caracteres japoneses no se convierten correctamente?

Gracias.

Answer 1

Estás mezclando conceptos aquí.

Una String es solo una secuencia de caracteres ( char s); una String en sí misma no tiene codificación en absoluto . Por lo que vale, reemplaza los characters de arriba con carrier pigeons . La misma cosa. Una paloma mensajera no tiene codificación. Tampoco lo hace un char . (1)

Lo que estás haciendo aquí:

new String(x.getBytes(), "UTF-8")

es un "proceso de codificación / descodificación de un hombre pobre". Probablemente habrás notado que hay dos versiones de .getBytes() : una donde pasas un juego de caracteres como argumento y el otro donde no.

Si no lo hace, y eso es lo que sucede aquí, significa que obtendrá el resultado del proceso de codificación utilizando su juego de caracteres predeterminado ; y luego intenta volver a decodificar esta secuencia de bytes usando UTF-8.

No hagas eso. Solo toma la cuerda como viene. Sin embargo, si tiene problemas para leer la secuencia de bytes original en una cadena, significa que utiliza un Reader con el juego de caracteres incorrecto. Arregla esa parte

Para más información, lea este enlace .

(1) el hecho de que, de hecho, un char sea ​​una unidad de código UTF-16 es irrelevante para esta discusión

Answer 2

Estoy de acuerdo con @fge.

Aclaración

En el texto java String/char/Reader/Writer handle (Unicode), y puede combinar todos los scripts del mundo.

Y byte[]/InputStream/OutputStream son datos binarios, que necesitan una indicación de alguna codificación para convertirse a String.

En su caso japaneseStingr ya debería ser un String correcto, o debería ser sustituido por el byte[] original byte[] .

Trampas en Java

La codificación a menudo es un parámetro opcional, que luego se predetermina a la codificación de la plataforma. Usted también cayó en esa trampa:

String s = "...";
byte[] b = s.getBytes(); // Platform encoding, non-portable.
byte[] b = s.getBytes("UTF-8"); // Explicit
byte[] b = s.getBytes(StandardCharsets.UTF_8); // Explicit,
                         //  better (for UTF-8, ISO-8859-1)

En general, evite los métodos sobrecargados sin parámetro de codificación, ya que son solo para datos de la computadora actual: no portátiles. Para completar: las clases FileReader / FileWriter deben evitarse ya que incluso no proporcionan parámetros de codificación.

Error

japaneseString ya está mal. Entonces tienes que leer bien. Podría haber sido leído erróneamente como Windows-1252 (Windows Latin-1) y sufrió al recodificarse a UTF-8. Evidentemente, solo algunos casos se arruinan.

Tal vez tuviste:

String japanesString = new String(bytes);

en lugar de:

String japanesString = new String(bytes, StandardCharsets.UTF_8);

Al final:

String name = japaneseString;

Muestre el código para leer japaneseString para obtener más ayuda.

Answer 3

Pruebe con el archivo de parámetros JVM.encoding para establecer con el valor UTF-8 en el inicio de Tomcat (JVM). Ej: -Dfile.encoding = UTF-8