¿Se pueden usar 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 sería ignorado por las aplicaciones que usan los datos JSON.

Probablemente sea mejor tener el comentario en los procesos que genera / recibe el JSON, ya que se supone que deben saber con anticipación cuáles serán los datos JSON, o al menos la estructura del mismo.

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 tipo de medio de application/json para la notación de objetos JavaScript (JSON)
  • RFC 7159 El formato de intercambio de datos de JavaScript Object Notation (JSON) – Obsoletos: 4627, 7158

Incluya comentarios si elige; elimínalos con un minificador antes de analizarlos o transmitirlos.

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

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

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

Supongamos que está utilizando JSON para mantener los archivos de configuración que desea anotar. Continúa e inserta todos los comentarios que te gusten. Luego páselo por JSMin antes de entregárselo a su analizador JSON. – Douglas Crockford, 2012

Espero 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.

Quité los comentarios de JSON porque vi que la gente los estaba usando para mantener las directivas de análisis sintáctico, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios hace que algunas personas se sientan tristes, pero no debería.

Supongamos que está utilizando JSON para mantener los archivos de configuración que desea anotar. Continúa e inserta todos los comentarios que te gusten. Luego páselo por JSMin antes de entregárselo a su analizador JSON.

Fuente: statement pública de Douglas Crockford sobre G +

DESCARGO DE RESPONSABILIDAD: SU GARANTÍA ES NULA

Como se ha señalado, este truco aprovecha la implementación de la especificación. No todos los analizadores de 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 está la respuesta original.


