¿Se pueden usar los comentarios en JSON?

7613

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

Michael Gundlach
fuente
153
@StingyJack: Para explicar cosas que pueden no ser obvias, o cualquier otra cosa que se pueda hacer con los comentarios. Por mi parte, a menudo tengo comentarios en los archivos de datos. XML, archivos ini y muchos otros formatos incluyen disposiciones para comentarios.
Michael Burr
24
Si, como yo, se preguntaba si //commentsestá bien para el caso de uso específico de un archivo de configuración de Sublime Text, la respuesta es sí (a partir de la versión 2). Sublime Text no se quejará al menos, mientras que se quejará {"__comment": ...}en la consola, porque es un campo inesperado.
driftcatcher 01 de
8
y tal vez esta es una razón por la cual se creó TOML ..
Alex Nolasco
10
Ligeramente novato, pero también intenté usar // para comentarios en JSON. Ahora me doy cuenta de que se usa estrictamente para el intercambio / intercambio. ¡Suspiro! No puedo comentar más :(. ¡La vida está condenada !.
Sid
12
JSON5 admite comentarios: stackoverflow.com/a/7901053/108238
schoetbi

Respuestas:

5596

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"
            }
         }
      }
   }
}
Eli
fuente
232
Podría pagar tener algún tipo de prefijo en el comentario real en caso de que alguna vez haya un campo válido llamado comentario:"__comment":"comment text goes here...",
Rob Fonseca-Ensor
19
Por cierto, la biblioteca json para Java google-gson tiene soporte para comentarios.
centic
11
¿Y si quisiera un comentario separado sobre las propiedades Accronymy Abbrev? He usado este patrón antes, pero lo detuve, ya que no me permite hacerlo. Es un hack. Tal vez si prefiero un nombre de propiedad con en su __comment__lugar. Eso es "__comment__Abbrev", sigue siendo un truco, pero me dejaría comentar sobre todas las iniciativas
Juan Mendes
41
también podría usar "//": esto parece más nativo y aún se puede repetir en el mismo padre
smnbbrv
44
Cuando JSON se usa para archivos de configuración destinados a humanos, deben ser anotados para que los humanos entiendan mejor. Anotado, dicho archivo ya no es JSON válido, pero hay soluciones. Por ejemplo, el GYP de Google admite comentarios de estilo #. JSON.Minify lo ayudará a descartar comentarios de estilo C / C ++ de su archivo de entrada.
Петър Петров
1842

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)
stakx - ya no contribuye
fuente
67
Si desea anotar su JSON con comentarios (lo que lo convierte en JSON no válido), minimícelo antes de analizarlo o transmitirlo. Crockford mismo reconoció esto en 2012 en el contexto de los archivos de configuración.
toolbear
25
@alkuzad: Cuando se trata de gramáticas formales, debe haber algo que diga explícitamente que están permitidas, no al revés. Por ejemplo, tome el lenguaje de programación que prefiera: el hecho de que alguna característica deseada (pero faltante) no se rechace explícitamente, no significa que su compilador la reconocerá mágicamente.
stakx - ya no contribuye
55
Si. El formato JSON tiene mucho espacio muerto entre elementos y es insensible al espacio en esas regiones, por lo que no hay ninguna razón por la que no pueda haber comentarios de una o varias líneas allí. Muchos analizadores y minificadores también admiten comentarios JSON, así que asegúrese de que su analizador los admita. JSON se usa mucho para los datos de la aplicación y la configuración, por lo que los comentarios son necesarios ahora. La "especificación oficial" es una buena idea, pero es insuficiente y obsoleta, así que es una pena. Minimice su JSON si le preocupa el tamaño de la carga útil o el rendimiento.
Triynko
58
Aunque su respuesta es absolutamente correcta, debe decirse que esto es BS. Con tantos usuarios finales que se encuentran con la necesidad de una configuración json, los comentarios son extremadamente útiles. Solo porque algunos sombreros de papel de aluminio decidieron que JSON es y siempre debe ser legible por máquina, ignorando el hecho de que los humanos necesitan leerlo, es una parodia de mentalidad pequeña.
cmroanirgo
18
@cmroanirgo: Obviamente no eres el primero en quejarte sobre esa limitación de JSON ... es por eso que tenemos analizadores que permiten comentarios en silencio y otros formatos como YAML y JSON5. Sin embargo, esto no cambia el hecho de que JSON es lo que es. Más bien, me parece interesante que la gente comenzó a usar JSON para propósitos donde claramente no era suficiente en primer lugar, dada la limitación en cuestión. No culpes al formato JSON; culparnos a nosotros mismos por insistir en usarlo donde no es particularmente adecuado.
stakx - ya no contribuye el
802

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.

