Quando e Por que é preferível XML para CSV? [fechadas]
https://stackoverflow.com/questions/1820129
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
às vezes parece que XML tem sido utilizado apenas porque era moda.
Solução
Alguns pontos fortes:
- Você pode validar dados XML contra XSD
- Você pode facilmente fornecer contratos (como XSD) para outras partes que devem ou criar / consumir dados XML, sem, literalmente, descrevendo-
- Você pode ter um para muitas relações em vários níveis de representação de dados XML
- XML é sem dúvida mais legível do que CSV
- XML é suportado nativamente pelo .NET Framework
Para citar alguns do topo da minha cabeça.
Outras dicas
arquivos .csv são boas quando seus dados é estritamente tabular e você sabe sua estrutura. Assim que você começa a ter relações entre os diferentes níveis de seus dados, xml tende a trabalhar melhor, porque os relacionamentos podem ser feitas óbvio (mesmo sem esquemas) apenas pelo aninhamento.
XML tornou-se o padrão para seus muitos benefícios que muitas outras pessoas já mencionado. Portanto, a questão torna-se realmente "Quando e Por que é CSV preferível XML?".
Eu me sinto CSV é preferível XML quando: - você está carregando dados tabulares simples - você está no controle tanto da geração e consumo do arquivo de dados - o conjunto de dados é grande
CSV é perfeitamente utilizável se os 2 primeiros pontos são verdadeiras, e tem uma vantagem de desempenho que se torna mais significativa quanto maior o conjunto de dados é.
Eu fiz um teste rápido carregamento ~ 8000 registros cada um com 6 campos de texto. Carregar e analisar o XML tomou ~ 8 segundos. Carregando o CSV levou menos de 1 segundo.
A sobrecarga de XML vale a pena em muitos casos, mas quando as estrelas se alinham, CSV faz mais sentido.
CSV é útil quando você só tem uma série de um valores que se relacionam com algum pedaço de informação e você sabe que sempre vai armazenar valores para cada campo.
XML tem o benefício de ter dados auto-descritivo (tags) e ter hierarquia -. O que lhe dá muito mais flexibilidade na maneira que você armazena os dados
Você pode ter uma hierarquia muito mais complexo, etc. e estrutura com CSV XML vs.. Ele oferece muito mais flexibilidade.
Eu encontrei um teste de desempenho interessante na rede. Deus exemplo de desvantagens de XML quando as características de XML não é necessário.
"Eu tentei a experiência de Steven de um ângulo diferente. Enchi um Excel XP planilha com um número de um dígito, salvou em XML e em um arquivo de texto delimitado por vírgulas (CSV). Eu, então, comprimido ambos com WinZip e, em seguida, abriu ambos com Excel. Aqui está o que eu encontrei:
O arquivo XML foi 840MB, o 34MB CSV - uma diferença de 2.500% Compactado, o arquivo XML foi 2.5MB, o 0.00015MB CSV (150 KB) - a 1,670% diferença.
Igualmente dramática é o tempo que levou para descompactar e tornar os arquivos como uma planilha do Excel: Demorou cerca de 20 minutos com o arquivo XML; o CSV levou 1 hora -. uma diferença de 2.000% "
Claro que é, por vezes, de moda e de zumbido-dignos. Tudo depende de sua aplicação. Eu prefiro arquivos de configuração em XML, porque eles são fáceis de analisar. Considerando que, eu uso arquivos CSV para DataGridView ou banco de dados lixeiras.
Este diário WTF: XML vs CSV a escolha é óbvia irá ajudá-lo a fazer a sua decisão ;)
XML é preferível ao longo CSV quando os dados são não estruturados (desconhecido esquema) e será lido por um humano.
Provavelmente, a menos que os dados contêm predominantemente texto, CSV é também destinado ao consumo humano.
Também relevante, é se os seus dados é 2 ou 3 dimensões. CSV é mais adequado para 2 texto dimensional, e devido à sua verbosidade, XML funciona bem com 3 dados dimensionais.
O todo "standardness" de XML é uma hipérbole, e não deve ser tomada literalmente. XML tem enormes problemas técnicos e muitas das soluções não são particularmente elegante, ou em muitos casos útil:
- Ele usa texto para especificar seu próprio codificadores de texto (galinha e do ovo?)
- Nenhuma das linguagens de esquema mais comuns para o trabalho XML particularmente bem.
- A forma antiga e comum de criar linguagens de marcação usando
<tags>não é particularmente útil como um padrão. - tentativas XML para mais poderosas linguagens de marcação retroativamente calçadeira como os SGML base, em si, criando uma confusão de legado incompatíveis.
- Ainda continua a ser determinado ou não sequências de escape texto XML pode trabalhar para nada, mas os casos simples maioria (ie. De dados amigável).
Para ser claro, XML é provavelmente a escolha incorreta para 90% dos Data Interchange ele está sendo usado para, uma vez que esses usos quebrar algumas ou todas as premissas acima.
Além das outras respostas, XML permite que você especifique qual conjunto de caracteres do documento está em.
Eu descobri das maiores vantagens de XML para ser a funcionalidade de análise e validação estrita que vem the-box out-of-com a maioria das bibliotecas XML. A insistência na boa formação e fácil de entender a mensagem de erro (xyz não fechado em x linha, coluna y) são uma ajuda real em comparação com os valores de caça quebrada, ou comportamento desconhecido, por causa de um erro no arquivo CSV.
CSV é mais leve se você quiser mudar as coisas desde a sua normalmente mais 2 vezes menor do que XML
XML é padrão e não será atingido pela versão diferentes OS'es de CSV
Eu não tenho reputação suficiente para comentar sobre a resposta relevante, mas alguém sugeriu comprimir o XML como uma forma de ganhar paridade em tamanho com formatos CSV. Embora isto seja verdade, compressão XML pode somtimes voltar a morder-lhe. Se você estiver transferindo dados XML de ponto a ponto e ele falhar, é bom ser capaz de ler o XML e descobrir o que deu errado. Se o XML é comprimido e a transferência falhar, às vezes não é possível descompactá-lo e examinar o conteúdo. Em outras palavras XML comprimindo anula a vantagem humana-legibilidade ele tem.
Eu diria XML uso (e ou JSON) porque um dia você ou alguém (com um pavio curto e uma grande coleção de armas) pode ter que ir encontrar um erro nos dados CSV.
Então, sim, eu estou dizendo a legibilidade, não se esqueça de pensar no outro cara! Ele pode estar pensando em você.
XML fornece uma maneira de marcar os seus dados com metadados (fornecido pelos nomes de marcas e nomes de atributos), enquanto CSV não. Junte isso com a capacidade de definir hierarquias estruturadas e faz XML mais fácil de entender quando fornecido com apenas os dados, enquanto CSV exigiria uma ferramenta ou documento de acompanhamento para descrever como cada valor é interpretado.
Você pode facilmente atravessar dados XML mesmo quando você tem dados complexos.
Verifique estes links:
E novamente mais uma para XML: O X em XML significa E xtensible (eu sei, não :-P realmente mnemônica) . Isso significa que, com a ajuda do mecanismo de namespace XML, você pode participar de quaisquer duas linguagens XML você gosta e combiná-los no mesma documento. Dado que só há uma 'linguagem' CSV (sem contar as miríades de estilos delimitadores), XML pode lidar com um monte de complexidade, e que de uma forma modular.
Este, porém, é a vantagem de CSV:. Se você realmente tem dados tabulares, sintaxe XML é mais frequentemente um exagero
Eu também descobri que algumas cvs geradores / analisadores têm muita dificuldade com dados de texto gerais. longas cadeias de texto com um monte de retornos de carro e vírgulas e citações, etc etc, apenas tornar a vida muito difícil quando se trata de manipulação de um cvs.
SSMS gosta de truncar csv para se divertir.
estruturado, legível, mais fáceis de editar, validação, parsability, transformabilidade, digitação, namespaces, bibliotecas poderosas por trás dele, são todos entre muitos das razões.
Acima de tudo que seja padrão.
- Existem analisadores e emissores existentes para que em todas as línguas e banco de dados
- Eles lidam com codificação para me
- Eles lidam com escapando para mim
Isso é tudo o que importa para mim.
Claro, há uma maneira semi-standard, fazer o escape em CSV (ou seja, "a maneira como o Excel faz isso"), e não é exatamente difícil escrever mesmo, mas faz exame de algum tempo. E então você tem que concordar implicitamente em uma codificação de caracteres out-of-band. Mas então, porque é tão simples, as pessoas tentam escrever por si próprios, e invariavelmente estragar tanto # 2 e # 3.
JSON também atende # 2 e # 3 e está ficando perto de satisfazer # 1. Também é sem dúvida mais simples, pelo menos para arquivos que não sejam documentos. Não surpreendentemente, encontro-me a usá-lo mais e mais, internamente e externamente.
E eu também prefiro isso porque é muito mais legível.
