usar - poner comentarios en un json




¿Se pueden usar los comentarios en JSON? (20)

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.


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 .


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

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.


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.


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!


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));

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

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







comments