2011-10-24 42 views
5

Al tratar de procesar una respuesta JSON con GSON (el resultado es de la API de Flickr en caso de que me pregunte) encontré lo que describiría como una codificación bastante extraña de ciertos caracteres especiales:GSON/JSON: Problema especial extraño (diéresis)

Original JSON response

Aquí hay una vista hexagonal de la misma:

Hex View of Original JSON response

La 'U' seguido por el 'doble puntos' es lo que se supone que es un alemán ' ü ', y aquí es donde mi confusión empieza. Es como si alguien tomara el carbón y lo rompiera por la mitad, codificando cada una de las 2 piezas. La siguiente imagen muestra la codificación hexadecimal de lo que cabe esperar que sea en caso de que la 'U' se ha codificado correctamente:

Expected Hex View

Aún más raro, en los casos en que cabe esperar que se presenten problemas (a saber, , el conjunto de caracteres asiáticos) todo parece funcionar bien, por ejemplo "Title": "ナ ガ Opinión テ ユ ク · · ·"

Preguntas:

  1. es que alguna rareza flickrAPI o correcta codificación JSON de la reposonse? ¿O es más bien JSON codificado correctamente y es GSON que no está 'reensamblando' esta respuesta en el 'ü' original. ¿O el autor del mensaje del título simplemente lo arruinó?
  2. Cómo resuelvo el problema (en caso de que sea JSON o GSON que esté dando vueltas, obviamente no puede hacer nada si fue el autor). ¿Cómo sé lo que 'otros' caracteres se ven afectados (ö y ä vienen a la mente, pero es probable que haya más 'casos especiales').

Respuesta

4

lo que estás viendo no es un caso de Unicode decomposition:

Personajes como diéresis alemanas se pueden expresar de dos maneras:

  • la forma más tradicional precompuesto como un solo carácter o ü
  • en forma descompuesta como carácter base u seguido de combining diaeresis̈_ (Tuve que usar un guión bajo aquí para que aparezca porque no se supone ed a autolimpiante, no deja de ser los "puntos flotando" a)

Si recibe algo como esto, se puede convertir fácilmente en forma precompuesto mediante el uso de java.text.Normalizer (disponible desde Java 1.6):

String decomposed = "Mitgef\u0308hl"; 
printChars(decomposed); // Mitgefühl -- [M, i, t, g, e, f, u, ̈, h, l] 
String precomposed = Normalizer.normalize(decomposed, Form.NFC); 
printChars(precomposed); // Mitgefühl -- [M, i, t, g, e, f, ü, h, l] 

// Normalizing with NFC again doesn't hurt: 
String precomposedAgain = Normalizer.normalize(precomposed, Form.NFC); 
printChars(precomposedAgain); // Mitgefühl -- [M, i, t, g, e, f, ü, h, l] 
... 

static void printChars(String s) { 
    System.out.println(s + " -- " + Arrays.toString(s.toCharArray())); 
} 

Como puede ver, la aplicación de NFC a una cadena ya precompuesta no duele.

Tenga en cuenta que la impresión del String se verá correctamente en cualquier terminal con capacidad Unicode, solo si imprime la matriz de caracteres verá la diferencia entre la forma descompuesta y precompuesta.

Una posible fuente podría ser MacOS que tiende a codificar cosas en forma descompuesta, sin embargo, es curioso que Flickr no normalice estas cosas.

+0

¿Podría el infractor explicar por qué? –

Cuestiones relacionadas