¿Se pueden usar los comentarios en JSON?

¿Puedo usar comentarios dentro de un archivo JSON? ¿Si es así, cómo?

No.

Todos los JSON deben ser datos, y si incluye un comentario, también serán datos.

Podría tener un elemento de datos designado llamado "_comment"(o algo) que las aplicaciones que usan los datos JSON ignorarían.

Probablemente sería mejor tener el comentario en los procesos que generan / reciben el JSON, ya que se supone que saben de antemano cuáles serán los datos JSON, o al menos la estructura de los mismos.

Pero si decidiste:

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
         "GlossList": {
            "GlossEntry": {
               "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                  "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
               },
               "GlossSee": "markup"
            }
         }
      }
   }
}

No , los comentarios del formulario //…o /*…*/no están permitidos en JSON. Esta respuesta se basa en:

• http://www.json.org
• RFC 4627 : El application/jsontipo de medio para la notación de objetos JavaScript (JSON)
• RFC 8259 El formato de intercambio de datos de notación de objetos JavaScript (JSON) (reemplaza a los RFC 4627, 7158, 7159)

Incluya comentarios si lo desea; quítelos con un minificador antes de analizarlos o transmitirlos.

Acabo de lanzar JSON.minify () que elimina los comentarios y espacios en blanco de un bloque de JSON y lo convierte en un JSON válido que se puede analizar. Entonces, puede usarlo como:

JSON.parse(JSON.minify(my_str));

Cuando lo lancé, tuve una gran reacción de personas que no estaban de acuerdo ni siquiera con la idea, así que decidí escribir una publicación completa en el blog sobre por qué los comentarios tienen sentido en JSON . Incluye este notable comentario del creador de JSON:

Supongamos que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Continúa e inserta todos los comentarios que te gusten. Luego canalícelo a través de JSMin antes de entregárselo a su analizador JSON. - Douglas Crockford, 2012

Esperemos que sea útil para aquellos que no están de acuerdo con por qué JSON.minify () podría ser útil.

Los comentarios fueron eliminados de JSON por diseño.

Eliminé los comentarios de JSON porque vi que las personas los usaban para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios entristece a algunas personas, pero no debería.

Supongamos que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Continúa e inserta todos los comentarios que te gusten. Luego canalícelo a través de JSMin antes de entregárselo a su analizador JSON.

Fuente: Declaración pública de Douglas Crockford sobre G +

DESCARGO DE RESPONSABILIDAD: SU GARANTÍA ES ANULADA

Como se ha señalado, este truco aprovecha la implementación de la especificación. No todos los analizadores JSON entenderán este tipo de JSON. Los analizadores de transmisión en particular se ahogarán.

Es una curiosidad interesante, pero realmente no deberías usarla para nada . A continuación se muestra la respuesta original.

He encontrado un pequeño truco que le permite colocar comentarios en un archivo JSON que no afectará el análisis o alterará los datos que se representan de ninguna manera.

Parece que al declarar un objeto literal puede especificar dos valores con la misma clave, y el último tiene prioridad. Lo creas o no, resulta que los analizadores JSON funcionan de la misma manera. Por lo tanto, podemos usar esto para crear comentarios en el JSON de origen que no estarán presentes en una representación de objeto analizada.

