¿Se pueden utilizar los comentarios en JSON?

8499

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

18
  • 184
    @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 archivos de datos. XML, archivos ini y muchos otros formatos incluyen disposiciones para comentarios. 28/108 a las 20:51
  • 30
    Si usted, 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á de él, al menos, mientras que se quejará {"__comment": ...}en la consola, porque es un campo inesperado. 1 feb 2013 a las 15:12
  • 21
    JSON5 admite comentarios: stackoverflow.com/a/7901053/108238 02/02/2015 a las 11:13
  • 4
    Uno de los objetivos clave de JSON es eliminar la placa base de formatos como XML. Se trata de los datos y el margen mínimo. Es un formato obstinado que le impide explícitamente utilizar comentarios. json-schema ayudará de alguna manera a que las personas comprendan los datos, de manera similar a los esquemas XML, pero el soporte de la herramienta debe mejorar. JSON se ha infiltrado en otras áreas además de la transferencia a través de Internet ahora, y estoy de acuerdo en que sería útil con comentarios para ese uso. 31/03/19 a las 11:08
  • 5
    "Eliminé los comentarios de JSON porque vi que la gente los usaba 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 ser así". - Douglas Crockford (Autor de JSON), 2012 20/11/19 a las 15:45
6341

No.

El JSON es solo datos, y si incluye un comentario, también serán datos.

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

Probablemente sería mejor tener el comentario en los procesos que genera / recibe el JSON, ya que se supone que saben cuáles serán los datos JSON de antemano, 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"
            }
         }
      }
   }
}
19
  • 278
    Puede resultar útil 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...", 3 de febrero de 2010 a las 11:41
  • 29
    Por cierto, la biblioteca json para Java google-gson tiene soporte para comentarios.
    centic
    1/10/12 a las 12:21
  • 12
    ¿Y si quisiera un comentario por separado sobre las propiedades Accronymy Abbrev? He usado este patrón antes, pero lo dejé porque no me permite hacer eso. Es un truco. Quizás si prefijo el nombre de una propiedad con en su __comment__lugar. Eso es "__comment__Abbrev", sigue siendo un truco, pero me dejaría comentar todas las propiedades. 11 de agosto de 2014 a las 12:58
  • 56
    también puede usar "//": esto parece más nativo y aún se puede repetir en el mismo padre
    smnbbrv
    28/08/15 a las 9:59
  • 13
    Cuando se usa JSON para archivos de configuración diseñados por humanos, deben anotarse para que los humanos los comprendan 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. 27 feb 2016 a las 13:59
2015

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

  • https://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 las RFC 4627, 7158, 7159)
11
  • 83
    Si desea anotar su JSON con comentarios (lo que lo convierte en JSON inválido), minimícelo antes de analizarlo o transmitirlo. El propio Crockford reconoció esto en 2012 en el contexto de los archivos de configuración. 7 de agosto de 2014 a las 19:26
  • 32
    @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 elija: el hecho de que alguna característica deseada (pero faltante) no esté explícitamente prohibida, no significa que su compilador la reconocerá mágicamente. 28 de septiembre de 2015 a las 7:01
  • 9
    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 tener 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 los ajustes de configuración, por lo que los comentarios son necesarios ahora. La "especificación oficial" es una buena idea, pero es insuficiente y obsoleta, es una lástima. Minimice su JSON si le preocupa el tamaño o el rendimiento de la carga útil.
    Triynko
    31 oct 2017 a las 17:36
  • 85
    Aunque su respuesta es absolutamente correcta, debe decirse que esto es una tontería. Con tantos usuarios finales que se encuentran con la necesidad de una configuración json, los comentarios son sumamente útiles. El hecho de que algunos sombreros de papel de aluminio decidieran que JSON es y siempre debe ser legible por máquina, ignorando el hecho de que los humanos necesitan leerlo, es en mi humilde opinión una parodia de mezquindad. 21/01/18 a las 0:29
  • 23
    @cmroanirgo: Obviamente no eres el primero en quejarte de esa limitación de JSON ... por eso tenemos analizadores que permiten comentarios silenciosamente 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 comenzara a usar JSON para fines en los que claramente no era suficiente en primer lugar, dada la limitación en cuestión. No culpes al formato JSON; Nos culpamos por insistir en usarlo donde no encaja particularmente bien. 21 de enero de 2018 a las 7:48