Kyle Simpson
fuente
153
El único problema que tengo con JSON.minify () es que es realmente muy lento. Entonces hice mi propia implementación que hace lo mismo: gist.github.com/1170297 . En algunos archivos de prueba grandes, su implementación toma 74 segundos y la mía 0.06 segundos.
WizKid
56
sería genial si pudiera enviar el algoritmo alternativo sugerido al repositorio de github para JSON.minify (), para que pueda ser portado a todos los langs compatibles: github.com/getify/json.minify
Kyle Simpson
16
@MiniGod Ya he escuchado las opiniones de Doug sobre este tema muchas veces. Me dirigí a ellos hace mucho tiempo en mi blog: blog.getify.com/json-comments
Kyle Simpson
18
@ MarnenLaibow-Koser todavía hay usos válidos para los comentarios, incluso para el uso de flujo de datos (o incluso paquetes): la inclusión de metadatos de diagnóstico como el tiempo de creación o las fuentes es un uso común con XML, y también es perfectamente sensible para los datos JSON. Los argumentos en contra de los comentarios son poco profundos, y cualquier formato de datos textuales debe permitir comentarios, independientemente del uso previsto (nada especifica que JSON no se pueda usar en otro lugar, fwiw)
StaxMan
18
Si JSON debe tener aceptación universal (lo que básicamente hace), entonces debería tener una aplicación universal. Ejemplo: JSON puede servir como un archivo de configuración de la aplicación. Esta aplicación desearía comentarios.
Eggmatters
441

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 +

Artur Czajka
fuente
198
Pensé que se suponía que JSON sería más legible para los humanos que, digamos, XML. Los comentarios son para facilitar la lectura.
intrepidis
25
De todos modos, podría ser travieso y agregar directivas de análisis en el JSON: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Parece YAML es el camino a seguir entonces ...
intrepidis
73
Opinión personal: no permitir comentarios ES lamentable. No tenía otra opción que construir un analizador JSON no estándar que ignora los comentarios, para decodificar mis archivos de configuración.
caiosm1005
17
@ArturCzajka Todavía no me gusta el hecho de que JSON no admite comentarios, pero probé con INI y debo admitir que tiene mucho más sentido usarlos sobre JSON para archivos de configuración. Gracias por la respuesta y espero que más personas cambien de opinión mientras leen esta conversación. (hacer un analizador fue más un ejercicio de todos modos :)
caiosm1005
77
Es como exigir que todas las bicicletas tengan ruedas de entrenamiento porque algunas personas no pueden andar en bicicleta. Eliminar una característica importante porque las personas estúpidas abusan de él es un mal diseño. Un formato de datos debe priorizar la usabilidad sobre ser a prueba de idiotas.
Phil Goetz
205

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!

p3drosola
fuente
150
De la especificación : Los nombres dentro de un objeto DEBEN ser únicos.
Quentin
113
"todas las implementaciones lo manejan igual" - Eso es algo difícil de probar.
Quentin
9191
El orden de los elementos en JSON no está garantizado. ¡Eso significa que el "último" elemento podría cambiar!
sep332
66
Esto viola claramente la especificación (ver comentarios anteriores), no hagas esto. ietf.org/rfc/rfc4627.txt?number=4627
voidlogic
334
NO , ¿y si el analizador está transmitiendo? ¿Qué sucede si el analizador lo lee en un diccionario donde el orden de las teclas no está definido? Mata esto con fuego .
deanWombourne
183

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.

Introducción a Hjson

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

