usar - json tutorial portugues




Os comentários podem ser usados no JSON? (20)

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


A ideia por trás do JSON é fornecer troca de dados simples entre aplicativos. Estes são tipicamente baseados na web e a linguagem é JavaScript.

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

Tudo o que disse, não é a intenção que o arquivo JSON deve conter comentários no sentido tradicional. Deve ser apenas os dados.

Dê uma olhada no site JSON para mais detalhes.


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

O JSON pode fazer tudo o que pode, mas é menos detalhado e mais legível - e os analisadores são fáceis e onipresentes em vários idiomas. É apenas uma árvore de dados. Mas os comentários fora de banda são uma necessidade, muitas vezes, para documentar configurações "padrão" e coisas do tipo. As configurações nunca devem ser "documentos completos", mas árvores de dados salvos que podem ser lidos por humanos quando necessário.

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


Comentários não são um padrão oficial. Embora alguns analisadores suportem comentários no estilo C. Um que eu uso é o 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 padrão.

Outro analisador é o JSON5 .

Uma alternativa para o JSON TOML .


Considere o uso de YAML. É quase um superconjunto do JSON (virtualmente todo o JSON válido é válido para o YAML) e permite comentários.


ISENÇÃO DE RESPONSABILIDADE: A SUA GARANTIA É NULA

Como já foi dito, esse hack aproveita a implementação da especificação. Nem todos os analisadores JSON entenderão esse tipo de JSON. Analisadores de streaming, em particular, vão sufocar.

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

Eu encontrei um pequeno hack que permite colocar comentários em um arquivo JSON que não afetará a análise ou alterar os dados representados de alguma forma.

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, 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á ter esta aparência:

{
  "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 é válido em JSON . Se você analisar, você terá 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á nenhum traço dos comentários, e eles não terão efeitos colaterais estranhos.

Hacker feliz!


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 pelos aplicativos que usam os dados JSON.

Você provavelmente seria melhor ter o comentário nos processos que gera / recebe o JSON, já que eles devem saber o que os dados JSON anteciparão, 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"
            }
         }
      }
   }
}

Se o seu arquivo de texto, que é uma string JSON, for lido por algum programa, quão difícil seria remover comentários em estilo C ou C ++ antes de usá-lo?

Resposta: Seria um forro único. Se você fizer isso, os arquivos JSON poderão ser usados ​​como arquivos de configuração.


Se você estiver usando Jackson como seu analisador JSON, então é 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 # definindo:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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


Veja o que encontrei na documentação do Google Firebase que permite colocar 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"
}

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


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 o JSON válido que pode ser analisado. Então, você pode usá-lo como:

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

Quando o lancei, tive uma enorme reação de pessoas discordando até mesmo 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 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, canalize-o pelo JSMin antes de entregá-lo ao analisador JSON. - plus.google.com/118095276221607585885/posts/RK8qyGVaGSr

Espero que isso seja útil para aqueles que não concordam com o motivo de o JSON.minify () ser útil.


JSON não é um protocolo estruturado . É um formato livre de linguagem . 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.


JSON não suporta comentários nativamente, mas você pode fazer seu próprio decodificador ou pelo menos pré-processador para remover comentários, isso é perfeitamente correto (contanto que você ignore os comentários e não os use para guiar como seu aplicativo deve processar os dados JSON) ).

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

Cf: Douglas Crockford, autor do JSON spec .


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

Se as pessoas tiverem fortes razões contra comentários no JSON ao comunicar dados (válidos ou não), possivelmente o JSON pode 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.

JSON-DOC permitirá comentários, e outras pequenas diferenças podem existir, como manipulação de espaço em branco. Analisadores podem facilmente converter de uma especificação para outra.

Com relação à plus.google.com/118095276221607585885/posts/RK8qyGVaGSr feita por Douglas Crockford sobre essas questões (referenciado 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, canalize-o pelo JSMin antes de entregá-lo ao analisador JSON.

Estamos falando de um problema de arquivo de configuração genérico (cross language / platform), 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 ele se torne onipresente em todos os idiomas e plataformas para que as pessoas parem de perder seu tempo sem o recurso, pois eles têm bons casos de uso fóruns on-line, e fazer com que as pessoas digam que é uma má ideia ou sugerir que é fácil implementar comentários fora 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 a ele. E esse subsistema deve ser acessado de diferentes idiomas. Então você vai dizer às pessoas: a propósito, não se esqueça de retirar os comentários dos arquivos JSON antes de passá-los para o analisador!


Depende da sua biblioteca JSON. Json.NET suporta comentários no estilo JavaScript /* commment */,.

Veja outra pergunta sobre estouro de pilha .


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

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

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

Mas se você quiser 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 exclusiva de dados em uma codificação JSON. Isso é permitido * na seção dois do RFC sob "espaço em branco é permitido antes ou depois de qualquer um dos seis caracteres estruturais".

* O RFC apenas declara "espaços em branco permitidos antes ou depois de qualquer um dos seis caracteres estruturais", não mencionando explicitamente cadeias, números, "falso", "verdadeiro" e "nulo". Essa omissão é ignorada em TODAS as implementações.

Primeiro, canonize seu JSON, diminuindo-o:

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

Então 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;

Existe uma boa solução (hack), que é um JSON válido. Basta fazer a mesma chave duas vezes (ou mais). Por exemplo:

{
  "param" : "This is the comment place",
  "param" : "This is value place",
}

Então, o JSON entenderá isso como:

{
  "param" : "This is value place",
}

O autor do JSON deseja incluir comentários no JSON, mas excluí-los antes de analisá-los (consulte o plus.google.com/118095276221607585885/posts/RK8qyGVaGSr fornecido por Michael Burr). Se o JSON tiver comentários, por que não padronizá-los e deixar o analisador JSON fazer o trabalho? Eu não concordo com a lógica lá, mas, infelizmente, esse é o padrão. Usar uma solução YAML como sugerido por outros é bom, mas requer uma dependência de biblioteca.

Se você deseja remover comentários, mas não quer ter uma dependência de biblioteca, aqui está uma solução de duas linhas, que funciona para comentários no estilo C ++, mas pode ser adaptada para outras pessoas:

var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

Observe que essa solução só pode ser usada em 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 obter a análise JSON, remoção de comentários e nenhuma biblioteca extra é avaliar o JSON em um interpretador JavaScript. A ressalva com essa abordagem, é claro, é que você só deseja avaliar dados não contaminados (sem entrada de usuário não confiável). Aqui está um exemplo dessa abordagem em Node.js - outra advertência, o exemplo a seguir só lerá os dados uma vez e, em seguida, será armazenado em cache:

data = require(fs.realpathSync(doctree_fp));

Se você usar o JSON5 poderá incluir comentários.

O JSON5 é uma extensão proposta para o JSON que tem como objetivo facilitar a escrita e a manutenção manual de humanos. Isso é feito adicionando alguns recursos mínimos de sintaxe diretamente do ECMAScript 5.


Suspiro. Por que não apenas 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 entrem em conflito com nenhum campo real.





comments