913

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

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

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

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

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. - Douglas Crockford, 2012

Con suerte, eso es útil para aquellos que no están de acuerdo con por qué JSON.minify () podría ser útil.

20
  • 171
    El único problema que tengo con JSON.minify () es que es realmente muy lento. Así que 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
    25/08/11 a las 9:16
  • sesenta y cinco
    Sería genial si pudieras enviar el algoritmo alternativo sugerido al repositorio de github para JSON.minify (), de modo que pueda ser portado a todos los idiomas compatibles: github.com/getify/json.minify 30/08/11 a las 17:20
  • 18
    @MiniGod Ya he escuchado los pensamientos de Doug sobre este tema muchas veces. Me referí a ellos hace mucho tiempo en mi publicación de blog: blog.getify.com/json-comments 26 feb 2013 a las 23:21
  • 23
    @ 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 perfectamente sensible para los datos JSON también. Los argumentos en contra de los comentarios son superficiales, y cualquier formato de datos textuales debe permitir comentarios, independientemente del uso previsto implícito (ninguna especificación sugiere que JSON no se pueda usar en otro lugar, fwiw)
    StaxMan
    28 de marzo de 2014 a las 22:09
  • 23
    Si JSON va a tener una aceptación universal (lo que básicamente tiene), entonces debería tener una aplicación universal. Ejemplo: JSON puede servir como archivo de configuración de la aplicación. Esta aplicación desearía comentarios. 27/01/16 a las 19:31
502

Los comentarios se eliminaron de JSON por diseño.

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.

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.

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

21
  • 254
    Pensé que JSON debía ser más legible por humanos que, digamos, XML. Los comentarios son para facilitar la lectura. 14/10/12 a las 13:00
  • 36
    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 ... 14/10/12 a las 13:04
  • 91
    Opinión personal: no permitir comentarios ES poco convincente. 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. 23 de septiembre de 2013 a las 2:28
  • 38
    "Eliminé los comentarios de JSON porque vi que la gente los usaba para mantener la directiva de análisis". Según esa lógica, también debería haber eliminado el tipo de cadena. Terrible decisión. 12/06/2014 a las 14:22
  • 100
    Eso es como requerir 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 ella es un mal diseño. Un formato de datos debe priorizar la usabilidad sobre ser a prueba de idiotas. 14 de mayo de 2015 a las 17:24
309

JSON no admite comentarios. Tampoco se diseñó para utilizarlo en archivos de configuración en los que 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.github.io para las bibliotecas JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ y C #.

8
  • 27
    Voto a favor. 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 lo es, no prueba que sea mejor y podría ser incluso peor si se mantiene encerrado en espacios limitados. No juzgues fácilmente a las personas como desarrolladores terribles. 30/06/2014 a las 19:20
  • 13
    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 la fragmentación, la confusión y una gran pérdida de tiempo. Mire el lío que dejan los desarrolladores web cuando escriben código solo porque cada navegador implementa versiones ligeramente diferentes de estándares. Puede que el lenguaje JSON no sea perfecto, pero la fragmentación es peor. Y sí, eso es solo una opinión y eres libre de no estar de acuerdo. 9 de julio de 2014 a las 16:02
  • 27
    Admiro tu coraje, pero estás reinventando YAML. Si desea mucha flexibilidad y legibilidad humana, use YAML (no lo haga en realidad: stackoverflow.com/questions/450399/… ) o quédese con la cascarrabias, pero sin ambigüedades, JSON. 7 de agosto de 2014 a las 18:25
  • 5
    Encuentro 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 los dedos de los pies en el estanque de configuración.
    Matt
    10 feb.15 a las 15:15
  • 23
    Siempre que necesite json como configuración (donde se necesitan comentarios ), nombre su archivo ".js" en lugar de ".json". Por supuesto, js puede manejar cualquier objeto json válido y, además, puede manejar comentarios. Esa es la razón por la que es "webpack.config.js" y no "webpack.config.json" (bueno, también hay muchas más razones para eso en webpack: P)
    jebbie
    6/04/2016 a las 14:20
227

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 comprenderán este tipo de JSON. En particular, los analizadores de flujo se ahogarán.

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


Encontré 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 se pueden especificar dos valores con la misma clave, y el último tiene prioridad. Lo crea 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á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 piratería!