({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
// => 1

Si aplicamos esta técnica, su archivo JSON comentado podría verse así:

{
  "api_host" : "The hostname of your API server. You may also specify the port.",
  "api_host" : "hodorhodor.com",

  "retry_interval" : "The interval in seconds between retrying failed API calls",
  "retry_interval" : 10,

  "auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
  "auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",

  "favorite_numbers": "An array containing my all-time favorite numbers",
  "favorite_numbers": [19, 13, 53]
}

El código anterior es JSON válido . Si lo analiza, obtendrá un objeto como este:

{
    "api_host": "hodorhodor.com",
    "retry_interval": 10,
    "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
    "favorite_numbers": [19,13,53]
}

Lo que significa que no hay rastro de los comentarios, y no tendrán efectos secundarios extraños.

¡Feliz pirateo!

JSON no admite comentarios. Tampoco fue pensado para usarse en archivos de configuración donde se necesitarían comentarios.

Hjson es un formato de archivo de configuración para humanos. Sintaxis relajada, menos errores, más comentarios.

Consulte hjson.org para las bibliotecas JavaScript, Java, Python, PHP, Rust, Go, Ruby y C #.

Considera usar YAML. Es casi un superconjunto de JSON (prácticamente todos los JSON válidos son YAML válidos) y permite comentarios.

No puedes Al menos esa es mi experiencia de un vistazo rápido a json.org .

JSON tiene su sintaxis visualizada en esa página. No hay ninguna nota sobre los comentarios.

Los comentarios no son un estándar oficial, aunque algunos analizadores admiten comentarios de estilo C ++. Uno que uso es JsonCpp . En los ejemplos hay este:

// Configuration options
{
    // Default encoding for text
    "encoding" : "UTF-8",

    // Plug-ins loaded at start-up
    "plug-ins" : [
        "python",
        "c++",
        "ruby"
        ],

    // Tab indent size
    "indent" : { "length" : 3, "use_space": true }
}

jsonlint no valida esto. Por lo tanto, los comentarios son una extensión específica del analizador y no estándar.

Otro analizador es JSON5 .

Una alternativa a JSON TOML .

Otra alternativa es jsonc .

En su lugar, debe escribir un esquema JSON . El esquema JSON es actualmente una propuesta de borrador de especificación de Internet. Además de la documentación, el esquema también se puede utilizar para validar sus datos JSON.

Ejemplo:

{
    "description":"A person",
    "type":"object",
    "properties":
        {
            "name":
                {
                    "type":"string"
                },
            "age":
                {
                    "type":"integer",
                    "maximum":125
                }
        }
}

Puede proporcionar documentación utilizando el atributo de esquema de descripción .

Si está utilizando Jackson como su analizador JSON, así es como lo habilita para permitir comentarios:

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);

Entonces puedes tener comentarios como este:

{
  key: "value" // Comment
}

Y también puede tener comentarios comenzando #por configurar:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Pero en general (como se respondió antes) la especificación no permite comentarios.

Esto es lo que encontré en la documentación de Google Firebase que le permite poner comentarios en JSON:

{
  "//": "Some browsers will use this to enable push notifications.",
  "//": "It is the same for all projects, this is not your project's sender ID",
  "gcm_sender_id": "1234567890"
}

NO . JSON solía admitir comentarios, pero fueron abusados ​​y eliminados del estándar.

Del creador de JSON:

Eliminé los comentarios de JSON porque vi que las personas los usaban para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios entristece a algunas personas, pero no debería. - Douglas Crockford, 2012

El sitio oficial de JSON está en JSON.org . JSON se define como un estándar por ECMA International. Siempre hay un proceso de petición para revisar las normas. Es poco probable que se agreguen anotaciones al estándar JSON por varias razones.

JSON por diseño es una alternativa de ingeniería inversa (analizada por humanos) a XML. Se simplifica incluso hasta el punto de que las anotaciones son innecesarias. Ni siquiera es un lenguaje de marcado. El objetivo es la estabilidad y la interoperablilty.

Cualquiera que comprenda la relación "tiene-a" de la orientación a objetos puede comprender cualquier estructura JSON, de eso se trata. Es solo un gráfico acíclico dirigido (DAG) con etiquetas de nodo (pares clave / valor), que es una estructura de datos casi universal.

Esta única anotación requerida podría ser "// Estas son etiquetas DAG". Los nombres de clave pueden ser tan informativos como sea necesario, lo que permite una aridad semántica arbitraria.

Cualquier plataforma puede analizar JSON con solo unas pocas líneas de código. XML requiere bibliotecas OO complejas que no son viables en muchas plataformas.

Las anotaciones solo harían que JSON sea menos interoperable. Simplemente no hay nada más que agregar, a menos que lo que realmente necesite sea un lenguaje de marcado (XML), y no le importe si sus datos persistentes se analizan fácilmente.

PERO como también observó el creador de JSON, siempre ha habido soporte de canalización JS para comentarios:

Continúa e inserta todos los comentarios que te gusten. Luego canalícelo a través de JSMin antes de entregárselo a su analizador JSON. - Douglas Crockford, 2012

Si su archivo de texto, que es una cadena JSON, va a ser leído por algún programa, ¿qué tan difícil sería eliminar los comentarios de estilo C o C ++ antes de usarlo?

Respuesta: Sería un trazador de líneas. Si lo hace, los archivos JSON podrían usarse como archivos de configuración.

Si está utilizando la biblioteca Newtonsoft.Json con ASP.NET para leer / deserializar, puede usar comentarios en el contenido JSON:

// "nombre": "cadena"

//"Yo dint

o

/* Esto es un

comentario ejemplo * /

PD: los comentarios de una sola línea solo son compatibles con más de 6 versiones de Newtonsoft Json.

Nota adicional para las personas que no pueden pensar fuera de la caja: uso el formato JSON para la configuración básica en una aplicación web ASP.NET que hice. Leo el archivo, lo convierto en el objeto de configuración con la biblioteca Newtonsoft y lo uso cuando es necesario.

Prefiero escribir comentarios sobre cada configuración individual en el archivo JSON en sí, y realmente no me importa la integridad del formato JSON siempre que la biblioteca que uso esté bien con él.

Creo que esta es una forma 'más fácil de usar / comprender' que crear un archivo 'settings.README' separado y explicar la configuración en él.

Si tiene un problema con este tipo de uso; lo siento, el genio está fuera de la lámpara. La gente encontraría otros usos para el formato JSON, y no hay nada que pueda hacer al respecto.

La idea detrás de JSON es proporcionar un intercambio de datos simple entre aplicaciones. Estos suelen estar basados ​​en la web y el lenguaje es JavaScript.

Realmente no permite comentarios como tales, sin embargo, pasar un comentario como uno de los pares de nombre / valor en los datos ciertamente funcionaría, aunque obviamente esos datos tendrían que ser ignorados o manejados específicamente por el código de análisis.

Dicho todo esto, no es la intención que el archivo JSON contenga comentarios en el sentido tradicional. Deberían ser solo los datos.

Eche un vistazo al sitio web de JSON para obtener más detalles.

Acabo de encontrar esto para los archivos de configuración. No quiero usar XML (detallado, gráfico, feo, difícil de leer), o formato "ini" (sin jerarquía, sin estándar real, etc.) o formato Java "Propiedades" (como .ini).

JSON puede hacer todo lo que puede hacer, pero es mucho menos detallado y más legible para los humanos, y los analizadores son fáciles y ubicuos en muchos idiomas. Es solo un árbol de datos. Pero los comentarios fuera de banda son una necesidad a menudo para documentar configuraciones "predeterminadas" y similares. Las configuraciones nunca deben ser "documentos completos", sino árboles de datos guardados que pueden ser legibles por humanos cuando sea necesario.

Supongo que uno podría usar "#": "comment", para JSON "válido".

JSON no admite comentarios de forma nativa, pero puede hacer su propio decodificador o al menos un preprocesador para eliminar los comentarios, eso está perfectamente bien (siempre que ignore los comentarios y no los use para guiar cómo su aplicación debe procesar los datos JSON )

JSON no tiene comentarios. Un codificador JSON NO DEBE generar comentarios. Un decodificador JSON PUEDE aceptar e ignorar los comentarios.

Los comentarios nunca deben usarse para transmitir algo significativo. Para eso es JSON.

Cf: Douglas Crockford, autor de la especificación JSON .

Depende de tu biblioteca JSON. Json.NET apoya los comentarios de estilo JavaScript /* commment */.

Ver otra pregunta de desbordamiento de pila .

JSON tiene mucho sentido para los archivos de configuración y otros usos locales porque es omnipresente y porque es mucho más simple que XML.

Si las personas tienen fuertes razones para no tener comentarios en JSON cuando comunican datos (ya sean válidos o no), posiblemente JSON podría dividirse en dos:

• JSON-COM: JSON en el cable o reglas que se aplican al comunicar datos JSON.
• JSON-DOC: documento JSON o JSON en archivos o localmente. Reglas que definen un documento JSON válido.

JSON-DOC permitirá comentarios, y pueden existir otras diferencias menores, como el manejo de espacios en blanco. Los analizadores pueden convertir fácilmente de una especificación a otra.

Con respecto a la observación hecha por Douglas Crockford sobre estos temas (referenciada por @Artur Czajka)

Supongamos que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Continúa e inserta todos los comentarios que te gusten. Luego canalícelo a través de JSMin antes de entregárselo a su analizador JSON.

Estamos hablando de un problema de archivo de configuración genérico (idioma / plataforma cruzada), ¡y él está respondiendo con una utilidad específica de JS!

Claro que se puede implementar un minify específico de JSON en cualquier idioma, pero estandarice esto para que sea omnipresente en todos los analizadores en todos los idiomas y plataformas para que las personas dejen de perder el tiempo sin la función porque tienen buenos casos de uso, buscando el problema en foros en línea y hacer que la gente les diga que es una mala idea o que sugieran que es fácil implementar comentarios de eliminación de archivos de texto.

El otro problema es la interoperabilidad. Suponga que tiene una biblioteca o API o cualquier tipo de subsistema que tenga algunos archivos de configuración o datos asociados. Y se debe acceder a este subsistema desde diferentes idiomas. Entonces, ¿vas a decirle a la gente: por cierto, no olvides eliminar los comentarios de los archivos JSON antes de pasarlos al analizador!

Si usa JSON5 , puede incluir comentarios.

JSON5 es una extensión propuesta para JSON que tiene como objetivo facilitar que los humanos escriban y mantengan a mano. Lo hace agregando algunas características de sintaxis mínimas directamente desde ECMAScript 5.

El kit de herramientas JavaScript de Dojo Toolkit (al menos a partir de la versión 1.4), le permite incluir comentarios en su JSON. Los comentarios pueden ser de /* */formato. Dojo Toolkit consume el JSON a través de la dojo.xhrGet()llamada.

Otros kits de herramientas de JavaScript pueden funcionar de manera similar.

Esto puede ser útil al experimentar con estructuras de datos alternativas (o incluso listas de datos) antes de elegir una opción final.

JSON no es un protocolo enmarcado . Es un formato de idioma libre . Por lo tanto, el formato de un comentario no está definido para JSON.

Como muchas personas han sugerido, hay algunos trucos, por ejemplo, claves duplicadas o una clave específica _commentque puede usar. Tu decides.

Usted puede tener comentarios en JSONP , pero no en JSON pura. Acabo de pasar una hora tratando de hacer que mi programa funcione con este ejemplo de Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

Si sigues el enlace, verás

?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);

