Os comentários podem ser usados ​​no JSON?


7611

Posso usar comentários dentro de um arquivo JSON? Se sim, como?


153
@StingyJack: Para explicar coisas que podem não ser óbvias, ou qualquer outra coisa que se possa fazer com comentários. Eu pelo menos tenho comentários em arquivos de dados. XML, arquivos ini e muitos outros formatos incluem disposições para comentários.
Michael Burr

24
Se você, como eu, estava se perguntando se //commentsestá bom para o caso de uso específico de um arquivo de configuração de Texto Sublime, a resposta é sim (a partir da versão 2). O Texto sublime não reclamará, pelo menos, enquanto reclamará {"__comment": ...}no console, porque é um campo inesperado.
Driftcatcher

8
e talvez esta seja uma razão pela qual TOML foi criado ..
Alex Nolasco

10
Um pouco noobish, mas também tentei usar // para comentários em JSON. Agora percebo que é estritamente usado para intercâmbio / troca. Suspiro! Eu não posso comentar mais :( vida está condenada !..
Sid

12
O JSON5 suporta comentários: stackoverflow.com/a/7901053/108238
schoetbi:

Respostas:


5595

Não.

O JSON deve ser todos dados, e se você incluir um comentário, também serão dados.

Você pode ter um elemento de dados designado chamado "_comment"(ou algo assim) que seria ignorado pelos aplicativos que usam os dados JSON.

Você provavelmente seria melhor ter o comentário nos processos que geram / recebem o JSON, pois eles devem saber quais serão os dados JSON com antecedência, ou pelo menos a estrutura deles.

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

232
Pode valer a pena ter algum tipo de prefixo no comentário real, caso haja um campo válido com o nome comment:"__comment":"comment text goes here...",
Rob Fonseca-Ensor

19
BTW, a biblioteca json para Java google-gson tem suporte para comentários.
centic

11
E se eu quisesse um comentário separado sobre as propriedades Accronyme Abbrev? Eu usei esse padrão antes, mas parei, pois ele não me permite fazer isso. É um truque. Talvez se eu prefixo um nome de propriedade __comment__. Isso é "__comment__Abbrev", ainda um hack, mas gostaria de comentar todas as propriedades
Juan Mendes

41
você também pode usar "//": Isso parece mais nativa e ainda é repetível no mesmo pai
smnbbrv

4
Quando o JSON é usado para arquivos de configuração destinados a humanos, eles devem ser anotados para que os humanos compreendam melhor. Anotado, esse arquivo não é mais JSON válido, mas existem soluções. Por exemplo, o GYP do Google suporta comentários no estilo #. O JSON.Minify ajudará você a descartar comentários no estilo C / C ++ do seu arquivo de entrada.
Петър Петров

1842

Não , comentários do formulário //…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 8259 O formato de intercâmbio de dados da JavaScript Object Notation (JSON) (substitui as RFCs 4627, 7158, 7159)

67
Se você deseja anotar seu JSON com comentários (tornando-o inválido para JSON), minimize-o antes de analisar ou transmitir. O próprio Crockford reconheceu isso em 2012 no contexto dos arquivos de configuração.
#

25
@alkuzad: Quando se trata de gramáticas formais, deve haver algo que diga explicitamente que são permitidas, e não o contrário. Por exemplo, escolha sua linguagem de programação preferida: apenas porque algum recurso desejado (mas ausente) não é explicitamente proibido, não significa que seu compilador o reconhecerá magicamente.
stakx - não está mais contribuindo em

5
Sim. O formato JSON possui muito espaço morto entre elementos e não faz distinção de espaço nessas regiões, portanto, não há razão para que você não possa ter comentários únicos ou multilinhas lá. Muitos analisadores e minificadores também suportam comentários JSON, portanto, verifique se o analisador os suporta. O JSON é muito usado para dados de aplicativos e definições de configuração, portanto, comentários são necessários agora. A "especificação oficial" é uma boa idéia, mas é insuficiente e obsoleta, muito ruim. Minimize seu JSON se estiver preocupado com o tamanho ou o desempenho da carga útil.
Triynko

58
Embora sua resposta esteja absolutamente correta, deve-se dizer que isso é BS. Com tantos usuários finais passando pela necessidade da configuração do json, os comentários são extremamente úteis. Só porque alguns chapéus de papel alumínio decidiram que o JSON é e sempre deve ser legível por máquina, ignorando o fato de que os humanos precisam lê-lo, é como uma farsa de uma mente pequena.
Cmroanirgo