26
  • 172
    De la especificación : Los nombres dentro de un objeto DEBEN ser únicos.
    Quentin
    2/0813 a las 13:50
  • 103
    El orden de los elementos en JSON no está garantizado. ¡Eso significa que el "último" elemento podría cambiar!
    sep332
    2 de agosto de 2013 a las 14:33
  • 69
    Esto claramente viola la especificación (vea los comentarios anteriores), no haga esto. ietf.org/rfc/rfc4627.txt?number=4627 2 de agosto de 2013 a las 14:39
  • 359
    NO , ¿qué pasa si el analizador está transmitiendo? ¿Qué pasa si el analizador lo lee en un diccionario donde el orden de las claves no está definido? mata esto con fuego . 2 de agosto de 2013 a las 14:55
  • 27
    Mientras trabajamos en RFC 4627bis en el IETF en el grupo de trabajo JSON (¡únase a nosotros y ayude! Datatracker.ietf.org/wg/json ), hemos encontrado cuatro enfoques diferentes que los implementadores han usado para nombres duplicados en un objeto. : use el primero; usa el último; informar de todos ellos y dejar que la persona que llama elija uno; devuelve un error y deja de analizar. Si sus datos no pueden sobrevivir a todos esos enfoques, no interactuarán en la práctica. 3 de agosto de 2013 a las 22:03
158

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

10
  • 15
    @NateS Muchas personas ya habían señalado que la respuesta era no. Sugerí una mejor manera de lograr el objetivo del PO. Esa es una respuesta. 28 de marzo de 2014 a las 12:57
  • 6
    @ marnen-laibow-koser: sí, debe haber sido una incompetencia usar las bibliotecas YAML disponibles para Java y Perl y esperar que el YAML producido por cada uno sea consumido por el otro sin errores. Esa interoperabilidad YAML fue un problema, pero la interoperabilidad JSON no lo fue, se explica completamente por mi falta de conocimiento. 17 de agosto de 2014 a las 23:32
  • 4
    @ 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 hay que poner un emisor entre un humano y el formato para protegerlos de las ambigüedades, el formato pierde su pretensión de ser amigable con los humanos. JSON reclama menos y mayormente tiene éxito donde YAML reclama más y se queda corto. 25 de agosto de 2014 a las 11:45
  • 3
    @ marnen-laibow-koser, he refutado su implicación de mi propia incompetencia, he respaldado mis afirmaciones con detalles y he elaborado un poco sobre mis preferencias / sesgos que informan mi crítica de YAML. Otros comentarios hechos por mí probablemente tengan rendimientos decrecientes. Confío en la capacidad de los futuros lectores para tomar una decisión informada. Aparte de esquivar de cerca un ataque ad hominem, gracias por el discurso. La última palabra es tuya si la deseas. 25 de agosto de 2014 a las 11:56
  • 3
    @toolbear No se pretendía ningún ataque ad hominem. "Un formato pragmático con implementaciones perfectas es mejor que un formato ideal con implementaciones imperfectas". No estoy seguro de estar de acuerdo. Si el formato es ideal (e implementable), siempre se puede realizar una buena implementación. Si el formato no es el ideal, incluso una implementación perfecta no será muy buena. :) "la especificación YAML es larga, densa y obtusa". Eso no es realmente lo que significa "obtuso", pero la especificación YAML es bastante clara. No veo ninguna ambigüedad mencionada en Wikipedia; cite secciones específicas del artículo si me perdí algo. 13 de septiembre de 2014 a las 0:58
125

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

97

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 .

La última versión de nlohmann / json tiene soporte opcional para ignorar los comentarios sobre el análisis.

2
  • 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
    6/11/15 a las 21:47
  • Newtonsoft Json.NET también admite comentarios de estilo C sin problemas
    Max
    17 abr.20 a las 1:19
79

En su lugar, debería escribir un esquema JSON . 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 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 .

