Español

Herramientas de desarrollo · JSON formateador y validador

Claves duplicadas en JSON: qué permite el RFC 8259 y qué hacen los analizadores

· Antecedentes

json estándares validación

Claves duplicadas en JSON: qué permite el RFC 8259 y qué hacen los analizadores ilustrados con tokens JSON y un límite de validación preciso
Ilustración de vector original de ToolAcre

La gramática de JSON permite la misma clave dos veces, la especificación solo dice que los nombres "deberían" ser únicos y los analizadores no están de acuerdo sobre qué valor gana. Esta publicación explica por qué eso es importante para la corrección y la seguridad.

¿Qué 'rol' leyó el servidor?

Considere `{"role":"viewer","role":"editor"}`. Ambos miembros están gramaticalmente completos, por lo que ToolAcre informa JSON válido. Cuando el texto llega a `JSON.parse`, el objeto resultante tiene una propiedad `role` cuyo valor es `"editor"`. El miembro anterior no se conserva como historial oculto. Por lo tanto, una verificación de sintaxis exitosa no responde nada sobre si los nombres de los objetos aparecieron más de una vez.

El formato hace que la pérdida sea visible solo después de que ha ocurrido: la salida contiene `{"role":"editor"}` en el diseño elegido. No puede reproducir el miembro `viewer` descartado porque la serialización recibe el objeto analizado, no la secuencia del miembro original. Si los nombres repetidos son importantes para una revisión, conserve e inspeccione el texto fuente antes de presionar Formato en lugar de confiar en el resultado normalizado.

La gramática lo permite, la especificación lo desaconseja

RFC 8259 dice que los nombres dentro de un objeto deben ser únicos. Ese "debería" promueve resultados interoperables sin hacer que la unicidad forme parte de la gramática básica del objeto. Un nombre repetido todavía consta de una cadena válida, dos puntos y un valor en la posición correcta separada por comas. En consecuencia, un validador gramatical puede aceptar el documento mientras una política de aplicación lo rechaza.

Esta distinción es fácil de pasar por alto porque muchos errores son fallas de sintaxis obligatorias: los dos puntos faltantes o la coma final no pueden formar un objeto JSON en absoluto. Los duplicados son diferentes. Crean una pregunta de interoperabilidad después de que el analizador reconoce cada token. ToolAcre se detiene intencionalmente en la sintaxis y no agrega una regla de nombre duplicado, por lo que su resultado Válido no debe leerse como una garantía de unicidad.

Qué hacen JSON.parse y ToolAcre

`JSON.parse` utiliza la aparición posterior cuando se repiten los nombres de los objetos. ToolAcre hereda ese comportamiento porque analiza antes de formatear. Para `{"limit":10,"limit":25,"unit":"items"}`, la validación se realiza correctamente, el límite analizado es 25 y la salida formateada contiene un `limit`. La clasificación de claves opcional puede reposicionar esa propiedad sobreviviente pero no puede exponer la ocurrencia sobrescrita.

No generalice ese resultado a cada analizador o configuración. Algunos sistemas pueden rechazar duplicados y otras pilas de procesamiento pueden aplicar una política diferente o inspeccionar tokens antes de construir un objeto. La declaración de seguridad entre sistemas es limitada: los nombres repetidos no son interoperables de manera confiable. Verifique los modos de análisis reales utilizados en cada límite cuando la distinción sea importante, en lugar de depender de una afirmación que abarque todo el idioma.

Cuando el desacuerdo entre el analizador se convierte en un riesgo

Los duplicados se convierten en un problema de seguridad sólo en una ruta concreta de varias etapas donde los componentes interpretan el mismo texto de manera diferente. Por ejemplo, un filtro de solicitudes podría inspeccionar una ocurrencia mientras la aplicación consume otra. Que eso pueda suceder depende de los analizadores exactos, las opciones, el comportamiento de reenvío y el uso del campo. La sintaxis duplicada por sí sola no constituye una solución explotable.