18
@cmroanirgo: Você obviamente não é o primeiro a reclamar sobre essa limitação do JSON ... é por isso que temos analisadores que silenciosamente permitem comentários e outros formatos como YAML e JSON5. No entanto, isso não muda o fato de que JSON é o que é. Em vez disso, acho interessante que as pessoas tenham começado a usar o JSON para fins em que claramente não era suficiente em primeiro lugar, dada a limitação em questão. Não culpe o formato JSON; nos culpamos por insistir em usá-lo onde não é particularmente adequado.
stakx - não contribui mais com

802

Inclua comentários se você escolher; retire-os com um minificador antes de analisar ou transmitir.

Acabei de lançar o JSON.minify (), que retira comentários e espaços em branco de um bloco de JSON e torna JSON válido que pode ser analisado. Então, você pode usá-lo como:

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

Quando o libertei, recebi uma enorme reação das pessoas que discordavam até da ideia, então decidi escrever um post abrangente sobre por que os comentários fazem sentido no JSON . Inclui este comentário notável do criador do JSON:

Suponha que você esteja usando 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 pelo JSMin antes de entregá-lo ao seu analisador JSON. - Douglas Crockford, 2012

Espero que seja útil para aqueles que discordam do porquê JSON.minify () poderia ser útil.


153
O único problema que tenho com JSON.minify () é que é realmente muito lento. Então, eu fiz minha própria implementação que faz a mesma coisa: gist.github.com/1170297 . Em alguns arquivos de teste grandes, sua implementação leva 74 segundos e a minha, 0,06 segundos.
WizKid

56
seria ótimo se você pudesse enviar o algoritmo alternativo sugerido ao repositório do github para JSON.minify (), para que ele possa ser portado para todos os idiomas suportados: github.com/getify/json.minify
Kyle Simpson

16
@MiniGod Eu já ouvi os pensamentos de Doug sobre esse assunto muitas vezes. I se dirigiu a eles há muito tempo no meu blog: blog.getify.com/json-comments
Kyle Simpson

18
@ MarnenLaibow-Koser ainda existem usos válidos para comentários, mesmo para uso de fluxo de dados (ou mesmo pacote): a inclusão de metadados de diagnóstico, como horário ou fontes de criação, é comum no XML e é perfeitamente sensível aos dados JSON. Argumentos contra comentários são rasas, e qualquer formato de dados textuais devem permitir comentários, independentemente do uso pretendido implícita (nada especs sugerem JSON não pode ser usado em outros lugares, fwiw)
StaxMan

18
Se o JSON tiver aceitação universal (o que basicamente acontece), ele deverá ter aplicação universal. Exemplo: JSON pode servir como um arquivo de configuração do aplicativo. Esta aplicação gostaria de comentários.
eggmatters 27/01

441

Os comentários foram removidos do JSON por design.

Eu removi os comentários do JSON porque vi que as pessoas os estavam usando para manter diretivas de análise, uma prática que teria destruído a interoperabilidade. Sei que a falta de comentários deixa algumas pessoas tristes, mas não deveria.

Suponha que você esteja usando 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 pelo JSMin antes de entregá-lo ao seu analisador JSON.

Fonte: declaração pública de Douglas Crockford no G +


198
Eu pensei que o JSON deveria ser mais legível por humanos do que, digamos, XML? Os comentários são para facilitar a leitura.
Intrepidis

25
De qualquer forma, você pode ser impertinente e adicionar diretivas de análise no JSON: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Parece YAML é o caminho a seguir, então ...
intrepidis

73
Opinião pessoal: não permitir comentários É coxo. Eu não tinha outra opção além de criar um analisador JSON não padrão que ignore comentários, para decodificar meus arquivos de configuração.
caiosm1005

17
@ArturCzajka Ainda não gosto do fato de o JSON não suportar comentários, mas tentei o INI e devo admitir que faz muito mais sentido usá-los no JSON para arquivos de configuração. Obrigado pela resposta e espero que mais pessoas mudem de idéia ao lerem essa conversa. (fazendo um analisador foi mais um exercício de qualquer maneira :)
caiosm1005

77
É como exigir que todas as bicicletas tenham rodinhas de treinamento, porque algumas pessoas não podem andar de bicicleta. Remover um recurso importante porque pessoas estúpidas abusam é um design ruim. Um formato de dados deve priorizar a usabilidade em vez de ser à prova de idiotas.
Phil Goetz 14/05

205

AVISO LEGAL: SUA GARANTIA É ANULADA

Como foi apontado, esse hack tira vantagem da implementação das especificações. Nem todos os analisadores JSON entenderão esse tipo de JSON. Os analisadores de streaming, em particular, engasgam.

É uma curiosidade interessante, mas você realmente não deve usá-lo para nada . Abaixo está a resposta original.


