2009-03-24 17 views
61

Recibo un error "no bien formado" en la consola de error de Firefox 3.0.7 cuando el JavaScript de mi página carga un archivo de texto que contiene un objeto en formato de notación de objetos JavaScript. Si el archivo no contiene nada más que el objeto JSON, produce el error. Si envuelvo el objeto en <documento> </document > etiquetas, no produce el error. La solicitud tiene éxito de cualquier manera, así que podría ignorarla, pero no quiero que mi registro de errores se llene con estos mensajes.error "no bien formado" en Firefox al cargar el archivo JSON con XMLHttpRequest

Aquí hay algunos ejemplos de código para ilustrar el problema. En primer lugar, el "no bien formado" archivo llamado "data.json":

{ a: 3 } 

Ahora algo de código para cargar el archivo:

que produce el siguiente error en la consola de errores de Firefox:

no bien formada
archivo: Línea //path/to/data.json: 1
{a: 3}
-^

Si data.json se modifica para esto:

<document>{ a: 3 }</document> 

No hay error. Supuse que se estaba quejando porque el archivo JSON simple no es un documento XML bien formado, así que intenté sobreescribir el tipo MIME antes de la llamada "enviar" para forzarlo a cargar como texto sin formato, pero eso no funcionó.

var req = new XMLHttpRequest(); 
req.open("GET", "data.json"); 
req.overrideMimeType("text/plain"); 
req.send(null); 
// Still produces an error! 

Voy a continuar con envolviendo mis datos JSON en un documento XML para moverse por lo validación del XMLHttpRequest está llevando a cabo, pero me gustaría saber si hay alguna manera de que pueda obligarlo a cargar solo texto sin formato acríticamente y no intentar validarlo. Alternativamente, ¿hay otro método para cargar datos además de XMLHttpRequest que pueda usarse con texto sin formato?

Respuesta

64

¿Ha intentado utilizar el tipo MIME para JSON?

application/json 

También podría configurar su servidor para enviar este tipo MIME automáticamente para archivos .json.

+0

Esto funciona, ¡gracias! –

+7

Para ser más específicos: req.overrideMimeType ("application/json"); req.send (null); funciona. Especificar el tipo MIME en el servidor sería la mejor solución, pero anularla también funciona. –

+0

¡Esto es genial! Esto funciona para mi. ¡Gracias! – shaosh

20

En primer lugar, JSON verdadero es mucho más estricto que JavaScript, y para ser JSON válido, debe tener sus claves citadas.

{ "a": 3 } 

Además, como se está utilizando un XMLHttpRequest desnuda, que generalmente espera recibir un resultado XML a menos cabeceras MIME especifican estrictamente lo contrario.

Sin embargo, es posible que desee hacer su propia vida más fácil simplemente utilizando un marco de JavaScript como jQuery que resuma todo este problema para usted y se ocupe de todos los casos desagradables.

$.getJSON("data.json",{}, function(data){ 
    /* # do stuff here */ 
}); 

Además, si se utiliza tanto estricta JSON y utiliza una biblioteca de abstraer por usted, cuando los navegadores empiezan a tener JSON nativo analizadores la biblioteca será capaz de hacer transparente el uso de estos y obtener una mejora significativa de velocidad.

(Esto está programado para suceder más temprano que tarde, y cuando sucede, ¡sus usuarios obtendrán una actualización silenciosa sin esfuerzo!).

+0

Gracias por los indicadores en JSON. Cambiaré mis datos para usar nombres de atributos de cadenas entre comillas. Lamentablemente, jQuery u otro marco no es una opción para mí. –

+0

Me interesaría mucho por qué, en general, ese es el síntoma del código malicioso para evitar con vehemencia la reutilización del código y evitar el uso de problemas resueltos. –

+1

esta debería ser la verdadera respuesta ... – TheHippo

3

Debería ser {"a": 3} en realidad.

5

Esto también ocurre cuando Content-Type está completamente vacío (lo que elude la detección de tipo natural).

-6

Kent, no estoy de acuerdo.

La siguiente ES JSON "válida":

{ a: 3 } 

JavaScript nombres de propiedades de objetos no tienen que ser cadenas.

El problema es uno de tipo MIME, no la sintaxis JSON/JavaScript.

Acabo de resolver este mismo problema agregando JSON como "text/javascript" a mis tipos servidor web mime del archivo:

text/javascript     js, json 

El error "no bien formado" desapareció. El navegador (FireFox) asumió, incorrectamente, que el archivo .json era XML.

+8

incorrecto Es válido * javascript *, y si lo interpreta como javascript, estará bien. Sin embargo, JSON es * más estricto * que javascript, y el formato JSON es analizado por separado por un cliente conforme que desea que "JSON" no "Javascript". Cualquier paginador JSON compatible con Specificiation trata las claves sin comillas como un error. –

+1

Para reiterar, JSON es * unidioma * de javascript, y mientras que * TODOS * JSON es javascript válido, ** NO ** todo Javascript es JSON válido. –

+1

Si no está de acuerdo conmigo, lleve su queja a Mozilla, ya que está argumentando que su analizador JSON es incorrecto =). http://jsfiddle.net/kentnl/uGDQP/ –

1

Encontré el mismo mensaje de error pero por una causa muy diferente. Después de un poco de tiempo infructuosamente cambiando el contenido de JSON, me di cuenta de que había reiniciado accidentalmente la página que se ejecutaba en el sistema de archivos local (archivo: //Users/me/Sites/mypage.html) en lugar del servidor (http: // localhost/~ me/Sites/mypage.html).

0

También estaba recibiendo el mismo mensaje de advertencia con XMLHttpRequest() (en FireFox), al solicitar recursos marcados como Content-Type: application/json por el servidor.

¿Cuál fue el truco para mí fue establecer explícitamente la propiedad XMLHttpRequest.responseType en json en el objeto de solicitud. Por ejemplo,

var request = new XMLHttpRequest(); 
request.onreadystatechange = function() { ... } 
... 
request.open('GET','https://random-domain.com/random-path',true); 
request.responseType = 'json'; 
... 
request.send(); 
0
Browser --- request expects a given content-type ---> Server 
     <-- response contains content-type ---------- 

Firefox se ve en el HTTP Content-Type header. Si el encabezado de respuesta HTTP del servidor no coincide con las expectativas del código de su navegador, se quejará con este mensaje.

En mi humilde opinión, este mensaje de error podría haber sido mucho mejor, como "Esperando respuesta Content-Type header ... pero encontrado ...".

Cuestiones relacionadas