Herramientas de desarrollo · JSON formateador y validador
JSON: RFC 4627 a RFC 8259 y ECMA-404
· Antecedentes
json estándares validación
JSON ha sido especificado al menos cuatro veces por dos organismos de normalización. Esta publicación traza el camino desde json.org de Douglas Crockford hasta RFC 8259 y ECMA-404, y explica lo que realmente cambió para los desarrolladores a lo largo del camino.
¿Qué especificación sigue mi analizador?
¿Qué especificación sigue un analizador? La respuesta suele ser visible en los bordes y no en objetos y matrices ordinarios. Pruebe una cadena de nivel superior como `"ready"`, una marca de orden de bytes inicial, nombres de miembros duplicados y números inusualmente grandes. Diferentes documentos analizan la sintaxis y la interoperabilidad en diferentes niveles, mientras que las implementaciones agregan sus propios tipos de datos y comportamiento de error. Nombrar un estándar es útil sólo cuando el contrato del analizador observado se mantiene separado de las suposiciones sobre cada implementación JSON.
La evidencia del repositorio de ToolAcre es concreta y más limitada que un historial de estándares generales. El formateador utiliza `JSON.parse` para producir valores y `JSON.stringify` para emitirlos; Después de un error de análisis, un escáner local proporciona una posición y un motivo de diagnóstico estables.
json.org y la descripción inicial de JSON
json.org presentó JSON como una notación compacta derivada de la sintaxis literal de objeto de JavaScript y documentó sus estructuras centrales con una pequeña gramática. Esa descripción inicial ayudó a brindar a los desarrolladores un nombre compartido y una referencia para objetos, matrices, cadenas, números, valores booleanos y nulos. Es más seguro describir la página como una explicación pública temprana que afirmar, sin citar evidencia histórica aquí, que una página o una persona descubrió por sí sola un formato o estableció su adopción.
Las fuentes del repositorio actual no incluyen un historial de archivo de json.org, el uso del navegador ni las discusiones del comité. Muestran cómo esta aplicación analiza y diagnostica JSON hoy. En consecuencia, las declaraciones históricas en este artículo se mantienen cercanas a documentos estándar anticuados y evitan atribuir motivos o efectos en el mercado que esos archivos locales no pueden probar.
RFC 4627 en 2006: la primera descripción del IETF, el tipo de medio de la aplicación /json y la regla de que un texto tenía que ser un objeto o matriz
RFC 4627, publicado en 2006, describió JSON para el intercambio de Internet y registró el tipo de medio `application/json`. Su definición de un texto JSON requería un objeto o matriz en el nivel superior, aunque existieran cadenas, números y literales como valores dentro de esos contenedores. Esa restricción es una diferencia histórica útil porque un documento que contiene solo `"ready"` podría ser un valor válido en una formulación posterior y quedar fuera de la definición de texto JSON del RFC 4627.
El documento también analiza los problemas de codificación y seguridad en el contexto de las implementaciones disponibles en ese momento. No debe leerse como un registro de cambios para este repositorio: ToolAcre no contiene un modo de compatibilidad RFC 4627 y su ruta del analizador delega la construcción de valores al motor JavaScript del host.
ECMA-404 en 2013: el estándar mínimo de sintaxis de Ecma y por qué dos organizaciones terminaron describiendo un formato
ECMA-404, publicado por primera vez en 2013, especifica la sintaxis de JSON en una forma deliberadamente compacta. Su objetivo es la gramática del texto JSON válido en lugar de un perfil de intercambio completo para cada uso en red. Ese alcance ayuda a explicar por qué ECMA-404 y los documentos del IETF pueden describir la misma notación básica y al mismo tiempo difieren en la guía de interoperabilidad circundante que enfatizan. La existencia de dos organismos de normalización no implica dos formatos incompatibles en el uso habitual.
Las afirmaciones sobre por qué las organizaciones eligieron rutas de publicación particulares requieren fuentes documentales más allá de esta base de código, por lo que este artículo no infiere los motivos del comité a partir de las fechas de los estándares. El punto práctico relevante es que RFC 8259 y ECMA-404 están destinados a alinearse en sintaxis, mientras que RFC 8259 proporciona recomendaciones que son importantes para el intercambio interoperable.
RFC 7159 y RFC 8259
RFC 7159 reemplazó el RFC 4627 en 2014 y amplió la definición de un texto JSON a cualquier valor serializado, eliminando la regla de nivel superior de solo objeto o matriz. RFC 8259 reemplazó a RFC 7159 en 2017 y sigue siendo la referencia del IETF normalmente citada para JSON. Requiere UTF-8 para JSON intercambiado entre sistemas fuera de un ecosistema cerrado y registra precauciones de interoperabilidad en torno a números, nombres duplicados, Unicode y marcas de orden de bytes en lugar de pretender que la gramática por sí sola garantiza resultados idénticos en todas partes.
Un `true` de nivel superior es una forma compacta de observar la regla moderna del valor raíz en ToolAcre porque `JSON.parse` la acepta. Ese resultado demuestra el comportamiento de esta implementación; no reconstruye cuándo cada navegador, servidor o API adoptó la definición más amplia.
Qué cambió para los desarrolladores que trabajan
Para los desarrolladores que trabajan, los cambios de especificación más claros son la aceptación moderna de cualquier valor JSON en la raíz y una guía más sólida para la codificación interoperable. La lección menos visible es que la sintaxis válida aún deja opciones de implementación. Los nombres de objetos duplicados pueden colapsarse, el orden de los miembros no es un contrato semántico, los números muy grandes pueden perder precisión y las secuencias Unicode inusuales pueden viajar de manera diferente a través de las bibliotecas. Por lo tanto, un documento que cumpla con los estándares puede merecer restricciones adicionales de un esquema de aplicación.
En este formateador, los nombres duplicados y los tokens numéricos pasan primero por `JSON.parse`, por lo que el formato posterior refleja el valor de JavaScript resultante en lugar del documento léxico original. El escáner contribuye al diagnóstico después de una falla; no conserva miembros duplicados ni números de precisión arbitraria. Esas son observaciones respaldadas por repositorios.
Lo que esto no cubre
Lo que esto no cubre son las especificaciones superpuestas a JSON. JSON El esquema describe restricciones sobre la forma y los valores del documento; JSON El puntero dirige ubicaciones dentro de un documento; JSON El parche representa cambios. Resuelven problemas diferentes a los de la gramática base y no deben tratarse como versiones posteriores del propio JSON. JSONC, JSON5 y formatos de creación similares también amplían o alteran la sintaxis aceptada y requieren sus propios analizadores en lugar de incorporarse a una validación estricta de forma silenciosa.
Este artículo también evita una historia social completa de la adopción de JSON, el soporte del navegador o la competencia con XML porque las fuentes del repositorio enumeradas no pueden fundamentar esa narrativa. No se han inventado citas externas para llenar el vacío.
Conclusión: RFC 8259 es la referencia a citar
RFC 8259 es la referencia práctica del IETF a citar para la guía de sintaxis e interoperabilidad actual de JSON, y ECMA-404 proporciona el estándar de sintaxis Ecma alineado. RFC 4627 y RFC 7159 siguen siendo útiles para comprender cómo cambió la definición publicada, especialmente en el nivel superior. Cite el documento que respalda la afirmación exacta en lugar de utilizar "la especificación JSON" como una vaga apelación a la autoridad, y distinga las reglas normativas del comportamiento de implementación observado en un analizador en particular.
Para ToolAcre, la afirmación defendible es que el repositorio utiliza el analizador y serializador JSON de JavaScript y agrega un escáner local estricto para el diagnóstico después de fallas. Las pruebas de valores de nivel superior, puntuación mal formada y manejo de números describen esa ruta; No son fuentes históricas.