Eu encontrei um pequeno truque 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 qualquer forma.

Parece que, ao declarar um literal de objeto, você pode especificar dois valores com a mesma chave, e o último tem precedência. Acredite ou não, verifica-se 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 analisada.

({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
// => 1

Se aplicarmos essa técnica, seu arquivo JSON comentado poderá ser 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ê analisá-lo, obterá 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 nos comentários e eles não terão efeitos colaterais estranhos.

Feliz hacking!


150
A partir da especificação : Os nomes dentro de um objeto devem ser únicos.
Quentin

113
"todas as implementações lidam da mesma forma" - Isso é algo difícil de provar.
Quentin

91
A ordem dos elementos no JSON não é garantida. Isso significa que o "último" item pode mudar!
sep332

66
Isso claramente viola as especificações (veja os comentários acima), não faça isso. ietf.org/rfc/rfc4627.txt?number=4627
voidlogic

334
NÃO - e se o analisador estiver transmitindo? E se o analisador o ler em um dicionário em que a ordem das chaves é indefinida? mate isso com fogo .
precisa saber é o seguinte

183

JSON não suporta comentários. Também nunca foi planejado para ser usado em arquivos de configuração nos quais seriam necessários comentários.

Hjson é um formato de arquivo de configuração para humanos. Sintaxe relaxada, menos erros, mais comentários.

Introdução ao Hjson

Veja hjson.org para bibliotecas JavaScript, Java, Python, PHP, Rust, Go, Ruby e C #.


13
Votado. É obviamente uma boa variação que pessoas conservadoras não abertas adorariam odiar. Espero que sua implementação seja mais conhecida - e talvez até se torne mais popular que a original;) ​​Espero que alguém também a implemente com Ruby. @adelphus A linguagem que está sendo bem definida é a sua própria perspectiva ou opinião. Ser um "desenvolvedor" conservador se você é um não prova que é melhor e pode ser ainda pior mantendo-se trancado em espaços limitados. Não julgue as pessoas como desenvolvedores terríveis facilmente.
konsolebox

7
Desculpe por isso, @konsolebox. Talvez você possa reconsiderar sua visualização "JSON bem definido é sua opinião" depois de ler ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf É um padrão real e os desenvolvedores implementam suas próprias versões "especiais" leva à fragmentação, confusão e muito tempo perdido. Observe a bagunça que os desenvolvedores da Web ficam quando escrevem código apenas porque cada navegador implementa versões ligeiramente diferentes dos padrões. A linguagem JSON pode não ser perfeita, mas a fragmentação é pior. E sim, isso é apenas uma opinião e você pode discordar.
9138 adelphus

22
Admiro seu bom senso, mas você está meio que reinventando o YAML. Se você deseja muita flexibilidade e legibilidade humana, use o YAML (na verdade não: stackoverflow.com/questions/450399/… ) ou use a linguagem convencional, mas o JSON inequívoco.
#

4
Acho que o formato de configuração mais amigável ainda é o INI. É simples e não tem muita sintaxe. Isso torna menos intimidante para os usuários apenas mergulhando os dedos dos pés no lago de configuração.
Matt

14
Sempre que precisar de json como config (onde os comentários são necessários) - nomear o arquivo ".js" em vez de ".json" .. js pode, naturalmente, lidar com qualquer objeto JSON válida e, adicionalmente, pode lidar com comentários .. Essa é a razão pela qual é "webpack.config.js" e não "webpack.config.json" (bem há muito mais razões para que também em Webpack: P)
jebbie

122

Considere usar o YAML. É quase um superconjunto de JSON (praticamente todo JSON válido é YAML válido) e permite comentários.


12
@ g33kz0r Correto, portanto, minha descrição do YAML como um superconjunto do JSON.
Marnen Laibow-Koser 12/09/12

12
@NateS Muitas pessoas já haviam apontado que a resposta era não. Sugeri uma maneira melhor de atingir a meta do OP. Essa é uma resposta.
Marnen Laibow-Koser

5
Desvantagem: a yamlbiblioteca não é fornecida com o Python.
Bleeding Fingers

6
@ marnen-laibow-koser: sim, deve ter sido incompetência usar as bibliotecas YAML disponíveis para Java e Perl e esperar que o YAML produzido por cada um seja consumido pelo outro sem erros. A interoperabilidade YAML foi um problema, mas a interoperabilidade JSON não foi, é totalmente explicada pela minha falta de conhecimento.
toolbear

3
@ marnen-laibow-koser, um formato que realiza a mesma coisa com uma especificação mais simples é melhor. Um formato pragmático com implementações perfeitas é melhor que um formato ideal com implementações imperfeitas. Nem toda a culpa por falhas nas bibliotecas está nos ombros dos implementadores; a especificação YAML é longa, densa e obtusa. Sua entrada na Wikipedia cita dois exemplos de ambiguidades; se é necessário colocar um emissor entre um humano e o formato para protegê-lo de ambiguidades, o formato perde sua reivindicação amigável ao ser humano. O JSON reivindica menos e é bem-sucedido principalmente onde o YAML reivindica mais e fica aquém.
toolbear

108

Você não pode. Pelo menos essa é a minha experiência de uma rápida olhada no json.org .

JSON tem sua sintaxe visualizada nessa página. Não há nenhuma observação sobre comentários.


67

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

O jsonlint não valida isso. Portanto, os comentários são uma extensão específica do analisador e não são padrão.

Outro analisador é JSON5 .

Uma alternativa ao JSON TOML .

Uma outra alternativa é jsonc .


O Groovy possui algumas classes internas para lidar com JSON . JsonSlurper pode lidar com comentários. Obviamente, comentários não são permitidos nas especificações oficiais; portanto, esse comportamento em qualquer analisador não é padrão e não é portátil.
izrik

O Newtonsoft Json.NET também suporta comentários no estilo C sem problemas
Max

66

Você deve escrever um esquema JSON . O esquema JSON é atualmente uma especificação de rascunho proposta na Internet. 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 atributo do esquema de descrição .


5
O esquema JSON está vivo? Existe, mas é suportado por qualquer biblioteca conhecida?
28412 Munhitsu

1
sim, o grupo json-schema google é bastante ativo e eu recomendaria o JSV para uma boa implementação JavaScript de um validador de esquema JSON.
Raffel

5
Isso só ajuda com documentação estruturada, não ad-hoc documentação
Juan Mendes

Se você usar Clojure (e tenho certeza que você não) há um analisador razoavelmente destaque de código aberto esquema JSON aqui: github.com/bigmlcom/closchema
charleslparker

O @Munhitsu Manatee.Json (.Net) suporta extensivamente o esquema JSON.
gregsdennis

64

Se você estiver usando Jackson como seu analisador JSON, é assim que você permite que ele permita comentários:

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);