4
  • 1
    sí, el grupo de google json-schema es bastante activo y recomendaría JSV para una buena implementación de JavaScript de un validador de esquema JSON.
    raffel
    27/11/12 a las 11:34
  • Si usa clojure (y estoy seguro de que no lo hace), aquí hay un analizador de esquemas JSON de código abierto con funciones razonables: github.com/bigmlcom/closchema 15/04/2013 a las 13:50
  • @Munhitsu Manatee.Json (.Net) admite ampliamente el esquema JSON. 26/06/15 a las 0:26
  • Esto no es relevante para todas las situaciones. Tengo uno en el que tengo un JSON configurado manualmente para que lo analice otra cosa (un administrador de paquetes) que tiene su propio esquema. En eso quiero un comentario como / * Es mejor usar X en lugar de otro administrador de paquetes, sin embargo, ese administrador no proporciona X todavía. * /.
    jgmjgm
    8 dic 2017 a las 11:22
75

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 con la #configuración:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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

1
  • ¿Es esto reversible? ¿Qué pasa si carga el archivo y lo vuelve a escribir?
    R. Du
    19 nov.20 a las 18:11
71

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"
}
4
  • Para su información, Firebase Realtime Database no permite el uso de '/' en una clave. por lo que esta puede ser una buena convención para su propio uso, pero no puede hacerlo en Firebase
    gutte
    1 de nov. De 2017 a las 20:44
  • 6
    Este método rompe algunas bibliotecas, que requieren que la clave sea única. Estoy solucionando ese problema numerando los comentarios.
    MovGP0
    19 de enero de 2018 a las 11:45
  • buen comentario, encontré esta pregunta en SO ... esta parte parece no estar cubierta por la especificación stackoverflow.com/questions/21832701/…
    mana
    20 de ene. De 2018 a las 19:36
  • 8
    Tiendo a usarlo así hoy en día: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} Puede usar una matriz para varios comentarios: {"// foo": ["comentario foo 1", "comentario foo 2"], "foo": '' valor foo "}
    MovGP0
    9/03/18 a las 16:29
61

NO . JSON solía admitir comentarios, pero se abusó de ellos y se eliminaron del estándar.

Del creador de JSON:

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. - Douglas Crockford, 2012

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

JSON por diseño es una alternativa fácil 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 interoperabilidad.

Cualquiera que comprenda la relación "tiene-a" de la orientación a objetos puede comprender cualquier estructura JSON; ese es el punto. 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 necesaria podría ser "// Estas son etiquetas DAG". Los nombres de las claves pueden ser tan informativos como sea necesario, lo que permite una aridez 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 pueden analizar fácilmente.

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

Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. - Douglas Crockford, 2012

0
46

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

Respuesta: Sería una sola línea. Si lo hace, los archivos JSON podrían usarse como archivos de configuración.

6
  • 3
    Probablemente la mejor sugerencia hasta ahora, aunque sigue siendo un problema para mantener los archivos como formato de intercambio, ya que necesitan un procesamiento previo antes de su uso.
    Orbling
    25 feb 2011 a las 11:04
  • Estoy de acuerdo y he escrito un analizador JSON en Java, disponible en www.SoftwareMonkey.org, que hace exactamente eso. 28/07/12 a las 1:51
  • 3
    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 de julio de 2013 a las 12:09
  • 29
    "... sería una línea" umm, no, en realidad, JSON no es una gramática regular donde una expresión regular puede simplemente 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. 8 de diciembre de 2013 a las 21:55
  • 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 alternativa a las expresiones regulares ad hoc. Haz eso, no esto. 7 de agosto de 2014 a las 19:32
45

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

//"name": "string"

//"id": int

o

/* This is a

comment example */

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.

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 tiene algún 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.

4
  • Es difícil entender por qué alguien tendría problemas para declarar un hecho.
    dvdmn
    29/07/14 a las 14:17
  • 1
    Asumiría que alguien hizo una excepción porque lo anterior ya no es JSON o es JSON inválido. Quizás se apaciguaría agregar una breve exención de responsabilidad. 7 de agosto de 2014 a las 18:12
  • 5
    Estoy completamente de acuerdo con usted y, sin embargo, hasta ahora hay 883 votos a favor por la falta de respuesta que solo dice lo obvio. Pureza ideológica valorada por encima de la información útil, eso es TAN para ti.
    John
    20/0814 a las 16:48
  • 1
    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 lo es, la gente intentará analizarlo con el idioma / biblioteca de su 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
    6 de junio de 2019 a las 3:35
38

La idea detrás de JSON es proporcionar un intercambio de datos simple entre aplicaciones. Por lo general, se basan en la web y el idioma 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 esos datos obviamente 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 JSON para obtener más detalles.

4
  • 24
    Es cierto que el formato JSON no tiene comentarios. Personalmente, creo que es un error importante: 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 se descartaron. : - /
    StaxMan
    1 de septiembre de 2009 a las 18:20
  • 5
    @StaxMan se eliminaron exactamente porque la gente comenzó a usarlos como metadatos. Crockford dijo que rompió la compatibilidad para lo que se diseñó el formato, y estoy de acuerdo: si desea metadatos, ¿por qué no incluirlos como datos reales? Es incluso más fácil analizar de esta manera. 11/12/10 a las 9:03
  • 7
    Los metadatos pertenecen a construcciones de metadatos (por ejemplo, etiquetas HTML <meta>), no a comentarios. Abusar de los comentarios para los metadatos es solo un truco que se usa donde no existe una verdadera construcción de metadatos. 6 de septiembre de 2011 a las 4:55
  • Esa es exactamente la razón por la que se eliminó: los comentarios utilizados como metadatos romperían la interoperabilidad. También debería almacenar sus metadatos como JSON. 25 de junio de 2013 a las 14:50
36

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

JSON does not have comments. A JSON encoder MUST NOT output comments. A JSON decoder MAY accept and ignore comments.

Comments should never be used to transmit anything meaningful. That is what JSON is for.

Cf: Douglas Crockford, autor de JSON spec .

1
  • 5
    Crockford luego pasó a escribir: "Suponga que está usando 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 entregárselo a su analizador JSON". Consulte la respuesta de @kyle-simpson sobre JSON.minify para obtener más información. 7 de agosto de 2014 a las 19:14
34

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

JSON puede hacer todo lo que puede hacer, pero es mucho menos detallado y más 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 son a menudo una necesidad 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 se podría usar "#": "comment", para JSON "válido".

4
  • 5
    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. 19/10/11 a las 21:35
  • @Hamidam Más de una docena de idiomas admiten yaml: yaml.org , pero tiene razón al preguntar cuántos tienen soporte integrado, sin la necesidad de una dependencia de biblioteca de terceros. Parece que Ruby 1.9.2 lo hace. ¿Alguien sabe de otros? ¿Y qué idiomas ofrecen soporte para json de forma predeterminada?
    nealmcb
    21/03/12 a las 15:53
  • 5
    La interoperabilidad YAML es una mentira: stackoverflow.com/questions/450399/… . Si su instinto es usar JSON para archivos de configuración, sígalo. 7 de agosto de 2014 a las 19:10
  • Esto es antiguo, pero creo que usar # no es una buena idea. Json está cerca de la sintaxis de un lenguaje literal de Javascript. Javascript admite 2 tipos de comentarios: // y / * ... * / Si yo fuera usted, me quedaría con uno o ambos tipos de comentarios. 2 dic 2015 a las 18:24
33

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

Consulte otra pregunta de Stack Overflow .

1
  • Y creo que es por eso que veo un comentario en una captura de pantalla en esta página de vista previa de ASP.NET vNext (en package.json): blogs.msdn.com/b/webdev/archive/2014/06/03/… aunque no tengo Todavía no encontré nada en la especificación.
    webXL
    17 de septiembre de 2014 a las 21:54
32

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 cuando comunican datos (sean válidos o no), entonces 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 al comentario hecho por Douglas Crockford sobre este tema (referenciado por @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.

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

Seguro que un minify específico de JSON se puede implementar en cualquier idioma, pero estandarícelo para que se vuelva 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 para ello, 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 la eliminación de comentarios de los archivos de texto.

El otro problema es la interoperabilidad. Suponga que tiene una biblioteca o API o cualquier tipo de subsistema que tiene algunos archivos de configuración o datos asociados. Y se puede acceder a este subsistema desde diferentes idiomas. Luego, continúe diciéndole a la gente: por cierto, ¡no olvide eliminar los comentarios de los archivos JSON antes de pasarlos al analizador!

1
  • No es necesario fragmentar JSON. JSON con comentarios ya no es JSON. Pero es perfectamente aceptable anotar su JSON con comentarios, siempre que se asegure de eliminarlos antes de analizarlo o transmitirlo. Nunca debería ser responsabilidad del receptor hacer esto. 7 de agosto de 2014 a las 19:19
32

Si usa JSON5 , puede incluir comentarios.


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

3
  • 5
    ¿Podría agregar un ejemplo? Entonces es posible que realmente necesite esos caracteres adicionales. 17 dic 2015 a las 0:15
  • 6
    Es requerido por las pautas de SO para proporcionar una respuesta real. No se desean respuestas de solo enlace. Puede consultar las pautas stackoverflow.com/help/how-to-answer 29/12/15 a las 20:06
  • 2
    SO es moderado por sus usuarios. Eso significa que puedo dar una respuesta si la tengo de la misma manera que puedo comentar la suya si no sigue las pautas. Así es como SO se convierte en un gran recurso. 30/12/15 a las 11:21
26

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 JSON a través de la dojo.xhrGet()llamada.

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

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

4
  • 4
    No. No esto. JSON no tiene comentarios. Si elige anotar su JSON con comentarios, minimícelo antes de analizarlo o transmitirlo. Esto no debería ser responsabilidad del receptor. 7 de agosto de 2014 a las 19:31
  • 2
    No dije que JSON tiene comentarios. Tampoco quise dar a entender que es apropiado incluirlos en su JSON, especialmente en un sistema de producción. Dije que el kit de herramientas de Dojo te permite agregarlos, lo cual es (o al menos, era) de hecho cierto. Existen casos de uso muy útiles para hacerlo en su fase de prueba.
    David
    7 de agosto de 2014 a las 23:37
  • 1
    Es un mal vudú servir JSON comentado y, por lo tanto, inválido, que dojo.xhrGet()implícitamente alienta al aceptar. 8 de agosto de 2014 a las 20:21
  • Sigo votando por actualizar la especificación JSON para permitir comentarios. Estoy totalmente a favor de minificar y eliminar los comentarios antes de transmitir el JSON, pero no tengo la capacidad de comentar su JSON de ninguna manera estándar sin tener que pasarlo a través de 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. 15 de septiembre de 2014 a las 7:03
24

JSON no es un protocolo enmarcado . Es un formato libre de idiomas . Entonces, el formato de un comentario no está definido para JSON.

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

23

Descargo de responsabilidad: esto es una tontería

En realidad, hay una manera de agregar comentarios y permanecer dentro de la especificación (no se necesita un analizador adicional). Sin embargo, no resultará en comentarios legibles por humanos sin ningún tipo de análisis.

Podría abusar de lo siguiente:

Insignificant whitespace is allowed before or after any token. Whitespace is any sequence of one or more of the following code points: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (U+0020).

De una 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 espacios 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 salto de línea y para 2 use retorno de carro.

Esto solo te dejará con una gran cantidad de espacios en blanco ilegibles (a menos que crees un complemento IDE para codificarlo / decodificarlo sobre la marcha).

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

1
  • Esto es muy gracioso.
    Evert
    21 de marzo a las 2:57
23

, el nuevo estándar JSON5 permite los comentarios al estilo C ++, entre muchas otras extensiones :

// A single line comment.

/* A multi-
   line comment. */

El formato de intercambio de datos JSON5 (JSON5) es un superconjunto de JSON que tiene como objetivo aliviar algunas de las limitaciones de JSON. Es totalmente compatible con versiones anteriores, y usarlo probablemente sea mejor que escribir el analizador no estándar personalizado, activar funciones no estándar para el existente o usar varios trucos como campos de cadena para comentar. O, si el analizador en uso lo admite, simplemente acepte que estamos usando el subconjunto JSON 5 que son comentarios de estilo JSON y C ++ . Es mucho mejor que modificar el estándar JSON de la manera que mejor nos parezca .

Ya hay un paquete npm , un paquete Python , un paquete Java y una biblioteca C disponibles. Es compatible con versiones anteriores. No veo ninguna razón para quedarme con las restricciones JSON "oficiales".

Creo que la eliminación de comentarios de JSON ha sido impulsada por las mismas razones que la eliminación de la sobrecarga del operador en Java: se puede usar de manera incorrecta, pero se pasaron por alto algunos casos de uso claramente legítimos. Para la sobrecarga de operadores, es álgebra matricial y números complejos. Para los comentarios JSON, se trata de archivos de configuración y otros documentos que pueden ser escritos, editados o leídos por humanos y no solo por el analizador.

4
  • ¿JSON5 es "muy" estándar? ¿O sigue siendo adoptado? Quiero decir ... ¿Puedo esperar que cualquier marco en 2021 entienda Json5? ¿O probablemente no? 28 mar a las 13:53
  • Si crea su propio estándar, es el único en el mundo que lo usa. Algo como JSON5 probablemente sea mejor. 28 mar a las 21:09
  • No es mi intención crear mi estándar ... solo me pregunto si es hora de considerar JSON5 o mejor seguir con el "viejo JSON" y esperar unos meses antes de dedicar tiempo a la exploración. 29 mar a las 19:00
  • JSON5 no es "el nuevo estándar", es un estándar independiente desarrollado por personas independientes.
    zkldi
    3 de agosto a las 16:51
22

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

No, no debe usar miembros de objeto duplicados para rellenar 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 en un JSON válido, aquí tiene 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 "Se permiten espacios en blanco antes o después de cualquiera de los seis caracteres estructurales".

* El RFC solo establece que "se permiten espacios 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 se ignora en TODAS las implementaciones.


Primero, canonicaliza tu JSON minificándolo:

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

Luego codifique su comentario en binario:

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

Luego, configure su binario:

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

Aquí está su salida:

$jsonWithComment = $steg . $jsonMin;
4
  • 2
    El RFC solo establece que "se permiten espacios en blanco 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. 24 de septiembre de 2014 a las 18:15
  • 1
    Para una mayor densidad de comentarios, ¿no podría codificar su comentario en ternario y usar espacio, tabulación y nueva línea para clasificarlo? 26/09/18 a las 19:44
  • DEBERÍA no DEBE. Consulte el RFC 2119 incluido explícitamente: DEBE: Esta palabra, o los términos "REQUERIDO" o "DEBERÁ", significan 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 entenderse y sopesarse cuidadosamente antes de elegir un curso diferente.
    Jeff K
    23/09/19 a las 18:04
  • 1
    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 tal 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é claves se usaron ya. 26/09/19 a las 20:22
22

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 sigue el enlace, verá

?(/* 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 silenciosamente debido a los comentarios.

Finalmente, envié 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, por lo que tuve que eliminar los comentarios.

21

JSON no permite comentarios, per se. El razonamiento es completamente tonto, porque puede usar JSON en sí mismo para crear comentarios, lo que obvia el razonamiento por completo y carga el espacio de datos del analizador sin ninguna buena razón para exactamente el mismo resultado y problemas potenciales, como son: un JSON archivo con comentarios.

If you try to put comments in (using // or /* */ or # for instance), then some parsers will fail because this is strictly not within the JSON specification. So you should never do that.

Aquí, por ejemplo, donde mi sistema de manipulación de imágenes ha guardado notaciones de imagen 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."
    }
}
4
  • El vínculo del "razonamiento" está roto. ¿Alguna posibilidad de encontrar un enlace actual? 23/04/19 a las 17:05
  • Don, desafortunadamente, Google ha eliminado el sistema de redes sociales que contenía la publicación; No tengo idea de a dónde fue el póster original desde allí, si es que lo hizo. Sin embargo, eliminaré el enlace en la información anterior para eliminar la ambigüedad. Gracias.
    fyngyrz
    24/04/19 a las 13:50
  • El razonamiento no es tonto y lo acaba de demostrar. La implementación de comentarios como etiquetas preserva la interoperabilidad . Esta es exactamente la razón por la que Crockford quería que los comentarios se analizaran como etiquetas. Ahora todo es solo una etiqueta y se analiza de la misma manera . 14/07/19 a las 16:30
  • 1
    Si la especificación indica que "una línea que comienza con # es un comentario", entonces sería completamente interoperable. Tal como está, 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 de la falta. de comentarios en .json, solo desventajas.
    fyngyrz
    28/01/20 a las 14:41
21

En mi caso, necesito usar comentarios con fines de depuración justo antes de la salida del JSON. Así que puse 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í

16

Estamos usando 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'}
3
  • 2
    Tenga en cuenta que jsonya no es un JSON válido cuando incluye estos comentarios de propiedad. 31/07/19 a las 12:12
  • ¿En qué contexto se ejecuta strip-json-comments? Node.js? 8/10/20 a las 17:06
  • @PeterMortensen probé con node.js. puede probar si funciona en js del lado del cliente.
    Joy
    8/10/20 a las 23:44