He encontrado un pequeño hack que te permite colocar comentarios en un archivo JSON que no afectará el análisis sintáctico, 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. Entonces podemos usar esto para crear comentarios en el JSON de origen que no estará presente en una representación de objeto analizado.

 ({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 que no tendrán efectos secundarios extraños.

¡Feliz hacking!

JSON no admite comentarios. Tampoco fue pensado para ser utilizado para 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.

Hjson introducción

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

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

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

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

Debería escribir un esquema JSON en su lugar. El esquema JSON es actualmente una especificación de borrador de Internet propuesta. Además de la documentación, el esquema también se puede usar 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á usando 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 con # estableciendo:

 mapper.configure(Feature.ALLOW_YAML_COMMENTS, true); 

Pero en general (como se contestó anteriormente) la especificación no permite comentarios.

Los comentarios no son un estándar oficial. Aunque algunos analizadores admiten comentarios tipo 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 .

Lo sentimos, no podemos usar comentarios en JSON … Consulte el diagtwig de syntax para JSON en JSON.org .

Douglas Crockford dice ” por qué eliminó los comentarios en JSON y proporciona una forma alternativa de hacerlo “:

Quité los comentarios de JSON porque vi que la gente los estaba usando para mantener las directivas de análisis sintáctico, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios hace que algunas personas se sientan tristes, pero no debería.

Supongamos que está utilizando JSON para mantener los archivos de configuración que desea anotar. Continúa e inserta todos los comentarios que te gusten. Luego páselo por JSMin antes de entregárselo a su analizador JSON.

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" } 

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

Respuesta: Sería un trazador de líneas. Si lo hace, entonces 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

ejemplo de comentario * /

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

Nota adicional para las personas que no pueden pensar de manera inmediata: utilizo el formato JSON para las configuraciones básicas en una aplicación web ASP.NET que realicé. Leo el archivo, lo convierto en el objeto de configuración con la biblioteca de Newtonsoft y lo uso cuando sea necesario.

Prefiero escribir comentarios sobre cada configuración individual en el archivo JSON, y realmente no me importa la integridad del formato JSON, siempre y cuando 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’ por 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 puedas hacer al respecto.

La idea detrás de JSON es proporcionar un simple intercambio de datos entre las aplicaciones. Por lo general, se basan en la web y el lenguaje es JavaScript.

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

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

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

JSON no admite comentarios de forma nativa, pero puede crear su propio decodificador o al menos un preprocesador para eliminar comentarios, eso está perfectamente bien (siempre y cuando simplemente 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 emitir 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 .

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

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

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

Depende de tu biblioteca JSON. Json.NET admite comentarios al estilo de JavaScript, /* commment */ .

Ver otra pregunta de desbordamiento de stack .

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 razones poderosas para no tener comentarios en JSON al comunicar datos (ya sean válidos o no), posiblemente JSON podría dividirse en dos:

  • JSON-COM: JSON on the wire, or rules that apply when communicating JSON data.
  • JSON-DOC: JSON document, or JSON in files or locally. Rules that define a valid JSON document.

JSON-DOC will allow comments, and other minor differences might exist such as handling whitespace. Parsers can easily convert from one spec to the other.

With regards to the remark made by Douglas Crockford on this issues (referenced by @Artur Czajka)

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

We’re talking about a generic config file issue (cross language/platform), and he’s answering with a JS specific utility!

Sure a JSON specific minify can be implemented in any language, but standardize this so it becomes ubiquitous across parsers in all languages and platforms so people stop wasting their time lacking the feature because they have good use-cases for it, looking the issue up in online forums, and getting people telling them it’s a bad idea or suggesting it’s easy to implement stripping comments out of text files.

The other issue is interoperability. Suppose you have a library or API or any kind of subsystem which has some config or data files associated with it. And this subsystem is to be accessed from different languages. Then do you go about telling people: by the way don’t forget to strip out the comments from the JSON files before passing them to the parser!

The Dojo Toolkit JavaScript toolkit (at least as of version 1.4), allows you to include comments in your JSON. The comments can be of /* */ format. Dojo Toolkit consumes the JSON via the dojo.xhrGet() call.

Other JavaScript toolkits may work similarly.

This can be helpful when experimenting with alternate data structures (or even data lists) before choosing a final option.

If you use JSON5 you can include comments.


JSON5 is a proposed extension to JSON that aims to make it easier for humans to write and maintain by hand. It does this by adding some minimal syntax features directly from ECMAScript 5.

You can have comments in JSONP , but not in pure JSON. I’ve just spent an hour trying to make my program work with this example from Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

If you follow the link, you will see

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

Since I had a similar file in my local folder, there were no issues with the Same-origin policy , so I decided to use pure JSON… and, of course, $.getJSON was failing silently because of the comments.

Eventually I just sent a manual HTTP request to the address above and realized that the content-type was text/javascript since, well, JSONP returns pure JavaScript. In this case comments are allowed . But my application returned content-type application/json , so I had to remove the comments.

JSON is not a framed protocol . It is a language free format . So a comment’s format is not defined for JSON.

As many people have suggested, there are some tricks, for example, duplicate keys or a specific key _comment that you can use. Tu decides.

This is a “can you” question. And here is a “yes” answer.

No, you shouldn’t use duplicative object members to stuff side channel data into a JSON encoding. (See “The names within an object SHOULD be unique” in the RFC ).

And yes, you could insert comments around the JSON , which you could parse out.

But if you want a way of inserting and extracting arbitrary side-channel data to a valid JSON, here is an answer. We take advantage of the non-unique representation of data in a JSON encoding. This is allowed * in section two of the RFC under “whitespace is allowed before or after any of the six structural characters”.

* The RFC only states “whitespace is allowed before or after any of the six structural characters”, not explicitly mentioning strings, numbers, “false”, “true”, and “null”. This omission is ignored in ALL implementations.


First, canonicalize your JSON by minifying it:

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

Then encode your comment in binary:

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

Then steg your binary:

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

Here is your output:

 $jsonWithComment = $steg . $jsonMin; 

We are using strip-json-comments for our project. It supports something like:

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

Simply npm install --save strip-json-comments to install and use it like:

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

There is a good solution (hack), which is valid JSON. Just make the same key twice (or more). Por ejemplo:

 { "param" : "This is the comment place", "param" : "This is value place", } 

So JSON will understand this as:

 { "param" : "This is value place", } 

To cut a JSON item into parts I add “dummy comment” lines:

 { "#############################" : "Part1", "data1" : "value1", "data2" : "value2", "#############################" : "Part2", "data4" : "value3", "data3" : "value4" } 

The author of JSON wants us to include comments in the JSON, but strip them out before parsing them (see link provided by Michael Burr.) If JSON should have comments, why not standardize them, and let the JSON parser do the job? I don’t agree with the logic there, but, alas, that’s the standard. Using YAML solution as suggested by others is good, but requires library dependency.

If you want to strip out comments, but don’t want to have a library dependency, here is a two-line solution, which works for C++-style comments, but can be adapted to others:

 var comments=new RegExp("//.*", 'mg'); data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, '')); 

Note that this solution can only be used in cases where you can be sure that the JSON data does not contain the comment initiator, eg (‘//’).

Another way to achieve JSON parsing, stripping of comments, and no extra library, is to evaluate the JSON in a JS interpreter. The caveat with that approach, of course, is that you would only want to evaluate untainted data (no untrusted user-input.) Here is an example of this approach in node.js — another caveat, following example will only read the data once and then it will be cached:

 data = require(fs.realpathSync(doctree_fp)); 

You can use JSON with comments in it, if you load it as a text file, and then remove comments from it.

You can use decomment library for that. Below is a complete example.

Input JSON (file input.js):

 /* * multi-line comments **/ { "value": 123 // one-line comment } 

Test Application:

 var decomment = require('decomment'); var fs = require('fs'); fs.readFile('input.js', 'utf8', function (err, data) { if (err) { console.log(err); } else { var text = decomment(data); // removing comments var json = JSON.parse(text); // parsing JSON console.log(json); } }); 

Salida:

 { value: 123 } 

See also: gulp-decomment , grunt-decomment