laktak
fuente
13
Votado Obviamente, es una buena variación que a las personas conservadoras no abiertas les encantaría odiar. Espero que su implementación se conozca más, y tal vez incluso se vuelva más popular que la original;) ​​Espero que alguien pueda implementarla también con Ruby. @adelphus El lenguaje bien definido es su propia perspectiva u opinión. Ser un "desarrollador" conservador si eres uno no prueba que eres mejor y podrías ser aún peor si te mantienes encerrado en espacios limitados. No juzgues fácilmente a las personas como desarrolladores terribles.
konsolebox
77
Lo siento, @konsolebox. Quizás podría reconsiderar su vista de "JSON bien definido es su opinión" después de leer ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf Es un estándar real y los desarrolladores implementan sus propias versiones "especiales" conduce a fragmentación, confusión y mucho tiempo perdido. Mire el desorden que los desarrolladores web se quedan al escribir código solo porque cada navegador implementa versiones ligeramente diferentes de los estándares. El lenguaje JSON puede no ser perfecto, pero la fragmentación es peor. Y sí, eso es solo una opinión y eres libre de estar en desacuerdo.
adelphus
22
Admiro tu sentido común, pero estás reinventando YAML. Si desea mucha flexibilidad y legibilidad humana, use YAML (en realidad no: stackoverflow.com/questions/450399/… ) o quédese con curmudgeony, pero JSON inequívoco.
toolbear
44
Creo que el formato de configuración más fácil de usar sigue siendo INI. Es sencillo y no tiene mucha sintaxis. Esto hace que sea menos intimidante para los usuarios que simplemente sumergen sus dedos en el estanque de configuración.
Matt
14
Siempre que necesite json como configuración (donde se necesitan comentarios ), nombre su archivo ".js" en lugar de ".json" ... js puede, por supuesto, manejar cualquier objeto json válido y, además, puede manejar comentarios ... Esa es la razón por la cual es "webpack.config.js" y no "webpack.config.json" (bueno, hay muchas más razones para eso también en webpack: P)
jebbie
122

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

Marnen Laibow-Koser
fuente
12
@ g33kz0r Correcto, de ahí mi descripción de YAML como un casi superconjunto de JSON.
Marnen Laibow-Koser
12
@NateS Muchas personas ya habían señalado que la respuesta era no. Sugerí una mejor manera de lograr el objetivo del OP. Esa es una respuesta.
Marnen Laibow-Koser
55
Desventaja: la yamlbiblioteca no se envía con Python.
Sangrado dedos
66
@ marnen-laibow-koser: sí, debe haber sido incompetente usar las bibliotecas YAML disponibles para Java y Perl y esperar que el YAML producido por cada uno sea consumido por el otro sin error. Esa interoperabilidad de YAML fue un problema, pero la interoperabilidad de JSON no lo fue, se explica por completo por mi falta de conocimiento.
toolbear
3
@ marnen-laibow-koser, un formato que logra lo mismo con una especificación más simple es mejor. Un formato pragmático con implementaciones perfectas es mejor que un formato ideal con implementaciones imperfectas. No toda la culpa de las bibliotecas defectuosas recae en los hombros de los implementadores; La especificación YAML es larga, densa y obtusa. Su entrada de Wikipedia cita dos ejemplos de ambigüedades; Si uno debe colocar un emisor entre un humano y el formato para protegerlo de las ambigüedades, el formato pierde su reclamo amigable con los humanos. JSON reclama menos y en su mayoría tiene éxito donde YAML reclama más y se queda corto.
toolbear
108

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.

Alegre
fuente
67

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 .

Schoetbi
fuente
Groovy tiene algunas clases integradas para manejar JSON . JsonSlurper puede manejar comentarios. Por supuesto, los comentarios no están permitidos en la especificación oficial, por lo que este comportamiento en cualquier analizador no es estándar ni portátil.
izrik
Newtonsoft Json.NET también admite comentarios de estilo C sin problemas
máximo
66

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 .

raffel
fuente
55
¿Está vivo el esquema JSON? Existe pero ¿es compatible con alguna biblioteca conocida?
Munhitsu
1
sí, el grupo de google json-schema está bastante activo y recomendaría JSV para una buena implementación de JavaScript de un validador de esquema JSON.
sorteo el
55
Esto solo ayuda con la documentación estructurada, no con la documentación ad-hoc
Juan Mendes
Si usa clojure (y estoy seguro de que no) hay un analizador de esquema JSON de código abierto razonablemente destacado aquí: github.com/bigmlcom/closchema
charleslparker
@Munhitsu Manatee.Json (.Net) es ampliamente compatible con el esquema JSON.
gregsdennis
64

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.

