2009-04-07 10 views
6

En la mayoría de los serializadores/deserializadores JSON, la parte "clave" en un diccionario javascript/matriz hash se escribe como una cadena.¿Por qué la parte "clave" en un hash/dict JS debe ser una cadena?

¿Cuál es la ventaja de utilizar una cadena como clave en lugar de simplemente escribir el nombre deseado en?

Por ejemplo, digamos que definir dos objetos k1 y k2 así:

var k1 = { a: 1, b: 2, c: 3 };   // define name normally 
var k2 = { "a": 1, "b": 2, "c": 3 }; // define name with a string 

Y entonces me encontré las siguientes pruebas:

alert(k1 == k2);     // false (of course) 

alert(k1.a == k2.a);    // true 
alert(k1["b"] == k2["b"]);   // true 

alert(uneval(k1));     // returns the k1 object literal notation. 
alert(uneval(k2));     // returns the same string as above line. 

alert(uneval(k1) == uneval(k2)); // true 

Entonces, ¿cuál es el punto de tener las llaves estén en comillas dobles (una cadena) como en la forma en que se definió k2 en lugar de solo escribir los nombres de las teclas como en la forma en que se definió k1


Acabo de ver esto en más de Ajaxian señalando Aaron Boodman's blog entry:

chromium.tabs.createTab({ 
"url": "http://www.google.com/", 
"selected": true, 
"tabIndex": 3 
}); 

ya que él también los casos de uso del camello por tabIndex, no veo ningún punto en el uso de una cadena en absoluto.

Por qué no:

chromium.tabs.createTab({ 
url: "http://www.google.com/", 
selected: true, 
tabIndex: 3 
}); 

¿Por qué un ninja JS sigue la convención de convertir url, y selectedtabIndex en una cadena?

Respuesta

6

Porque JSON es un subconjunto de la sintaxis literal de JavaScript real. Para simplificar la implementación de los analizadores JSON, siempre se requieren comillas dobles alrededor de las cadenas, y como las claves en JSON son cadenas, se requieren allí.

No todo es legal JavaScript es JSON legal. Si bien puede definir literales de objeto en JavaScript sin las comillas, si desea JSON interoperable, tendrá que ponerlos.

+0

Supongo que la convención en javascript simplemente se filtró después de haber trabajado con una gran cantidad de JSON, entonces ... – chakrit

+0

Creo que la compatibilidad de python se mencionó como una razón para las cotizaciones – cobbal

+0

@chakrit Sí. Además, como señala gizmo, generalmente es más seguro usar comillas en JavaScript, ya que no tiene que preocuparse por las palabras reservadas.Por ejemplo, {do: "something"} no es JavaScript legal. –

1

Porque al hacerlo, evita utilizar, por error, una palabra clave reservada de JavaScript, como "do" por ejemplo. Usar la notación de cuerdas te mantuvo en el lado seguro.

0

Si se debe creer el diagrama de sintaxis en json.org, los nombres de las propiedades de palabras simples no son estándar. ¿En cuántos navegadores ejecutó sus pruebas?

+0

No mucho ... pero I * do * mantiene una enorme aplicación javascript en el trabajo. Y uso los nombres de las palabras sin estilo todo el tiempo (por ejemplo, creando clases y cosas por el estilo) y funciona en todos los principales navegadores ... IE FF Opera Safari. – chakrit

+0

JSON es un subconjunto de JavaScript. Requiere cotizaciones, pero JavaScript no. –

0

Aparte de conseguir lejos de palabras clave reservadas que puede utilizar realmente lo caracteres en los nombres de propiedad - incluyendo espacios, dos puntos ...

No

entendemos para qué harías eso. Prefiero usar la notación normal de "objeto".

Cuestiones relacionadas