usar poner hacer formato estructura ejemplos como comentarios comentario comentar comenta json comments

poner - ¿Se pueden usar los comentarios en JSON?



json ejemplos (30)

Acabo de encontrar esto para los archivos de configuración. No quiero usar el formato XML (detallado, gráfico, feo, difícil de leer) o "ini" (sin jerarquía, sin estándar real, etc.) o el formato "Propiedades" de Java (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 sólo un árbol de datos. Pero los comentarios fuera de banda son a menudo una necesidad para documentar configuraciones "por defecto" y similares. Las configuraciones nunca deben ser "documentos completos", sino árboles de datos guardados que pueden ser leídos por humanos cuando sea necesario.

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

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


Considera usar YAML. Es casi un superconjunto de JSON (prácticamente todo JSON válido es YAML válido) y permite comentarios.


Deberías escribir un esquema JSON en su lugar. El esquema JSON es actualmente una propuesta de especificación de borrador 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 .


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


JSON no admite comentarios de forma nativa, pero puede crear su propio decodificador o al menos un preprocesador para eliminar los comentarios, eso es perfectamente correcto (siempre que solo 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 comentarios.

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

Cf: Douglas Crockford, autor de JSON spec .


JSON no soporta 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.

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


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

Sin embargo, realmente no permite comentarios como tales, sin embargo, pasar un comentario como uno de los pares nombre / valor en los datos funcionaría, aunque obviamente los datos deberían 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. Solo deben ser los datos.

Echa un vistazo a la página web de JSON para más detalles.


Lo sentimos, no podemos usar comentarios en JSON ... Vea el diagrama de sintaxis de JSON en JSON.org .

Douglas Crockford dice " plus.google.com/118095276221607585885/posts/RK8qyGVaGSr ":

Eliminé los comentarios de JSON porque vi que la gente los estaba usando 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. Anímate e inserta todos los comentarios que quieras. Luego colóquelo en JSMin antes de entregárselo a su analizador JSON.


Los comentarios fueron eliminados de JSON por diseño.

Eliminé los comentarios de JSON porque vi que la gente los estaba usando 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. Anímate e inserta todos los comentarios que quieras. Luego colóquelo en JSMin antes de entregárselo a su analizador JSON.

Fuente: plus.google.com/118095276221607585885/posts/RK8qyGVaGSr


Los comentarios no son una norma 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. Así que los comentarios son una extensión específica del analizador y no estándar.

Otro analizador es JSON5 .

Una alternativa a JSON TOML .


No.

El JSON debe ser todos datos, y si incluye un comentario, también lo será.

Podría tener un elemento de datos designado llamado "_comment" (o algo así) 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 deben saber de antemano cuáles serán los datos de JSON, o al menos su estructura.

Pero si decides:

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


RENUNCIA: SU GARANTÍA ES NULA

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 streaming 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, ni 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 del 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 válido JSON . Si lo analizas, obtendrás 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 piratería!


Si está utilizando Jackson como su analizador JSON, esta es la forma en que 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 puedes tener comentarios que comiencen con # configurando:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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


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 son compatibles con las versiones 6+ 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. Leí el archivo, lo convertí en el objeto de configuración con la biblioteca de Newtonsoft y lo uso cuando es necesario.

Prefiero escribir comentarios sobre cada configuración individual en el propio archivo JSON, y realmente no me importa la integridad del formato JSON, siempre que la biblioteca que uso esté de acuerdo.

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

Si tienes 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.


Si su archivo de texto, que es una cadena JSON, 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, entonces los archivos JSON podrían usarse como archivos de configuración.


Usted no puede Al menos esa es mi experiencia de un rápido vistazo a JSON.org .

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


Incluir comentarios si lo desea; Elimínelos con un minificador antes de analizarlos o transmitirlos.

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

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

Cuando lo publiqué, tuve una gran reacción de personas que no estaban de acuerdo con la idea, así que decidí escribir una entrada de blog completa 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. Anímate e inserta todos los comentarios que quieras. Luego colóquelo en JSMin antes de entregárselo a su analizador JSON. - plus.google.com/118095276221607585885/posts/RK8qyGVaGSr

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


JSON no es un protocolo enmarcado . Es un formato libre de idioma . Así que 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.


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

  • http://www.json.org
  • RFC 4627 : La application/json Media Type para notación de objetos de JavaScript (JSON)
  • RFC 7159 El formato de intercambio de datos de la notación de objetos de JavaScript (JSON) - Obsoletos: 4627, 7158

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

Si las personas tienen fuertes razones 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 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 pequeñas diferencias, como el manejo de espacios en blanco. Los analizadores pueden convertir fácilmente de una especificación a la otra.

Con respecto a la plus.google.com/118095276221607585885/posts/RK8qyGVaGSr hecha por Douglas Crockford sobre estos temas (referenciado por @Artur Czajka)

Supongamos que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Anímate e inserta todos los comentarios que quieras. Luego colóquelo en JSMin antes de entregárselo a su analizador JSON.

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

Claro que se puede implementar una minificación específica de JSON en cualquier idioma, pero estandarice esto de modo que se convierta en omnipresente en todos los analizadores en todos los idiomas y plataformas, de modo que la gente deje de perder el tiempo sin la característica porque tienen buenos casos de uso para ello. foros en línea, y hacer que la gente les diga que es una mala idea o sugerir que es fácil implementar la eliminación de comentarios de archivos de texto.

El otro tema es la interoperabilidad. Supongamos que tiene una biblioteca o API o cualquier tipo de subsistema que tenga asociados algunos archivos de configuración o de datos. Y este subsistema debe ser accedido desde diferentes idiomas. Luego, dile a la gente: por cierto, ¡no olvides eliminar los comentarios de los archivos JSON antes de pasarlos al analizador!


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

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


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

Ver otra pregunta de desbordamiento de pila .


El autor de JSON quiere que incluyamos comentarios en el JSON, pero los eliminamos antes de analizarlos (vea el plus.google.com/118095276221607585885/posts/RK8qyGVaGSr proporcionado por Michael Burr). Si JSON debería tener comentarios, ¿por qué no estandarizarlos y dejar que el analizador JSON haga el trabajo? No estoy de acuerdo con la lógica allí, pero, ay, esa es la norma. Usar una solución YAML como lo sugieren otros es bueno, pero requiere una dependencia de la biblioteca.

Si desea eliminar comentarios, pero no quiere tener una dependencia de biblioteca, aquí hay una solución de dos líneas, que funciona para comentarios de estilo C ++, pero que puede adaptarse a otros:

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

Tenga en cuenta que esta solución solo se puede utilizar en los casos en que puede estar seguro de que los datos JSON no contienen el iniciador de comentarios, por ejemplo, (''//'').

Otra forma de lograr el análisis JSON, la eliminación de comentarios y no una biblioteca adicional, es evaluar el JSON en un intérprete de JavaScript. La advertencia con este enfoque, por supuesto, es que solo querría evaluar los datos no contaminados (no la entrada del usuario no confiable). Este es un ejemplo de este enfoque en Node.js: otra advertencia, el siguiente ejemplo solo leerá los datos una vez y luego se almacenará en caché:

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


El kit de herramientas de 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 cuando se experimenta con estructuras de datos alternativas (o incluso listas de datos) antes de elegir una opción final.


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

No, no debe usar miembros de objetos duplicados para rellenar datos del 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 en torno al JSON , que podría analizar.

Pero si desea una forma de insertar y extraer datos de canal lateral arbitrarios 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 de la RFC bajo "el espacio en blanco está permitido antes o después de cualquiera de los seis caracteres estructurales".

* El RFC solo indica "se permite el espacio en blanco 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 es ignorada en TODAS las implementaciones.

Primero, canonicaliza tu JSON reduciéndolo:

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

Luego codifica tu comentario en binario:

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

Entonces steg tu binario:

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

Aquí está tu salida:

$jsonWithComment = $steg . $jsonMin;


Estamos utilizando strip-json-commentspara nuestro proyecto. Soporta algo como:

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

Simplemente npm install --save strip-json-commentsinstalarlo y usarlo como:

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


Hay una buena solución (hack), que es JSON válido. Solo haz la misma clave dos veces (o más). Por ejemplo:

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

Entonces JSON entenderá esto como:

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


Si usas JSON5 puedes incluir comentarios.

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


Suspiro. ¿Por qué no simplemente agregar campos, por ejemplo

{ "note1" : "This demonstrates the provision of annotations within a JSON file", "field1" : 12, "field2" : "some text", "note2" : "Add more annotations as necessary" }

Solo asegúrate de que tus nombres "notex" no entren en conflicto con ningún campo real


Usted puede tener comentarios en JSONP , pero no en JSON pura. Acabo de pasar una hora intentando 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] ]);

Debido a que 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, $.getJSONfallaron 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/javascript, bueno, JSONP devuelve JavaScript puro. En este caso se permiten comentarios . Pero mi aplicación devolvió el tipo de contenido application/json, así que tuve que eliminar los comentarios.