Andrejs
fuente
50

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"
}
mana
fuente
Para su información, Firebase Realtime Database no permite el uso de '/' en una clave. por lo que este puede ser un buen convenio para su propio uso, pero no puede hacerlo en Firebase
gutte
55
Este método rompe algunas bibliotecas, que requieren que la clave sea única. Estoy trabajando en ese tema numerando los comentarios.
MovGP0
buen comentario, encontré esta pregunta en SO ... esta parte parece no estar cubierta por la especificación stackoverflow.com/questions/21832701/…
mana
44
Tiendo a usarlo así hoy en día: {"// foo": "comentario de foo", "foo": "valor de foo", "// bar": "comentario de barra", "bar": "valor de barra"} Puede usar una matriz para múltiples comentarios: {"// foo": ["foo comment 1", "foo comment 2"], "foo": '' valor foo "}
MovGP0
47

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

Dominic Cerisano
fuente
37

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.

John T. Vonachen
fuente
1
Probablemente la mejor sugerencia hasta el momento, aunque sigue siendo un problema para mantener los archivos como un formato de intercambio, ya que necesitan un procesamiento previo antes de su uso.
Orbling
Estoy de acuerdo y he escrito un analizador JSON en Java, disponible en www.SoftwareMonkey.org, que hace exactamente eso.
Lawrence Dol
2
A pesar de que creo, no es una buena idea extender JSON (sin llamarlo un formato de intercambio diferente): asegúrese de ignorar los "comentarios" dentro de las cadenas. {"foo": "/ * Esto no es un comentario. * /"}
stofl
27
"... sería un trazador de líneas" umm, no, en realidad, JSON no es una gramática regular donde una expresión regular simplemente puede encontrar pares coincidentes de / *. Debe analizar el archivo para encontrar si aparece un / * dentro de una cadena (e ignorarlo), o si se ha escapado (e ignorarlo), etc. Además, su respuesta no es útil porque simplemente especula (incorrectamente) en lugar de proporcionar alguna solución.
Kyle Simpson
1
Lo que dijo @ kyle-simpson. Además, es demasiado modesto para dirigir a los lectores a su propia respuesta sobre el uso de JSON.minify como una alternativa a las expresiones regulares ad hoc. Haz eso, no esto.
toolbear
36

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.

dvdmn
fuente
Es difícil entender por qué alguien tendría problemas para declarar un hecho.
dvdmn
Supongo que alguien tomó una excepción porque lo anterior ya no es JSON o es JSON no válido. Quizás agregar un breve descargo de responsabilidad lo aplacaría.
toolbear
55
Estoy completamente de acuerdo con usted y, sin embargo, hasta ahora hay 883 votos a favor por la falta de respuesta que simplemente indica lo obvio. Pureza ideológica valorada por encima de la información útil, eso es SO para usted.
John
El punto es que un archivo con comentarios no es JSON y muchas bibliotecas JSON no podrán analizarlo. Siéntase libre de hacer lo que quiera en su propio programa, pero un archivo con comentarios no es JSON. Si afirma que es así, la gente intentará analizarlo con su idioma / biblioteca de elección y fallará. Es como preguntar si puede usar corchetes en lugar de corchetes angulares en XML. Puede hacer lo que quiera, pero ya no será XML.
gman
32

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.

Neil Albrock
fuente
17
Es cierto que el formato JSON no tiene comentarios. Personalmente, creo que es un error significativo: la capacidad de tener comentarios como metadatos (no datos) es algo muy útil con xml. Las versiones preliminares de la especificación JSON incluían comentarios, pero por alguna razón fueron descartados. : - /
StaxMan
44
@StaxMan se eliminaron exactamente porque la gente comenzó a usarlos como metadatos. Crockford dijo que violaba la compatibilidad para el diseño del formato, y estoy de acuerdo: si desea metadatos, ¿por qué no incluirlos como datos reales? Es aún más fácil analizar de esta manera.
Camilo Martin
66
Los metadatos pertenecen a construcciones de metadatos (por ejemplo, etiquetas HTML <meta>), no comentarios. Abusar de los comentarios para los metadatos es solo un truco utilizado donde no existe una verdadera construcción de metadatos.
Marnen Laibow-Koser
Esa es exactamente la razón por la que se descartó: los comentarios utilizados como metadatos romperían la interoperabilidad. También debe almacenar sus metadatos como JSON también.
Gaborous
1
Esta respuesta es redundante con respuestas mejor escritas y con mayor voto, que dicen esencialmente lo mismo, aunque esto haya sido escrito anteriormente. Así es la vida.
toolbear
29

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

peterk
fuente
44
Para los archivos de configuración, sugeriría YAML, no JSON. Es (casi) un superconjunto más poderoso de JSON, pero también admite construcciones más legibles, incluidos los comentarios.
Marnen Laibow-Koser
1
¿Cuántos idiomas crees que admite YAML fuera de la caja en comparación con json?
mmm
@Hamidam Más de una docena de idiomas admiten yaml: yaml.org , pero tiene razón al preguntar cuántos tienen soporte incorporado, sin la necesidad de una dependencia de biblioteca de terceros. Parece que Ruby 1.9.2 lo hace. Alguien sabe de los demás? ¿Y qué idiomas envían soporte para json por defecto?
nealmcb
55
La interoperabilidad de YAML es una mentira: stackoverflow.com/questions/450399/… . Si su instinto es usar JSON para los archivos de configuración, sígalo.
toolbear
Esto es viejo, pero creo que usar # no es una buena idea. Json está cerca de la sintaxis de un Javascript literal. Javascript admite 2 tipos de comentarios: // y / * ... * / Si fuera usted, me quedaría con uno o ambos tipos de comentarios.
Pascal Ganaye
28

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 .

gaborous
fuente
44
Crockford más tarde escribió: "Suponga que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Continúe e inserte todos los comentarios que desee. Luego canalícelo a través de JSMin antes de entregarlo a su analizador JSON". Consulte la respuesta de @ kyle-simpson sobre JSON.minify para obtener más información.
toolbear
27

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!

Basel Shishani
fuente
No es necesario fragmentar JSON. JSON con comentarios ya no es JSON. Pero es perfectamente aceptable anotar su JSON con comentarios, siempre y cuando se asegure de eliminarlos antes de analizarlos o transmitirlos. Nunca debería ser responsabilidad del receptor hacer esto.
toolbear
json5.org es una solución para json-doc
Michael Freidgeim
24

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.

Smit Johnth
fuente
55
¿Podría por favor agregar un ejemplo? Entonces es posible que realmente necesites esos caracteres adicionales.
dgilperez
66
Es requerido por las directrices SO para proporcionar una respuesta real. No se desean respuestas de solo enlace. Puede consultar las pautas stackoverflow.com/help/how-to-answer
dgilperez
2
SO es moderado por sus usuarios. Eso significa que puedo proporcionar una respuesta si la tengo de la misma manera que puedo comentar la suya si no sigue las pautas. Así es como SO llega a ser un gran recurso.
dgilperez
22

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.

David
fuente
44
No. No esto. JSON no tiene comentarios. Si elige anotar su JSON con comentarios, minimícelo antes de analizar o transmitir. Esto no debería ser responsabilidad del receptor.
toolbear
2
No dije que JSON tiene comentarios. Tampoco quise decir que sea apropiado incluirlos en su JSON, especialmente en un sistema de producción. Dije que el kit de herramientas de Dojo le permite agregarlos, lo cual es (o al menos, era) cierto. Existen casos de uso muy útiles para hacerlo en su fase de prueba.
David
1
Es un vudú malo servir comentarios comentados y, por lo tanto, un JSON inválido, que dojo.xhrGet()implícitamente fomenta al aceptar.
toolbear
Todavía voto por actualizar la especificación JSON para permitir comentarios. Estoy a favor de minimizar y eliminar los comentarios antes de transmitir el JSON, pero no tener la capacidad de comentar su JSON de manera estándar sin tener que pasarlo por una utilidad separada antes de analizarlo, simplemente parece una tontería. También hago que sea imposible usar un editor JSON en sus archivos de configuración JSON, porque sus archivos no son JSON válidos.
Craig
20

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.

Shrivastava Manish
fuente
18

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.

osa
fuente
17

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;
William Entriken
fuente
1
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", "nulo". Esta omisión se ignora en TODAS las implementaciones.
William Entriken
1
Para una mayor densidad de comentarios, ¿no podría codificar su comentario en ternario y usar el espacio, la pestaña y la nueva línea para definirlo?
Claire Nielsen
NO SE DEBE. Consulte el RFC 2119 incluido explícitamente: DEBE: Esta palabra, o los términos "REQUERIDO" o "DEBERÁ", significa que la definición es un requisito absoluto de la especificación. ... DEBE: Esta palabra, o el adjetivo "RECOMENDADO", significa que pueden existir razones válidas en circunstancias particulares para ignorar un elemento en particular, pero las implicaciones completas deben ser entendidas y sopesadas cuidadosamente antes de elegir un curso diferente.
Jeff K
Buena referencia Un mejor razonamiento contra el uso de claves duplicadas es la cita del estándar "Cuando los nombres dentro de un objeto no son únicos, el comportamiento del software que recibe dicho objeto es impredecible". También ahora entiendo por qué el estándar no era "DEBE ser único", esto hace que un validador sea más simple, solo necesita rastrear [y {, no necesita saber qué teclas ya se usaron.
William Entriken
16

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.

Roy Prins
fuente
12

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'}
Alegría
fuente
Tenga en cuenta que jsonya no es un JSON válido cuando incluye estos comentarios de propiedad.
Roy Prins
12

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

Ingrese la descripción de la imagen aquí

WilliamK
fuente
12

JSON no permite comentarios, per se. El razonamiento es completamente absurdo, porque se puede utilizar JSON 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."
    }
}
fyngyrz
fuente
El enlace de "razonamiento" está roto. ¿Alguna posibilidad de encontrar un enlace actual?
Don Hatch el
Don, desafortunadamente, Google ha matado el sistema de redes sociales que contenía la publicación; No tengo idea de dónde fue el cartel original desde allí, si es que en algún lugar. Sin embargo, eliminaré el enlace en la información anterior, para eliminar la ambigüedad. Gracias.
fyngyrz
El razonamiento no es tonto, y lo acabas de demostrar. La implementación de comentarios como etiquetas preserva la interoperabilidad . Esto es exactamente por qué Crockford quería que los comentarios se analizaran como etiquetas. Ahora todo es solo una etiqueta y se analiza de la misma manera .
Dominic Cerisano
Si la especificación indica que "una línea que comienza con # es un comentario", entonces sería totalmente interoperable. Tal como están las cosas, los comentarios cargan el espacio del analizador, ya que son elementos analizados válidos en lugar de ser entendidos como comentarios, y pueden ser diferentes para cada archivo .json existente. Mientras que si (por ejemplo) la especificación dice "las líneas que comienzan con # son comentarios", entonces los analizadores podrían omitir esas líneas sin analizar (más rápido) y no cargar el espacio del analizador (mejor utilización de la memoria). No hay ningún beneficio en absoluto por la falta de comentarios en .json, solo desventajas.
Fyngyrz
11

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

{

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

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

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

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

}
Chris
fuente
15
Has emulado una estructura de archivo INI en JSON. Por favor, deja tu martillo dorado.
Artur Czajka
44
RFC dice "Los nombres dentro de un objeto DEBEN ser únicos". También vea a esta persona que está teniendo un error al analizar JSON como el anterior: stackoverflow.com/questions/4912386/…
William Entriken
Si está utilizando un esquema para validar el JSON, puede fallar debido a los campos adicionales.
gregsdennis
1
Si realmente está decidido a agregar comentarios a su JSON, tendría mucho más sentido hacer algo como esto: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } esto mantiene el nombre único y le permite agregar cualquier valor de cadena que desee. Todavía es un error, porque los comentarios no deberían ser parte de su JSON. Como otra alternativa, ¿por qué no agregar comentarios antes o después de su JSON, pero no dentro de él?
Jazimov