Então você pode ter comentários como este:

{
  key: "value" // Comment
}

E você também pode ter comentários começando com a #configuração:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Mas, em geral (como respondido anteriormente), a especificação não permite comentários.


50

Aqui está o que encontrei na documentação do Google Firebase que 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"
}

Para sua informação, o Firebase Realtime Database não permite o uso de '/' em uma chave. assim que esta pode ser uma boa convenção para seu próprio uso, mas você não pode fazê-lo em Firebase
gutte

5
Esse método quebra algumas bibliotecas, que exigem que a chave seja exclusiva. Estou resolvendo esse problema numerando os comentários.
precisa saber é o seguinte

bom comentário, encontrei esta pergunta no SO ... esta parte não parece ser coberta pelas especificações stackoverflow.com/questions/21832701/…
mana

4
Eu costumo usá-lo hoje em dia: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} Você pode usar uma matriz para vários comentários: {"// foo": ["foo comment 1", "foo comment 2"], "foo": '' foo value "}
MovGP0

47

NÃO . O JSON costumava dar suporte aos comentários, mas eles foram abusados ​​e removidos do padrão.

Do criador do JSON:

Eu removi os comentários do JSON porque vi que as pessoas os estavam usando 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 padrão pela ECMA International. Sempre existe um processo de petição para revisar os padrões. É improvável que as anotações sejam adicionadas ao padrão JSON por vários motivos.

JSON por design é uma alternativa de engenharia reversa facilmente (analisada por humanos) ao XML. É simplificado até ao ponto de que as anotações são desnecessárias. Nem sequer é uma linguagem de marcação. O objetivo é estabilidade e interoperabilidade.

Qualquer pessoa que entenda o relacionamento "has-a" de 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.

Essa única anotação necessária pode ser "// Estas são as tags do 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. O 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 são analisados ​​com facilidade.

MAS, como o criador do JSON também observou, sempre houve suporte ao pipeline do JS para comentários:

Vá em frente e insira todos os comentários que você gosta. Em seguida, passe-o pelo JSMin antes de entregá-lo ao seu analisador JSON. - Douglas Crockford, 2012


37

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?

Resposta: Seria uma linha. Se você fizer isso, os arquivos JSON poderão ser usados ​​como arquivos de configuração.


1
Provavelmente, a melhor sugestão até agora, embora ainda seja um problema para manter os arquivos como um formato de intercâmbio, pois eles precisam de pré-processamento antes do uso.
Orbling

Concordo e escrevi um analisador JSON em Java, disponível em www.SoftwareMonkey.org, que faz exatamente isso.
Lawrence Dol

2
Apesar de pensar, não é uma boa ideia estender o JSON (sem chamá-lo de um formato de troca diferente): certifique-se de ignorar os "comentários" nas strings. {"foo": "/ * Este não é um comentário. * /"}
stofl

27
"... seria um liner" umm, não, na verdade, JSON não é uma gramática regular, onde uma expressão regular pode simplesmente encontrar pares correspondentes de / *. Você precisa analisar o arquivo para descobrir se um / * aparece dentro de uma string (e a ignora), ou se ela escapou (e a ignora), etc. Além disso, sua resposta é inútil porque você simplesmente especula (incorretamente) em vez de fornecer qualquer solução.
Kyle Simpson

1
O que @ kyle-simpson disse. Além disso, ele é modesto demais para direcionar os leitores para sua própria resposta sobre o uso do JSON.minify como uma alternativa aos regexps ad hoc. Faça isso, não isso.
#

36

Se você estiver usando a biblioteca Newtonsoft.Json com o ASP.NET para ler / desserializar, poderá usar comentários no conteúdo JSON:

// "nome": "string"

//"eu não fiz

ou

/* Isto é um

exemplo de comentário * /

PS: 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 criei. Eu leio o arquivo, converto-o no objeto de configurações da biblioteca Newtonsoft e o uso 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 use esteja de acordo.

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.


É difícil entender por que alguém teria problemas em afirmar um fato.
Dvdmn

Eu diria que alguém teve uma exceção porque o acima não é mais JSON ou é JSON inválido. Talvez adicionar um aviso de isenção breve.
#

5
Concordo plenamente com você, e ainda existem 883 votos positivos até agora pela não resposta que apenas afirma o óbvio. Pureza ideológica valorizada acima de informações úteis, isso é SO para você.
John John

O ponto é que um arquivo com comentários não é JSON e falhará ao ser analisado por muitas bibliotecas JSON. Sinta-se livre para fazer o que quiser em seu próprio programa, mas um arquivo com comentários não é JSON. Se você afirma que é, as pessoas tentarão analisá-lo com o idioma / biblioteca de sua escolha e isso falhará. É como perguntar se você pode usar colchetes em vez de colchetes angulares em XML. Você pode fazer o que quiser, mas não será mais XML.
precisa

32

A idéia por trás do JSON é fornecer uma troca simples de dados entre aplicativos. Normalmente, eles são baseados na Web e o idioma é JavaScript.

Realmente não permite comentários como tais, no entanto, transmitir um comentário como um dos pares de nome / valor nos dados certamente funcionaria, embora esses dados precisassem obviamente ser ignorados ou manipulados especificamente pelo código de análise.

Tudo isso dito, não é a intenção que o arquivo JSON contenha comentários no sentido tradicional. Devem ser apenas os dados.

Dê uma olhada no site JSON para mais detalhes.


17
É verdade que o formato JSON não possui comentários. Pessoalmente, acho que é um erro significativo - a capacidade de ter comentários como metadados (não dados) é uma coisa muito útil no xml. As versões de rascunho anteriores da especificação JSON incluíam comentários, mas por algum motivo elas foram descartadas. : - /
StaxMan 01/09/09

4
@StaxMan, eles foram descartados exatamente porque as pessoas começaram a usá-los como metadados. Crockford disse que violou a compatibilidade com o que o formato foi projetado, e eu concordo: se você deseja metadados, por que não incluí-lo como dados reais? É ainda mais fácil analisar dessa maneira.
Camilo Martin

6
Os metadados pertencem às construções de metadados (por exemplo, tags HTML <meta>), não comentários. Abusar comentários de metadados é apenas um hack usado onde não existe nenhuma construção de metadados verdadeira.
Marnen Laibow-Koser

Essa é exatamente a razão pela qual foi descartada: comentários usados ​​como metadados quebrariam a interoperabilidade. Você também deve armazenar seus metadados como JSON.
gaborous

1
Essa resposta é redundante com respostas melhor escritas e com votação mais alta, que dizem essencialmente a mesma coisa, mesmo que isso possa ter sido escrito anteriormente. É a vida.
#

29

Acabei de encontrar isso para arquivos de configuração. Não quero usar o formato XML (detalhado, gráfico, feio, difícil de ler) ou "ini" (sem hierarquia, padrão real etc.) ou o formato "Propriedades" do Java (como .ini).

O JSON pode fazer tudo o que pode, mas é muito menos detalhado e mais legível para humanos - e os analisadores são fáceis e onipresentes em muitos idiomas. É apenas uma árvore de dados. Porém, comentários fora da banda são frequentemente necessários para documentar configurações "padrão" e coisas do gênero. As configurações nunca devem ser "documentos completos", mas árvores de dados salvos que podem ser legíveis por humanos quando necessário.

Eu acho que alguém poderia usar "#": "comment", para JSON "válido".


4
Para arquivos de configuração, sugiro YAML, não JSON. É (quase) um superconjunto mais poderoso do JSON, mas também suporta construções mais legíveis, incluindo comentários.
Marnen Laibow-Koser

1
quantos idiomas você acha que suporta o YAML imediatamente quando comparado ao json?
mmm

@Hamidam Mais de uma dúzia de idiomas suportam o yaml: yaml.org - mas você está certo em perguntar quantos deles têm suporte embutido, sem a necessidade de uma dependência de biblioteca de terceiros. Parece que o Ruby 1.9.2 faz. Alguém conhece os outros? E quais idiomas são compatíveis com o json por padrão?
Nealmcb 21/03/12

5
A interoperabilidade de YAML é uma mentira: stackoverflow.com/questions/450399/… . Se seu instinto é usar JSON para arquivos de configuração, siga-o.
#

Isso é antigo, mas acredito que usar # não é uma boa ideia. Json está próximo da sintaxe de um JavaScript Javascript. Javascript suporta 2 tipos de comentários: // e / * ... * / Se eu fosse você, ficaria com um ou ambos os tipos de comentários.
Pascal Ganaye 02/12/2015

28

O JSON não suporta comentários de forma nativa, mas você pode criar seu próprio decodificador ou pelo menos pré-processador para remover os comentários, tudo bem (desde que você ignore os comentários e não os use para orientar como seu aplicativo deve processar os dados JSON )

JSON não tem comentários. Um codificador JSON NÃO DEVE emitir 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 o JSON.

Cf: Douglas Crockford, autor da especificação JSON .


4
Mais tarde, Crockford escreveu: "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 desejar. Em seguida, passe pelo JSMin antes de entregá-lo ao seu analisador JSON." Consulte a resposta de @ kyle-simpson sobre JSON.minify para obter mais informações.
toolbear


27

O JSON faz muito sentido para arquivos de configuração e outros usos locais porque é onipresente e muito mais simples que XML.

Se as pessoas tiverem motivos fortes para não comentar no JSON ao comunicar dados (válidos ou não), possivelmente JSON poderá ser dividido em dois:

  • JSON-COM: JSON na ligação ou regras que se aplicam ao comunicar dados JSON.
  • JSON-DOC: documento JSON 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 espaços em branco. Os analisadores podem facilmente converter de uma especificação para outra.

Com relação à observação feita por Douglas Crockford sobre esse assunto (referenciada por @Artur Czajka)

Suponha que você esteja usando 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 pelo JSMin antes de entregá-lo ao seu analisador JSON.

Estamos falando de um problema genérico de arquivo de configuração (cross language / plataforma), e ele está respondendo com um utilitário específico do JS!

Certifique-se de que um minify específico do JSON possa 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 perder tempo sem o recurso porque possuem bons casos de uso, procurando o problema em fóruns on-line e levar as pessoas a dizerem que é uma má ideia ou sugerir que é fácil implementar a remoção de comentários de 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. E este subsistema deve ser acessado de diferentes idiomas. Então você continua dizendo às pessoas: a propósito, não esqueça de remover os comentários dos arquivos JSON antes de passá-los para o analisador!


Não há necessidade de fragmentar JSON. JSON com comentários não é mais JSON. Mas é perfeitamente aceitável anotar seu JSON com comentários, desde que você os remova antes de analisá-lo ou transmiti-lo. Nunca deve ser responsabilidade do receptor fazer isso.
#

json5.org é uma solução para json-doc
Michael Freidgeim 23/04

24

Se você usa JSON5, pode incluir comentários.


O JSON5 é uma extensão proposta para o JSON que visa tornar mais fácil para os humanos escrever e manter manualmente. Isso é feito adicionando alguns recursos mínimos de sintaxe diretamente do ECMAScript 5.


5
Você poderia adicionar um exemplo? Então você pode realmente precisar desses caracteres extras.
Dgilperez

6
É exigido pelas diretrizes da SO para fornecer uma resposta real. Respostas somente para links não são desejadas. Você pode verificar o diretrizes stackoverflow.com/help/how-to-answer
dgilperez

2
SO é moderado por seus usuários. Isso significa que posso fornecer uma resposta se a tiver da mesma maneira que posso comentar a sua se ela não seguir as diretrizes. É assim que o SO passa a ser um ótimo recurso.
dgilperez

22

O kit de ferramentas JavaScript do Dojo Toolkit (pelo menos a partir da versão 1.4) permite incluir comentários em seu JSON. Os comentários podem ter /* */formato. O Dojo Toolkit consome o JSON por meio da dojo.xhrGet()chamada.

Outros kits de ferramentas JavaScript podem funcionar de maneira semelhante.

Isso pode ser útil ao experimentar estruturas de dados alternativas (ou mesmo listas de dados) antes de escolher uma opção final.


4
Não. Não é isso. JSON não tem comentários. Se você optar por anotar seu JSON com comentários, reduza-o antes de analisar ou transmitir. Isso não deve ser de responsabilidade do receptor.
#

2
Eu não disse que o JSON tem comentários. Também não quis dizer que é apropriado incluí-los no seu JSON, especialmente em um sistema de produção. Eu disse que o kit de ferramentas do Dojo permite que você os adicione, o que é (ou pelo menos era) factualmente verdadeiro. Existem casos de uso muito úteis para isso em sua fase de teste.
David

1
É um vodu ruim servir JSON comentado e, portanto, inválido, o que dojo.xhrGet()implica implicitamente em aceitar.
toolbear

Ainda voto pela atualização da especificação JSON para permitir comentários. Sou a favor de minificar e remover os comentários antes de transmitir o JSON, mas não tenho a capacidade de comentar seu JSON de maneira padrão sem precisar passar por um utilitário separado antes de analisá-lo. Também impossibilito o uso de um editor JSON em seus arquivos de configuração JSON, porque seus arquivos não são JSON válidos.
Craig

20

JSON não é um protocolo emoldurado . É um formato livre de idioma . Portanto, o formato de um comentário não está definido para JSON.

Como muitas pessoas sugeriram, existem alguns truques, por exemplo, chaves duplicadas ou uma chave específica _commentque você pode usar. Você decide.


18

Você pode ter comentários em JSONP , mas não em JSON puro. Passei 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, 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 havia problemas com a política de mesma origem , então decidi usar JSON puro ... e, é claro, $.getJSONestava falhando silenciosamente por causa dos comentários.

Eventualmente, acabei de enviar uma solicitação HTTP manual para o endereço acima e percebi que o tipo de conteúdo era text/javascriptporque, bem, JSONP retorna JavaScript puro. Nesse caso, comentários são permitidos . Mas meu aplicativo retornou o tipo de conteúdo application/json, então tive que remover os comentários.


17

Esta é uma pergunta "você pode" . E aqui está um "sim" resposta .

Não, você não deve usar membros duplicados do objeto para inserir dados do canal lateral em uma codificação JSON. (Veja "Os nomes dentro de um objeto devem ser únicos" no RFC ).

E sim, você pode inserir comentários em torno do JSON , que você pode analisar.

Mas se você deseja inserir e extrair dados arbitrários do canal lateral em um JSON válido, aqui está uma resposta. Aproveitamos a representação não exclusiva de dados em uma codificação JSON. Isso é permitido * na seção dois da RFC em "espaço em branco permitido antes ou depois de qualquer um dos seis caracteres estruturais".

* O RFC apenas declara "espaço em branco é permitido antes ou depois de qualquer um dos seis caracteres estruturais", sem mencionar explicitamente cadeias, números, "false", "true" e "null". 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á a sua saída:

$jsonWithComment = $steg . $jsonMin;

1
O RFC apenas declara "espaço em branco é permitido antes ou depois de qualquer um dos seis caracteres estruturais", sem mencionar explicitamente cadeias, números, "false", "true", "null". Essa omissão é ignorada em TODAS as implementações.
William Entriken

1
Para maior densidade de comentários, você não poderia codificar seu comentário em ternário e usar espaço, tabulação e nova linha para armazená-lo?
31318 Claire Nielsen

Não deve. Veja o RFC 2119 explicitamente incluído: DEVE: Esta palavra, ou os termos "NECESSÁRIO" ou "DEVERÁ", significa que a definição é um requisito absoluto da especificação. ... DEVE: Esta palavra, ou o adjetivo "RECOMENDADO", significa que podem existir razões válidas em circunstâncias particulares para ignorar um item em particular, mas todas as implicações devem ser entendidas e ponderadas cuidadosamente antes de escolher um curso diferente.
Jeff K

Boa referência. Um melhor raciocínio contra o uso de chaves duplicadas é a citação do padrão "Quando os nomes em um objeto não são exclusivos, o comportamento do software que recebe esse objeto é imprevisível". Agora também entendo por que o padrão não era "DEVE ser único", isso simplifica um validador, ele só precisa rastrear [e {, não precisa saber quais chaves já foram usadas.
William Entriken

16

AVISO LEGAL: ISSO É TOLO

Na verdade, existe uma maneira de adicionar comentários e permanecer dentro das especificações (nenhum analisador adicional é necessário). Não resultará em comentários legíveis por humanos sem qualquer tipo de análise.

Você pode abusar do seguinte:

Espaço em branco insignificante é permitido antes ou depois de qualquer token. Espaço em branco é qualquer sequência de um ou mais dos seguintes pontos de código: tabulação de caracteres (U + 0009), avanço de linha (U + 000A), retorno de carro (U + 000D) e espaço (U + 0020).

De uma maneira hacky, você pode abusar disso para adicionar um comentário. Por exemplo: inicie e termine seu comentário com uma guia. Codifique o comentário na base3 e use os outros caracteres de espaço em branco para representá-los. Por exemplo.

010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202

( hello base threeem ASCII) Mas, em vez de 0, use espaço, para 1 uso de alimentação de linha e 2 para uso de retorno de carro.

Isso deixará você com muito espaço em branco ilegível (a menos que você crie um plug-in IDE para codificá-lo / decodificá-lo rapidamente).

Eu nunca tentei isso, por razões óbvias e você também não deveria.


12

Estamos usando strip-json-commentspara o nosso projeto. Ele suporta algo como:

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

Simplesmente npm install --save strip-json-commentspara instalar e usar como:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}

Observe que o jsonJSON não é mais válido quando inclui esses comentários de propriedade.
Roy Prins

12

No meu caso, preciso usar comentários para fins de depuração, antes da saída da estrutura JSON. Então, decidi usar as informações de depuração no cabeçalho HTTP, para evitar a quebra do cliente:

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

Digite a descrição da imagem aqui


12

JSON não permite comentários, por si só. O raciocínio é totalmente tolo, porque você pode usar o próprio JSON para criar comentários, o que evita completamente o raciocínio e carrega o espaço de dados do analisador sem nenhuma boa razão para exatamente o mesmo resultado e possíveis problemas, como eles são: um JSON arquivo com comentários.

Se você tentar inserir comentários (usando //ou /* */ou #por exemplo), alguns analisadores falharão porque isso não está estritamente dentro da especificação JSON. Então você nunca deve fazer isso.

Aqui está um exemplo, em que meu sistema de manipulação de imagens salvou notações de imagens e algumas informações básicas formatadas (comentários) relacionadas a elas (na 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."
    }
}

O link "raciocínio" está quebrado. Alguma chance de encontrar um link atual para ele?
Don escotilha

Infelizmente, o Google matou o sistema de mídia social que continha o post; Não tenho ideia de onde foi o pôster original, se é que houve algum lugar. Porém, matarei o link nas informações acima, para remover a ambiguidade. Obrigado.
Fyngyrz

O raciocínio não é tolo, e você acabou de provar. A implementação de comentários como tags preserva a interoperabilidade . É exatamente por isso que Crockford queria que os comentários fossem analisados ​​como tags. Agora tudo é apenas uma tag e analisado da mesma maneira .
Dominic Cerisano

Se a especificação declarasse que "uma linha que começa com # é um comentário", isso seria totalmente interoperável. Tal como está, os comentários carregam o espaço do analisador, pois são itens analisados válidos, em vez de serem entendidos como comentários, e podem ser diferentes para cada arquivo .json existente. Considerando que, se (por exemplo) a especificação disser "linhas começando com # são comentários", os analisadores poderão pular essas linhas sem analisar (mais rápido) e não carregar o espaço do analisador (melhor utilização da memória). Não há benefício algum com a falta dos comentários em .json, apenas desvantagens.
fyngyrz 28/01

11

Para cortar um item JSON em partes, adiciono linhas "comentários fictícios":

{

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

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

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

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

}

15
Você emulou uma estrutura de arquivo INI no JSON. Por favor, abaixe seu martelo de ouro.
Artur Czajka

4
RFC diz "Os nomes dentro de um objeto devem ser únicos". Consulte também esta pessoa que está tendo um erro ao analisar o JSON como acima: stackoverflow.com/questions/4912386/…
William Entriken

Se você estiver usando um esquema para validar o JSON, ele poderá falhar devido aos campos extras.
gregsdennis

1
Se você estiver realmente determinado a adicionar comentários ao seu JSON, faria muito mais sentido fazer algo assim: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } Isso mantém o nome exclusivo e permite adicionar o valor da string que você desejar. Ainda é um argumento, porque os comentários não devem fazer parte do seu JSON. Como outra alternativa, por que não adicionar comentários antes ou depois do seu JSON, mas não dentro dele?
Jazimov 04/04/2015
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.