El control defendible es establecer una política en el límite de confianza y probar la pila real. Rechace nombres duplicados antes de la construcción de objetos con pérdida cuando la ambigüedad sea inaceptable, o asegúrese de que cada componente reciba la misma representación ya analizada. ToolAcre puede demostrar su propio comportamiento de formato de última victoria, pero no puede auditar puertas de enlace, marcos o servicios que no formen parte de la herramienta del navegador.

Ejemplo resuelto: un documento con una clave repetida

Pegue `{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}`. ToolAcre acepta el texto porque cada miembro es sintácticamente válido. El análisis deja el tema raíz como `dark` y la densidad anidada como `compact`. El formateo emite una copia de cada nombre, por lo que ambos valores anteriores desaparecen del documento mostrado.

Ese ejemplo también muestra por qué buscar el resultado formateado es demasiado tarde. La detección de duplicados debe observar los nombres de los miembros mientras se lee el flujo de tokens original, en cada profundidad de objeto. Las matrices no necesitan una regla de nombre duplicado, aunque las reglas de aplicación separadas pueden preocuparse por los valores de elementos repetidos. Mantenga la fuente sin cambios, ejecute un analizador o linter que reconozca duplicados y decida si la política es de advertencia o de rechazo.

Detectar duplicados a propósito

Utilice herramientas que prometan explícitamente la detección de nombres duplicados en el origen JSON. Los enfoques adecuados incluyen un modo de analizador que falla en las repeticiones, un controlador de tokens de transmisión que rastrea los nombres de cada objeto abierto o un linter con una regla de clave duplicada documentada. Verifique los objetos anidados y los nombres de escape: `"name"` y `"name"` se decodifican con el mismo nombre de miembro aunque su ortografía original difiera.

JSON El esquema no es un sustituto una vez que el análisis ordinario ha descartado ocurrencias anteriores. Un validador de esquema normalmente recibe el valor construido y ve una propiedad, no el historial del token duplicado. Ejecute la verificación de unicidad antes o durante el análisis y luego aplique verificaciones de esquema al valor inequívoco. ToolAcre no realiza detección de duplicados ni validación de esquemas, por lo que ambas requieren un paso independiente diseñado específicamente.

Lo que esto no cubre

Los nombres de objetos repetidos no son los mismos que los valores repetidos en todos los registros. `[ {"id":7}, {"id":7} ]` contiene dos objetos separados, cada uno con un `id`; Al detectar un identificador duplicado, existe una regla de conjunto de datos. Del mismo modo, dos elementos de una matriz con la misma cadena siguen siendo dos posiciones intencionales a menos que un contrato de aplicación diga que la matriz representa un conjunto.

Este artículo no pretende una política universal de primeros ganadores, últimos ganadores o rechazo para ecosistemas lingüísticos amplios. Registra el comportamiento `JSON.parse` observable de ToolAcre y explica por qué se debe verificar otro componente directamente. Tampoco determina la explotabilidad a partir de un duplicado únicamente. El impacto en la seguridad requiere evidencia de que las diferentes interpretaciones cruzan un límite de autorización, enrutamiento o validación relevante.

Conclusión: válido JSON no siempre es inequívoco JSON

Un resultado válido de ToolAcre significa que la secuencia del token es estricta JSON; no significa que cada nombre de objeto sea único. `JSON.parse` mantiene el último valor de un nombre repetido y el formato serializa solo ese superviviente. Debido a que se borra la aparición anterior, la salida formateada no es una prueba adecuada para decidir si la fuente original contenía duplicados.

Cuando la unicidad es importante, inspeccione el texto original con herramientas que detectan duplicados antes del análisis o formateo normal. Aplique la validación de esquema y dominio luego al valor inequívoco resultante. Para una revisión de seguridad, rastree la ruta de solicitud real y la configuración del analizador en lugar de asumir que no hay desacuerdo. La regla práctica es simple: la aceptación de la sintaxis, la política de nombres duplicados y el significado posterior son comprobaciones separadas con evidencia separada.