¿Se pueden usar los comentarios en JSON?
https://stackoverflow.com/questions/244777
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Puedo usar comentarios dentro de un archivo JSON? Si es así, ¿cómo?
Solución
No.
El JSON debe ser todos datos, y si incluye un comentario, también lo será.
Podría tener un elemento de datos designado llamado " _comment " (o algo) que las aplicaciones que usan los datos JSON ignorarían.
Probablemente sea 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 de JSON, o al menos su estructura.
Pero si decides:
{
"_comment": "comment text goes here...",
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
Otros consejos
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 7159 Formato de intercambio de datos de la notación de objetos de JavaScript (JSON) - Obsoleto: 4627 , 7158
Incluye comentarios si lo eliges; elimínelos con un minificador antes de analizarlos o transmitirlos.
Acabo de publicar JSON.minify () que se elimina comentarios y espacios en blanco de un bloque de JSON y lo convierte en un JSON válido que se puede analizar. Por lo tanto, puede usarlo como:
JSON.parse(JSON.minify(my_str));
Cuando lo lancé, recibí una reacción violenta 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. Anímate e inserta todos los comentarios que quieras. Luego colóquelo en JSMin antes de entregárselo a su analizador JSON. - Douglas Crockford, 2012
Esperamos que sea útil para aquellos que no están de acuerdo con por qué JSON.minify () podría ser útil.
Los comentarios se eliminaron de JSON por diseño.
Eliminé 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.
Suponga que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Anímate e inserta todos los comentarios que quieras. Luego canalícelo a través de JSMin antes de entregárselo a su analizador JSON.
DESCARGO DE RESPONSABILIDAD: SU GARANTÍA ESTÁ NULADA
Como se ha señalado, este hack se aprovecha de la implementación de la especificación. No todos los analizadores JSON entenderán este tipo de JSON. Los analizadores de streaming en particular se ahogarán.
Es una curiosidad interesante, pero realmente no deberías usarla para nada . A continuación se muestra la respuesta original.
He encontrado un pequeño truco que te permite colocar comentarios en un archivo JSON que no afectará el análisis o alterará los datos que se representan de alguna 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 analizas, obtendrás un objeto como este:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
Lo que significa que no hay rastro de los comentarios y que no tendrán efectos secundarios extraños.
¡Feliz piratería!
JSON no admite comentarios. Tampoco fue diseñado para ser utilizado para archivos de configuración donde se necesitarían comentarios.
Hjson es un formato de archivo de configuración para personas. Sintaxis relajada, menos errores, más comentarios.
Consulte hjson.org para ver las bibliotecas de JavaScript, Java, Python, PHP, Rust, Go, Ruby y C #.
Considere usar YAML. Es casi un superconjunto de JSON (prácticamente todos los JSON válidos son YAML válidos) y permite comentarios.
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.
Debería escribir un esquema JSON en su lugar. 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 descripción .
Si está utilizando Jackson como su analizador JSON, esta es la forma en que lo habilita para permitir comentarios:
ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
Entonces puedes tener comentarios como este:
{
key: "value" // Comment
}
Y también puedes tener comentarios que comiencen con # configurando:
mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
Pero en general (como se respondió antes) la especificación no permite comentarios.
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 son estándar.
Otro analizador es JSON5 .
Una alternativa a JSON TOML .
Otra alternativa es jsonc .
Esto es lo que encontré en documentación de Google Firebase que te permite poner comentarios en JSON:
{
"//": "Some browsers will use this to enable push notifications.",
"//": "It is the same for all projects, this is not your project's sender ID",
"gcm_sender_id": "1234567890"
}
Si su archivo de texto, que es una cadena JSON, 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.
Si está utilizando la biblioteca Newtonsoft.Json con ASP.NET para leer / deserializar, puede usar comentarios en el contenido JSON:
// " nombre " ;: " cadena "
// " id " ;: int
o
/ * Este es un
ejemplo de comentario * /
PS: 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. Leí el archivo, lo convertí en el objeto de configuración con la biblioteca de Newtonsoft y lo uso cuando sea necesario.
Prefiero escribir comentarios sobre cada configuración individual en el propio archivo JSON, y realmente no me importa la integridad del formato JSON, siempre y cuando la biblioteca que uso esté de acuerdo.
Creo que esta es una forma 'más fácil de usar / entender' que crear un archivo 'settings.README' separado y explicar la configuración en él.
Si tiene un problema con este tipo de uso; lo siento, el genio está fuera de la lámpara. La gente encontraría otros usos para el formato JSON, y no hay nada que puedas hacer al respecto.
La idea detrás de JSON es proporcionar un intercambio de datos simple entre aplicaciones. Estos son típicamente 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 nombre / valor en los datos ciertamente funcionaría, aunque obviamente los datos deberían ser ignorados o manejados específicamente por el código de análisis .
Dicho todo esto, no es la intención que el archivo JSON contenga comentarios en el sentido tradicional. Solo deben ser los datos.
Eche un vistazo al sitio web JSON para obtener más detalles.
Acabo de encontrar esto para los archivos de configuración. No quiero usar XML (detallado, gráfico, feo, difícil de leer) o "ini" formato (sin jerarquía, sin estándar real, etc.) o Java '' Propiedades '' formato (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 a menudo una necesidad para documentar " default " configuraciones y similares. Las configuraciones nunca deben ser "documentos completos", sino árboles de datos guardados que puedan ser leídos por humanos cuando sea necesario.
Supongo que uno podría usar " # " ;: " comment " , para " válido " JSON.
JSON no admite comentarios de forma nativa, pero puedes crear tu propio decodificador o, al menos, preprocesador para eliminar los comentarios, eso está perfectamente bien (siempre y cuando no hagas caso de los comentarios y no los uses para guiarte en cómo debería procesar tu aplicación) los datos JSON).
JSON no tiene comentarios. Un codificador JSON NO DEBE emitir comentarios. Un decodificador JSON PUEDE aceptar e ignorar comentarios.
Los comentarios nunca deben usarse para transmitir algo significativo. Es decir para qué es JSON.
Depende de tu biblioteca JSON. Json.NET admite comentarios de estilo JavaScript, / * commment * / .
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 (ya 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 la otra.
Con respecto al comentario realizado por Douglas Crockford sobre estos temas (referenciado por @Artur Czajka)
Suponga que está utilizando JSON para mantener los archivos de configuración, que le gustaría anotar. Anímate e inserta todos los comentarios que quieras. Luego canalícelo a través de JSMin antes de entregárselo a su analizador JSON.
Estamos hablando de un problema genérico del archivo de configuración (lenguaje cruzado / plataforma), ¡y está respondiendo con una utilidad específica de JS!
Seguro que se puede implementar una reducción específica de JSON en cualquier idioma, pero estandarice esto 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, buscar el problema en foros en línea y hacer que la gente les diga que es una mala idea o sugiriendo que es fácil implementar la eliminación de comentarios 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 este subsistema es Para acceder desde diferentes idiomas. Entonces vas a decirle a la gente: por cierto ¡no olvide eliminar los comentarios de los archivos JSON antes de pasarlos al analizador!
El kit de herramientas de Dojo Toolkit JavaScript (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 llamada dojo.xhrGet () .
Otros kits de herramientas de JavaScript pueden funcionar de manera similar.
Esto puede ser útil cuando se experimenta con estructuras de datos alternativas (o incluso listas de datos) antes de elegir una opción final.
Si utiliza 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 & nbsp; 5.
JSON no es un protocolo enmarcado . Es un formato libre de idioma . 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 _comment que puede usar. Depende de usted.
Usted puede tener comentarios en JSONP , pero no en puro JSON. Acabo de pasar una hora intentando hacer que mi programa funcione con este ejemplo de Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Si 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]
]);
Ya que tenía un archivo similar en mi carpeta local, no hubo problemas con política , así que decidí usar JSON puro ... y, por supuesto, $ .getJSON estaba fallando silenciosamente debido a los comentarios.
Finalmente, acabo de enviar una solicitud HTTP manual a la dirección anterior y me di cuenta de que el tipo de contenido era text / javascript , ya que, bueno, JSONP devuelve JavaScript puro. En este caso, los comentarios están permitidos . Pero mi aplicación devolvió el tipo de contenido application / json , así que tuve que eliminar los comentarios.
JSON solía admitir comentarios, pero fueron abusados ??y eliminados de la norma.
Del creador de JSON:
Eliminé los comentarios de JSON porque vi que la gente los estaba usando para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios entristece a algunas personas, pero no debería. - Douglas Crockford, 2012
El sitio oficial de JSON se encuentra 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 las anotaciones se agreguen al estándar JSON por varias razones.
JSON por diseño es una alternativa a XML fácilmente diseñada por ingeniería inversa (análisis humano). Se simplifica incluso hasta el punto de que las anotaciones son innecesarias. Ni siquiera es un lenguaje de marcas. El objetivo es la estabilidad y la interoperablilty.
Cualquiera que entienda que " tiene-a " La relación entre 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 requerida podría ser " // Estas son etiquetas DAG " ;. Los nombres de las claves 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.
Esta es una pregunta " can " . Y aquí hay una " sí " respuesta.
No, no debe usar miembros de objetos duplicados para rellenar los datos del canal lateral en una codificación JSON. (Consulte " Los nombres dentro de un objeto DEBEN ser únicos " en el RFC ).
Y sí, podría insertar comentarios alrededor el JSON , que usted podría analizar hacia fuera.
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 debajo de "espacio en blanco" está permitido antes o después de cualquiera de los seis caracteres estructurales ".
* El RFC solo indica 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 " null " ;. Esta omisión se ignora en TODAS las implementaciones.
Primero, canonicaliza tu JSON reduciéndolo:
$jsonMin = json_encode(json_decode($json));
Luego codifica tu comentario en binario:
$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);
Luego apártate de tu binario:
$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);
Aquí está tu salida:
$jsonWithComment = $steg . $jsonMin;
Estamos utilizando strip-json-comments para nuestro proyecto. Soporta algo como:
/*
* Description
*/
{
// rainbows
"unicorn": /* ❤ */ "cake"
}
Simplemente npm install --save strip-json-comments para 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'}
Para cortar un elemento JSON en partes agrego " comentario ficticio " líneas:
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
Hay una buena solución (hack), que es JSON válida. Simplemente haga la misma clave dos veces (o más). Por ejemplo:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
Entonces JSON entenderá esto como:
{
"param" : "This is value place",
}
El autor de JSON desea que incluyamos comentarios en el JSON, pero los eliminamos antes de analizarlos (consulte link proporcionado por Michael Burr). Si JSON debería tener comentarios, ¿por qué no estandarizarlos y dejar que el analizador JSON haga el trabajo? No estoy de acuerdo con la lógica allí, pero, por desgracia, ese es el estándar. Usar una solución YAML como lo sugieren otros es bueno, pero requiere una dependencia de la biblioteca.
Si desea eliminar los comentarios, pero no desea tener una dependencia de la biblioteca, aquí hay una solución de dos líneas, que funciona para los comentarios de estilo C ++, pero se puede adaptar a otros:
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));
Tenga en cuenta que esta solución solo se puede utilizar en los casos en los que puede estar seguro de que los datos JSON no contienen el iniciador de comentarios, por ejemplo. ('//').
Otra forma de lograr el análisis JSON, la eliminación de comentarios y no una biblioteca adicional, es evaluar el JSON en un intérprete de JavaScript. La advertencia con este enfoque, por supuesto, es que solo querría evaluar los datos no contaminados (no la entrada del usuario no confiable). Este es un ejemplo de este enfoque en Node.js: otra advertencia, el siguiente ejemplo solo leerá los datos una vez y luego se almacenará en caché:
data = require(fs.realpathSync(doctree_fp));
Suspiro. ¿Por qué no solo agregar campos, por ejemplo,
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
Solo asegúrese de que su " notex " los nombres no entran en conflicto con ningún campo real.
