Comparação JSON e XML [fechado]
6 answers
Antes de responder quando usar qual, um pouco de fundo:
Edit: devo mencionar que esta comparação é realmente da perspectiva de usá-los em um navegador com JavaScript. Não é a forma como qualquer formato de Dados tem para ser usado, e há muitos bons parsers que vão mudar os detalhes para fazer o que estou dizendo não ser completamente válido.
JSON é mais compacto e (na minha opinião) mais legível - na transmissão pode ser" mais rápido " simplesmente porque menos dados são transferidos.
Ao analisar, depende do seu analisador. Um analisador de ligar o código (seja JSON ou XML) em uma estrutura de dados (como um mapa) podem se beneficiar de estrita natureza de XML (Esquemas XML é capaz de distinguir a estrutura de dados muito bem) - no entanto, em JSON o tipo de um item (String, Número/Aninhadas Objeto JSON) pode ser inferida sintaticamente, e.g:myJSON = {"age" : 12,
"name" : "Danielle"}
O analisador não precisa de ser inteligente o suficiente para perceber que 12 representa um número, (e Danielle é uma corda como qualquer outra). Então em javascript podemos fazer:
anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False
Em XML teríamos de fazer algo como o seguinte:
<person>
<age>12</age>
<name>Danielle</name>
</person>
(como um aparte, isto ilustra o ponto de que o XML é bastante mais descritivo; uma preocupação com a transmissão de dados). Para usar estes dados, passaríamos por um analisador, então teríamos que chamar algo como:
myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True
Na verdade, um bom analisador pode muito bem digitar o {[[8]} para você (por outro lado, você pode muito bem não querer isso). O que se passa? quando acessamos esses dados-em vez de fazer uma pesquisa de atributos como no exemplo JSON acima - estamos fazendo uma pesquisa de mapa na chave name. Pode ser mais intuitivo formar o XML assim:
<person name="Danielle" age="12" />
myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");
Editar: Original:
Na maioria das linguagens de programação (nem todas, por qualquer extensão), uma pesquisa de mapas como esta será mais cara do que uma pesquisa de atributos (como ficamos acima quando analisamos the JSON).
Isto é enganador: lembre-se que em JavaScript (e outras linguagens dinâmicas) não há diferença entre uma pesquisa de mapa e uma pesquisa de campo. Na verdade, uma pesquisa de campo é apenas uma pesquisa de mapa.
Se você quer uma comparação realmente útil, o melhor é fazer a referência - fazer os benchmarks no contexto em que você planeja usar os dados.
Como Tenho estado a escrever, o Felix Kling já apresentou uma resposta sucinta comparando eles em termos de quando usar cada um, por isso não vou mais longe.Faster não é um atributo de JSON ou XML ou um resultado que uma comparação entre eles renderia. Se houver, então é um atributo dos parsers ou a largura de banda com a qual você transmite os dados.
Aqui está (o início de) uma lista de vantagens e desvantagens de JSON e XML:
JSON
Pro:
- sintaxe simples, o que resulta em menos sobrecarga de "marcação" em comparação com XML.
- fácil de usar com JavaScript como a marcação é um subconjunto da notação literal de objetos JS e tem os mesmos tipos de dados básicos como JavaScript.
- JSON Schema para a descrição, tipo de dados e validação da estrutura
- JsonPath para extrair informação em estruturas profundamente aninhadas
Con:
- sintaxe simples, apenas um punhado de diferentes tipos de dados são suportados.
XML
Pro:
- Marca generalizada; é possível criar "dialetos" para qualquer tipo de propósito
- esquema XML para o tipo de dados, validação da estrutura. Torna também possível criar novos tipos de Dados
- XSLT para transformação em diferentes formatos de saída
- XPath/XQuery para extrair informação em estruturas profundamente aninhadas
- construído em suporte para espaços de nomes
Con:
- relativamente wordy comparado com JSON (resultados em mais dados para a mesma quantidade de informação).
Então, no final, você tem que decidir o que você precisa . Obviamente, ambos os formatos têm os seus casos legítimos de uso. Se você está indo principalmente para usar JavaScript, então você deve ir com JSON.
por favor, sinta-se à vontade para adicionar prós e contras. Não sou um perito em XML.;)
A velocidade de processamento pode não ser a única matéria relevante, no entanto, como essa é a questão, aqui estão alguns números em um benchmark: JSON vs. XML:alguns números duros sobre verbosidade . Para a velocidade, nesta SIMPLES referência, o XML apresenta uma sobrecarga de 21% sobre o JSON.
Uma nota importante sobre a verbosidade, que é como diz O artigo, a queixa mais comum: isto não é tão relevante na prática (nem os dados XML nem JSON são tipicamente tratados por humanos, mas por máquinas), mesmo que para a questão da velocidade, requer algum tempo razoável mais para comprimir.
Também, nesta referência, uma grande quantidade de dados foi processada, e uma aplicação web típica não irá transmitir blocos de dados de tais tamanhos, como o 90MB, e a compressão pode não ser benéfica (para blocos de dados pequenos o suficiente, um bloco comprimido será maior do que o bloco não comprimido), por isso não aplicável.
Ainda assim, se não houver compressão, JSON, como obviamente terser, irá pesar menos sobre o canal de transmissão, especialmente se transmitido através de uma conexão WebSocket, onde a ausência da sobrecarga HTTP clássica pode fazer a diferença em vantagem da JSON, ainda mais significativa.Após a transmissão, os dados devem ser consumidos, o que conta no tempo total de processamento. Se forem transmitidos dados suficientemente grandes ou complexos, a falta de um esquema verificado automaticamente por um analisador XML de validação, poderá requerer mais Verificação dos dados JSON; estas verificações teria que ser executado em JavaScript, que não é conhecido por ser particularmente rápido, e assim ele pode apresentar uma sobrecarga adicional sobre XML em tais casos.
De qualquer forma, apenas o teste irá fornecer a resposta para o seu caso de uso específico (se a velocidade é realmente a única questão, e não padrão, nem segurança, nem integridade...).
Actualização 1: vale a pena mencionar, é o EXI, o formato XML binário, que oferece compressão a menor custo do que usar o Gzip, e salvar o processamento de outra forma necessário para descomprimir XML comprimido. EXI é XML, o que BSON é para JSON. Ter uma visão geral rápida aqui, com alguma referência à eficiência tanto no espaço como no tempo: EXI: o último padrão binário?.
Update 2: Existe também um relatório binário de desempenho XML, conduzido pelo W3C, como eficiência e baixa memória e pegada de CPU, é também uma questão para a área XML também: avaliação eficiente do intercâmbio XML.
Actualização 2015-03-01
Vale a pena ser notado nisto. o contexto, como HTTP sobrecarga foi levantada: a IANA tem registrado a EXI codificação (o eficiente XML binário mencionado acima), como um Codificação de Conteúdo para o protocolo HTTP (juntamente com comprimir, esvaziar e gzip). Isto significa que o EXI é uma opção que se pode esperar que seja compreendida pelos navegadores entre, possivelmente, outros clientes HTTP. Ver parâmetros do Protocolo de transferência de hipertexto (iana.org).Sobre JSON pros:
Se tudo o que deseja transmitir São valores atómicos, listas ou traços de valores atômicos, JSON tem muitas das vantagens do XML: é directamente utilizável através da Internet, suporta uma grande variedade de aplicações, é fácil de escrever programas para processar JSON, ele tem poucos características opcionais, é legível e razoavelmente clear, a sua concepção é formal e conciso, documentos JSON são fáceis de criar, e usa Unicode. ...
Acerca dos prós XML:
Pessoalmente, concordo com o Norm. Eu acho que a maioria dos ataques ao XML vêm de desenvolvedores Web para aplicações típicas, e não realmente de desenvolvedores de integração. Mas essa é a minha opinião! ;)XML lida notavelmente bem com a riqueza completa de não estruturados dado. Não estou preocupado com o futuro do XML, mesmo que a sua morte é alegremente celebrado por um grupo de designers de API web.
E não resisto a aconchegar-me e a dizer: "Eu bem te disse!"token away in my Secretario. Estou ansioso para ver o que os JSON fazem quando são pediu para desenvolver APIs mais ricos. Quando querem trocar menos bem dados estruturados, vão enfiá-los no JSON? Eu vejo ocasionalmente menções de uma linguagem schema para JSON, outras línguas vão seguir? ...
O XML (extensible Markup Language) é usado muitas vezes XHR porque esta é uma linguagem de transmissão padrão, o que pode ser usado por qualquer linguagem de programação, e suportou tanto servidor e cliente lado, de modo que esta é a solução mais flexível. O XML pode ser separado para mais partes para que um grupo especificado possa desenvolver a parte do programa, sem afetar as outras partes. O formato XML também pode ser determinado pelo XML DTD ou XML Schema (XSL) e pode ser testado.
O JSON a formato de troca de dados que está ficando mais popular como o formato possível das aplicações JavaScript. Basicamente este é um array de notação de objeto. JSON tem uma sintaxe muito simples para que possa ser facilmente aprendida. E também o JavaScript suporta processar JSON com a função eval. Por outro lado, a função eval tem negativos. Por exemplo, o programa pode ser muito lento parsing JSON e por causa da segurança o eval pode ser muito arriscado. Isso não significa que o JSON não é bom, apenas temos que ser mais cuidado.
O XML é melhor para os sites maiores, por exemplo, sites de compras ou algo assim. O XML pode ser mais seguro e claro. Você pode criar dados básicos-struct e schema para testar facilmente a correção e separá-la em partes facilmente.
Sugiro que use XML por causa da velocidade e da segurança, mas o JSON para coisas leves.