2011-04-12 11 views
13

¿Tengo alguna manera de hacer que Jackson sea menos exigente con la entrada JSON? P.ej. JSONObject proporciona siguientes asignaciones:Haga que Jackson sea más amigable para la entrada JSON

Los constructores son más tolerantes en los textos que aceptarán:

  1. Un extra, (coma) pueden aparecer justo antes de la llave de cierre.
  2. Las cadenas pueden citarse con '(comilla simple).
  3. Las cadenas no necesitan ser citadas si no comienzan con una comilla o comilla simple, y si no contienen espacios iniciales o finales, y si no contienen ninguno de estos caracteres: {} []/\:, =; # y si no se parecen a los números y si no son las palabras reservadas verdadero, falso o nulo. *
  4. Las teclas pueden ir seguidas de = o => así como también por:.
  5. Los valores pueden ser seguidos por; (punto y coma) así como por, (coma).
  6. Los números pueden tener el prefijo 0x- (hexadecimal).

Lo más interesante para mí es el 3er punto. Permite siguiente conversión:

new JSONObject("{A : 1}"); 

... pero para Jackson que obtendrá un error con el mismo JSON de entrada:

new ObjectMapper().readTree("{ A : 1}"); // throws an exception 

Excepción:

org.codehaus.jackson.JsonParseException: Unexpected character ('A' (code 65)): was expecting double-quote to start field name 
    at [Source: [email protected]; line: 1, column: 4] 
at org.codehaus.jackson.JsonParser._constructError(JsonParser.java:943) 
at org.codehaus.jackson.impl.JsonParserBase._reportError(JsonParserBase.java:636) 
at org.codehaus.jackson.impl.JsonParserBase._reportUnexpectedChar(JsonParserBase.java:569) 
at org.codehaus.jackson.impl.ReaderBasedParser._handleUnusualFieldName(ReaderBasedParser.java:342) 
at org.codehaus.jackson.impl.ReaderBasedParser._parseFieldName(ReaderBasedParser.java:235) 
at org.codehaus.jackson.impl.ReaderBasedParser.nextToken(ReaderBasedParser.java:125) 
at org.codehaus.jackson.map.deser.BaseNodeDeserializer.deserializeObject(JsonNodeDeserializer.java:180) 
at org.codehaus.jackson.map.deser.BaseNodeDeserializer.deserializeAny(JsonNodeDeserializer.java:210) 
at org.codehaus.jackson.map.deser.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:52) 
at org.codehaus.jackson.map.deser.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:13) 
at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:1588) 
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1130) 

Respuesta

12

Lista de extensiones para JSON no estándar (es decir, cosas que NO son JSON , pero es lo suficientemente cerca como para que pueda ser soportado) se puede encontrar desde: http://wiki.fasterxml.com/JacksonFeaturesNonStandard

De su lista, (2) y (3) se puede hacer (más par de otras cosas no listadas, como commnets). Otros no son compatibles; y aunque el proyecto ha agregado soporte para algunas extensiones que se usan comúnmente, existen límites a lo que se considerará. Siempre es posible solicitar nuevas características, por supuesto; las características se agregan según solicitud, casos de uso.

En mi opinión personal, uno debe seguir el estándar o definir nuevos formatos: HTML es un buen ejemplo de los agujeros de rata que uno recibe al tratar de admitir cosas que son "casi, pero no del todo" válidas. No hay fin a los ajustes, y la interoperabilidad sufre: dado que no existe un estándar, todas las implementaciones admiten algunos subconjuntos no compatibles de características y construcciones.

4

Salida this relacionados pregunta. Muestra cómo configurar un ObjectMapper para hacer lo que desee, y también tiene una buena discusión sobre por qué es posible que no desee hacer eso :)

Cuestiones relacionadas