Os comentários podem ser usados em JSON?
https://stackoverflow.com/questions/244777
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Posso usar comentários dentro de um arquivo JSON?Se sim, como?
Solução
Não.
O JSON deve ser todos dados e, se você incluir um comentário, também serão dados.
Você poderia ter um elemento de dados designado chamado "_comment" (ou algo assim) que seria ignorado por aplicativos que usam os dados JSON.
Você provavelmente seria melhor ter o comentário nos processos que gera/recebe o JSON, pois eles deveriam saber quais os dados do JSON serão com antecedência, ou pelo menos a estrutura dele.
Mas se você decidiu:
{
"_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"
}
}
}
}
}
Outras dicas
Não, comentários da forma //… ou /*…*/ não são permitidos no JSON. Esta resposta é baseada em:
- http://www.json.org
- RFC 4627: O
application/jsonTipo de mídia para JavaScript Object Notation (JSON) - RFC 7159 O Javascript Object Notation (JSON) Formato de intercâmbio - Obsoletes: 4627, 7158
Inclua comentários se você escolher; Retire -os com um minificador antes de analisar ou transmitir.
Acabei de liberar Json.Minify () que retira comentários e espaço em branco de um bloco de JSON e o torna válido JSON que pode ser analisado. Então, você pode usá -lo como:
JSON.parse(JSON.minify(my_str));
Quando o liberei, recebi uma enorme reação de pessoas discordando até da ideia, então decidi que escreveria um post abrangente sobre o porquê Comentários fazem sentido em JSON. Inclui este comentário notável do Criador de JSON:
Suponha que você esteja usando o JSON para manter os arquivos de configuração, que você gostaria de anotar. Vá em frente e insira todos os comentários que você gosta. Em seguida, passe -o através do JSMIN antes de entregá -lo ao seu analisador JSON. - Douglas Crockford, 2012
Espero que seja útil para aqueles que discordam do porquê Json.Minify () pode ser útil.
Os comentários foram removidos do JSON pelo design.
Eu removi comentários do JSON porque vi as pessoas os usavam para realizar diretrizes de análise, uma prática que teria destruído a interoperabilidade. Eu sei que a falta de comentários deixa algumas pessoas tristes, mas não deveria.
Suponha que você esteja usando o JSON para manter os arquivos de configuração, que você gostaria de anotar. Vá em frente e insira todos os comentários que você gosta. Em seguida, passe -o através do JSMIN antes de entregá -lo ao seu analisador JSON.
Isenção de responsabilidade: sua garantia é anulada
Como foi apontado, esse hack aproveita a implementação das especificações. Nem todos os analisadores JSON entenderão esse tipo de JSON. Os analisadores de streaming em particular irão engasgar.
É uma curiosidade interessante, mas você realmente não deveria estar usando nada para nada. Abaixo está a resposta original.
Encontrei um pequeno hack que permite colocar comentários em um arquivo JSON que não afetará a análise ou alterará os dados que estão sendo representados de forma alguma.
Parece que, ao declarar um objeto literal, você pode especificar dois valores com a mesma chave, e o último tem precedência. Acredite ou não, acontece que os analisadores JSON funcionam da mesma maneira. Portanto, podemos usar isso para criar comentários no JSON de origem que não estarão presentes em uma representação de objeto analisado.
({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length;
// => 1
Se aplicarmos esta técnica, seu arquivo JSON comentado pode ficar assim:
{
"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]
}
O código acima é JSON válido. Se você analisar, você receberá um objeto como este:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
O que significa que não há vestígios dos comentários, e eles não terão efeitos colaterais estranhos.
Hacking feliz!
JSON não suporta comentários. Também nunca se destinou a ser usado para arquivos de configuração onde seriam necessários comentários.
HJSON é um formato de arquivo de configuração para humanos. Sintaxe relaxada, menos erros, mais comentários.
Ver hjson.org Para JavaScript, Java, Python, Php, Rust, Go, Ruby e C# Bibliotecas.
Considere usar YAML. É quase um superconjunto do JSON (praticamente todo o JSON válido é um YAML válido) e permite comentários.
Você não pode. Pelo menos essa é a minha experiência de uma rápida olhada em json.org.
O JSON possui sua sintaxe visualizada nessa página. Não há nota sobre comentários.
Você deveria escrever um Esquema JSON em vez de. Atualmente, o JSON Schema é uma especificação de rascunho da Internet proposta. Além da documentação, o esquema também pode ser usado para validar seus dados JSON.
Exemplo:
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
Você pode fornecer documentação usando o Descrição atributo de esquema.
Se você está usando Jackson Como seu analisador JSON, é assim que você o permite permitir comentários:
ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
Então você pode ter comentários assim:
{
key: "value" // Comment
}
E você também pode ter comentários começando com # definindo:
mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
Mas em geral (conforme respondido antes), a especificação não permite comentários.
Os comentários não são um padrão oficial.Embora alguns analisadores suportem comentários no estilo C.Um que eu uso é JSONCpp.Nos exemplos há 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 não valida isso.Portanto, os comentários são uma extensão específica do analisador e não um padrão.
Outro analisador é JSON5.
Uma alternativa ao JSON TOML.
Outra alternativa é jsonc.
Aqui está o que eu encontrei no Documentação do Google Firebase Isso permite que você coloque comentários no 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"
}
Se o seu arquivo de texto, que é uma string JSON, for lido por algum programa, quão difícil seria remover os comentários no estilo C ou C++ antes de usá-lo?
Responder: Seria uma linha única.Se você fizer isso, os arquivos JSON poderão ser usados como arquivos de configuração.
Se você estiver usando a biblioteca Newtonsoft.json com o ASP.NET para ler/Deserialize, você pode usar comentários no conteúdo JSON:
// "Nome": "String"
//"eu não fiz
ou
/* Isto é um
Exemplo de comentar */
PS: Os comentários de linha única são suportados apenas com mais de 6 versões do Newtonsoft JSON.
Nota adicional para pessoas que não conseguem pensar fora da caixa: Eu uso o formato JSON para configurações básicas em um aplicativo Web ASP.NET que fiz. Eu li o arquivo, converto -o no objeto Configurações com a biblioteca Newtonsoft e uso -o quando necessário.
Prefiro escrever comentários sobre cada configuração individual no próprio arquivo JSON, e realmente não me importo com a integridade do formato JSON, desde que a biblioteca que eu uso seja boa com ele.
Eu acho que essa é uma maneira 'mais fácil de usar/entender' do que criar um arquivo 'Settings.readMe' separado e explicar as configurações nele.
Se você tiver um problema com esse tipo de uso; Desculpe, o gênio está fora da lâmpada. As pessoas encontrariam outros usos para o formato JSON, e não há nada que você possa fazer sobre isso.
A idéia por trás do JSON é fornecer troca de dados simples entre aplicativos. Normalmente, são baseados na Web e o idioma é JavaScript.
No entanto, ele realmente não permite comentários, no entanto, passar um comentário como um dos pares de nome/valor nos dados certamente funcionaria, embora esses dados obviamente precisem ser ignorados ou tratados especificamente pelo código de análise.
Tudo isso dito, não é intenção que o arquivo JSON contenha comentários no sentido tradicional. Deve ser apenas os dados.
Dê uma olhada no Site JSON Para mais detalhes.
Eu apenas encontro isso para arquivos de configuração. Eu não quero usar Xml (Formato verboso, graficamente, feio, difícil de ler) ou "ini" (sem hierarquia, sem padrão real etc.) ou formato de "propriedades" java "(como .ini).
O JSON pode fazer tudo o que pode fazer, mas é muito menos detalhado e mais legível humano - e os analisadores são fáceis e onipresentes em muitos idiomas. É apenas uma árvore de dados. Mas os comentários fora da banda são uma necessidade geralmente para documentar as configurações "padrão" e similares. As configurações nunca devem ser "documentos completos", mas árvores de dados salvos que podem ser legíveis humanos quando necessário.
Eu acho que alguém poderia usar "#": "comment", para JSON "válido".
JSON não suporta comentários nativamente, mas você pode criar seu próprio decodificador ou pelo menos pré-processador para remover comentários, isso é perfeitamente aceitável (desde que você simplesmente ignore os comentários e não os use para orientar como seu aplicativo deve processar os dados JSON ).
JSON não possui comentários.Um codificador JSON NÃO DEVE gerar comentários.Um decodificador JSON PODE aceitar e ignorar comentários.
Os comentários nunca devem ser usados para transmitir algo significativo.É para isso que serve a JSON.
Depende da sua biblioteca JSON. Json.net suporta comentários no estilo JavaScript, /* commment */.
O JSON faz muito sentido para arquivos de configuração e outro uso local, porque é onipresente e porque é muito mais simples que o XML.
Se as pessoas tiverem fortes razões contra os comentários no JSON ao comunicar dados (válidos ou não), possivelmente o JSON poderá ser dividido em dois:
- JSON-COM: JSON no fio, ou regras que se aplicam ao comunicar dados JSON.
- JSON-Doc: JSON Document, ou JSON em arquivos ou localmente. Regras que definem um documento JSON válido.
O JSON-DOC permitirá comentários e outras pequenas diferenças podem existir, como lidar com o espaço em branco. Os analisadores podem converter facilmente de uma especificação para a outra.
Com relação ao observação Feito por Douglas Crockford sobre essas questões (referenciadas por @artur czajka)
Suponha que você esteja usando o JSON para manter os arquivos de configuração, que você gostaria de anotar. Vá em frente e insira todos os comentários que você gosta. Em seguida, passe -o através do JSMIN antes de entregá -lo ao seu analisador JSON.
Estamos falando de um problema genérico de arquivo de configuração (idioma/plataforma cruzado) e ele está respondendo com um utilitário específico do JS!
Claro que um Minify específico do JSON pode ser implementado em qualquer idioma, mas padronize isso para que se torne onipresente entre os analisadores em todos os idiomas e plataformas, para que as pessoas parem de desperdiçar seu tempo sem o recurso porque têm boas casas de uso, olhando o problema em Fóruns on -line, e levar as pessoas dizendo a eles que é uma má ideia ou sugerindo que é fácil implementar os comentários retirando os arquivos de texto.
A outra questão é a interoperabilidade. Suponha que você tenha uma biblioteca ou API ou qualquer tipo de subsistema que tenha alguns arquivos de configuração ou dados associados a ela. E este subsistema deve ser acessado de diferentes idiomas. Então você diz às pessoas: a propósito, não se esqueça de retirar os comentários dos arquivos JSON antes de passar para o analisador!
O Dojo Toolkit JavaScript Toolkit (pelo menos a partir da versão 1.4) permite que você inclua comentários em seu JSON. Os comentários podem ser de /* */ formato. Dojo Toolkit consome o JSON através do dojo.xhrGet() ligar.
Outros kits de ferramentas JavaScript podem funcionar da mesma forma.
Isso pode ser útil ao experimentar estruturas de dados alternativas (ou mesmo listas de dados) antes de escolher uma opção final.
Se você usar JSON5 Você pode incluir comentários.
JSON5 é uma extensão proposta para JSON Isso pretende facilitar para os humanos escrever e manter manualmente. Faz isso adicionando alguns recursos mínimos de sintaxe diretamente do ECMAScript 5.
JSON não é um protocolo emoldurado. É um Formato livre de idiomas. Portanto, o formato de um comentário não é definido para JSON.
Como muitas pessoas sugeriram, existem alguns truques, por exemplo, chaves duplicadas ou uma chave específica _comment que você pode usar. Você decide.
Você posso tenha comentários em JSONP, mas não em puro json. Acabei de passar uma hora tentando fazer meu programa funcionar com este exemplo da HighCharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Se você seguir o link, você 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 eu tinha um arquivo semelhante na minha pasta local, não houve problemas com o Política da mesma origem, então eu decidi usar o puro json ... e, claro, $.getJSON estava falhando em silêncio por causa dos comentários.
Eventualmente, acabei de enviar uma solicitação manual http para o endereço acima e percebi que o tipo de conteúdo era text/javascript Desde que, bem, o JSONP retorna JavaScript puro. Neste caso, comentários são autorizadas. Mas meu aplicativo retornou o tipo de conteúdo application/json, então eu tive que remover os comentários.
JSON costumava dar suporte a comentários, mas eles foram abusados e removidos do padrão.
Do criador do JSON:
Removi comentários do JSON porque vi que as pessoas os usavam para manter diretivas de análise, uma prática que teria destruído a interoperabilidade.Eu sei que a falta de comentários deixa algumas pessoas tristes, mas não deveria.- Douglas Crockford, 2012
O site oficial do JSON está em JSON.org.JSON é definido como um padrão pela ECMA Internacional.Sempre há um processo de petição para revisão dos padrões.É improvável que anotações sejam adicionadas ao padrão JSON por vários motivos.
JSON por design é uma alternativa de fácil engenharia reversa (analisada por humanos) ao XML.É simplificado a ponto de as anotações serem desnecessárias.Não é nem mesmo uma linguagem de marcação.O objetivo é estabilidade e interoperabilidade.
Qualquer pessoa que entenda o relacionamento "tem um" da orientação a objetos pode entender qualquer estrutura JSON - esse é o ponto principal.É apenas um gráfico acíclico direcionado (DAG) com tags de nó (pares chave/valor), que é uma estrutura de dados quase universal.
Esta única anotação necessária pode ser "//Estas são tags DAG".Os nomes das chaves podem ser tão informativos quanto necessário, permitindo aridade semântica arbitrária.
Qualquer plataforma pode analisar JSON com apenas algumas linhas de código.XML requer bibliotecas OO complexas que não são viáveis em muitas plataformas.
As anotações apenas tornariam o JSON menos interoperável.Simplesmente não há mais nada a acrescentar, a menos que você realmente precise de uma linguagem de marcação (XML) e não se importe se seus dados persistentes forem facilmente analisados.
Isto é um "você pode" pergunta. E aqui está um "sim" responda.
Não, você não deve usar membros duplicados do objeto para encher os dados do canal lateral em uma codificação JSON. (Veja "Os nomes dentro de um objeto devem ser únicos" no RFC).
E sim, você poderia Insira comentários por aí o json, que você poderia analisar.
Mas se você deseja uma maneira de inserir e extrair dados arbitrários de canal lateral para um JSON válido, aqui está uma resposta. Aproveitamos a representação não única dos dados em uma codificação JSON. Isso é permitido* Na seção dois da RFC em "O espaço em branco é permitido antes ou depois de qualquer um dos seis caracteres estruturais".
*A RFC afirma apenas "o espaço em branco é permitido antes ou depois de qualquer um dos seis caracteres estruturais", não mencionando explicitamente strings, números, "false", "verdadeiro" e "nulo". Essa omissão é ignorada em todas as implementações.
Primeiro, canonize seu JSON, minimizando -o:
$jsonMin = json_encode(json_decode($json));
Em seguida, codifique seu comentário em binário:
$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);
Então steg seu binário:
$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);
Aqui está sua saída:
$jsonWithComment = $steg . $jsonMin;
Nós estamos usando strip-json-comments para o nosso projeto. Ele suporta algo como:
/*
* Description
*/
{
// rainbows
"unicorn": /* ❤ */ "cake"
}
Simplesmente npm install --save strip-json-comments Para instalá -lo e usá -lo como:
var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}
Para cortar um item JSON em peças, eu adiciono linhas de "comentário fictício":
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
Existe uma boa solução (hack), que é válida JSON. Basta fazer a mesma chave duas vezes (ou mais). Por exemplo:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
Então JSON entenderá isso como:
{
"param" : "This is value place",
}
O autor de JSON quer que incluamos comentários no JSON, mas retire -os antes de analisá -los (veja link fornecido por Michael Burr). Se o JSON deve ter comentários, por que não padronizá -los e deixar o analisador JSON fazer o trabalho? Não concordo com a lógica lá, mas, infelizmente, esse é o padrão. Usar uma solução YAML, conforme sugerido por outros, é bom, mas requer uma dependência da biblioteca.
Se você deseja retirar comentários, mas não quer ter uma dependência da biblioteca, aqui está uma solução de duas linhas, que funciona para comentários de estilo C ++, mas pode ser adaptado a outros:
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));
Observe que esta solução só pode ser usada nos casos em que você pode ter certeza de que os dados JSON não contêm o iniciador de comentários, por exemplo ('//').
Outra maneira de alcançar o JSON Parsing, a remoção de comentários e nenhuma biblioteca extra é avaliar o JSON em um intérprete JavaScript. A advertência com essa abordagem, é claro, é que você só gostaria de avaliar dados não contaminados (sem entrada de usuário não confiável). Aqui está um exemplo dessa abordagem no Node.js - Outra ressalva, o exemplo a seguir só lerá os dados uma vez e, em seguida, serão armazenados em cache:
data = require(fs.realpathSync(doctree_fp));
Suspirar. Por que não adicionar campos, por exemplo
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
Apenas certifique -se de que seus nomes "NOTEX" não conflitem com nenhum campo real.