Como tenía un archivo similar en mi carpeta local, no hubo problemas con la política del mismo origen , así que decidí usar JSON puro ... y, por supuesto, $.getJSONestaba fallando en silencio debido a los comentarios.

Finalmente, acabo de enviar una solicitud HTTP manual a la dirección anterior y me di cuenta de que el tipo de contenido era text/javascriptporque, bueno, JSONP devuelve JavaScript puro. En este caso se permiten comentarios . Pero mi aplicación devolvió el tipo de contenido application/json, por lo que tuve que eliminar los comentarios.

Esta es una pregunta de "¿puedes?" . Y aquí hay una respuesta de "sí" .

No, no debe usar miembros de objetos duplicados para insertar datos de canal lateral en una codificación JSON. (Consulte "Los nombres dentro de un objeto DEBEN ser únicos" en el RFC ).

Y sí, podría insertar comentarios alrededor del JSON , que podría analizar.

Pero si desea una forma de insertar y extraer datos arbitrarios de canal lateral a un JSON válido, aquí hay una respuesta. Aprovechamos la representación no única de datos en una codificación JSON. Esto está permitido ^* en la sección dos del RFC bajo "el espacio en blanco está permitido antes o después de cualquiera de los seis caracteres estructurales".

^* El RFC solo establece que "el espacio en blanco está permitido antes o después de cualquiera de los seis caracteres estructurales", sin mencionar explícitamente cadenas, números, "falso", "verdadero" y "nulo". Esta omisión se ignora en TODAS las implementaciones.

Primero, canonicalice su JSON minimizándolo:

$jsonMin = json_encode(json_decode($json));

Luego codifique su comentario en binario:

$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);

Entonces steg su binario:

$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);

Aquí está su salida:

$jsonWithComment = $steg . $jsonMin;

DESCARGO DE RESPONSABILIDAD: ESTO ES TONTO

En realidad, hay una manera de agregar comentarios y permanecer dentro de las especificaciones (no se necesita un analizador adicional). Sin embargo, no dará lugar a comentarios legibles por humanos sin ningún tipo de análisis.

Podría abusar de lo siguiente:

Se permiten espacios en blanco insignificantes antes o después de cualquier token. El espacio en blanco es cualquier secuencia de uno o más de los siguientes puntos de código: tabulación de caracteres (U + 0009), avance de línea (U + 000A), retorno de carro (U + 000D) y espacio (U + 0020).

De manera hacky, puedes abusar de esto para agregar un comentario. Por ejemplo: comience y termine su comentario con una pestaña. Codifique el comentario en base3 y use los otros caracteres de espacio en blanco para representarlos. Por ejemplo.

010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202

( hello base threeen ASCII) Pero en lugar de 0 use espacio, para 1 use avance de línea y para 2 use retorno de carro.

Esto solo te dejará con un gran espacio en blanco ilegible (a menos que hagas un complemento IDE para codificarlo / decodificarlo sobre la marcha).

Nunca intenté esto, por razones obvias y tú tampoco deberías.

Estamos utilizando strip-json-commentspara nuestro proyecto. Es compatible con algo como:

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

Simplemente npm install --save strip-json-commentspara instalarlo y usarlo como:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}

En mi caso, necesito usar comentarios para propósitos de depuración, antes del resultado de la estructura JSON. Así que decidí usar la información de depuración en el encabezado HTTP, para evitar romper el cliente:

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

JSON no permite comentarios, per se. El razonamiento es completamente absurdo, porque se puede utilizar JSON sí para crear los comentarios, que obvia la razón por completo, y las cargas del espacio de datos del analizador sin motivo en absoluto para exactamente el mismo resultado y los problemas potenciales, tales como son: un JSON archivo con comentarios.

Si se intenta poner en los comentarios (utilizando //o /* */o #, por ejemplo), a continuación, algunos analizadores fallarán porque esto no es estrictamente dentro de la especificación JSON. Entonces nunca deberías hacer eso.

Aquí hay un ejemplo, donde mi sistema de manipulación de imágenes ha guardado anotaciones de imágenes y alguna información básica formateada (comentario) relacionada con ellas (en la parte inferior):

{
    "Notations": [
        {
            "anchorX": 333,
            "anchorY": 265,
            "areaMode": "Ellipse",
            "extentX": 356,
            "extentY": 294,
            "opacity": 0.5,
            "text": "Elliptical area on top",
            "textX": 333,
            "textY": 265,
            "title": "Notation 1"
        },
        {
            "anchorX": 87,
            "anchorY": 385,
            "areaMode": "Rectangle",
            "extentX": 109,
            "extentY": 412,
            "opacity": 0.5,
            "text": "Rect area\non bottom",
            "textX": 98,
            "textY": 385,
            "title": "Notation 2"
        },
        {
            "anchorX": 69,
            "anchorY": 104,
            "areaMode": "Polygon",
            "extentX": 102,
            "extentY": 136,
            "opacity": 0.5,
            "pointList": [
                {
                    "i": 0,
                    "x": 83,
                    "y": 104
                },
                {
                    "i": 1,
                    "x": 69,
                    "y": 136
                },
                {
                    "i": 2,
                    "x": 102,
                    "y": 132
                },
                {
                    "i": 3,
                    "x": 83,
                    "y": 104
                }
            ],
            "text": "Simple polygon",
            "textX": 85,
            "textY": 104,
            "title": "Notation 3"
        }
    ],
    "imageXW": 512,
    "imageYW": 512,
    "imageName": "lena_std.ato",
    "tinyDocs": {
        "c01": "JSON image notation data:",
        "c02": "-------------------------",
        "c03": "",
        "c04": "This data contains image notations and related area",
        "c05": "selection information that provides a means for an",
        "c06": "image gallery to display notations with elliptical,",
        "c07": "rectangular, polygonal or freehand area indications",
        "c08": "over an image displayed to a gallery visitor.",
        "c09": "",
        "c10": "X and Y positions are all in image space. The image",
        "c11": "resolution is given as imageXW and imageYW, which",
        "c12": "you use to scale the notation areas to their proper",
        "c13": "locations and sizes for your display of the image,",
        "c14": "regardless of scale.",
        "c15": "",
        "c16": "For Ellipses, anchor is the  center of the ellipse,",
        "c17": "and the extents are the X and Y radii respectively.",
        "c18": "",
        "c19": "For Rectangles, the anchor is the top left and the",
        "c20": "extents are the bottom right.",
        "c21": "",
        "c22": "For Freehand and Polygon area modes, the pointList",
        "c23": "contains a series of numbered XY points. If the area",
        "c24": "is closed, the last point will be the same as the",
        "c25": "first, so all you have to be concerned with is drawing",
        "c26": "lines between the points in the list. Anchor and extent",
        "c27": "are set to the top left and bottom right of the indicated",
        "c28": "region, and can be used as a simplistic rectangular",
        "c29": "detect for the mouse hover position over these types",
        "c30": "of areas.",
        "c31": "",
        "c32": "The textx and texty positions provide basic positioning",
        "c33": "information to help you locate the text information",
        "c34": "in a reasonable location associated with the area",
        "c35": "indication.",
        "c36": "",
        "c37": "Opacity is a value between 0 and 1, where .5 represents",
        "c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
        "c39": "backdrop. Recommendation is that regions be drawn",
        "c40": "only if the user hovers the pointer over the image,",
        "c41": "and that the text associated with the regions be drawn",
        "c42": "only if the user hovers the pointer over the indicated",
        "c43": "region."
    }
}

Para cortar un elemento JSON en partes, agrego líneas de "comentario ficticio":

{

"#############################" : "Part1",

"data1"             : "value1",
"data2"             : "value2",

"#############################" : "Part2",

"data4"             : "value3",
"data3"             : "value4"

}