Domanda

a volte sembra che XML sia stato usato solo perché era di moda.

È stato utile?

Soluzione

Alcuni punti di forza:

  • Puoi convalidare i dati XML su XSD
  • Puoi facilmente fornire contratti (come XSD) ad altre parti che dovrebbero creare / consumare dati XML, senza descriverli letteralmente
  • Puoi avere una o più relazioni a più livelli nella rappresentazione dei dati XML
  • XML è probabilmente più leggibile di CSV
  • XML è nativamente supportato dal framework .net

Per citarne alcuni dalla cima della mia testa.

Altri suggerimenti

I file .csv sono buoni quando i tuoi dati sono strettamente tabulari e ne conosci la struttura. Non appena si iniziano ad avere relazioni tra i diversi livelli dei dati, xml tende a funzionare meglio perché le relazioni possono essere rese ovvie (anche senza schemi) semplicemente annidando.

XML è diventato il valore predefinito per i suoi numerosi vantaggi che molte altre persone hanno già menzionato. Quindi la domanda diventa davvero & Quot; Quando e perché CSV è preferibile a XML? & Quot ;.

Sento che CSV è preferibile a XML quando: - stai caricando semplici dati tabulari - hai il controllo sia della generazione che del consumo del file di dati - il set di dati è grande

CSV è perfettamente utilizzabile se i primi 2 punti sono veri e ha un vantaggio in termini di prestazioni che diventa più significativo quanto maggiore è il set di dati.

Ho fatto un test rapido caricando ~ 8000 record ciascuno con 6 campi di testo. Il caricamento e l'analisi dell'XML ha richiesto ~ 8 secondi. Il caricamento del CSV ha richiesto meno di 1 secondo.

Il sovraccarico di XML vale la pena in molti casi, ma quando le stelle si allineano, CSV ha più senso.

CSV è utile quando hai solo una serie di valori che si riferiscono ad alcune informazioni e sai che salverai sempre valori per ogni campo.

XML ha il vantaggio di avere dati auto-descrittivi (tag) e di avere una gerarchia, il che ti dà molta più flessibilità nel modo in cui memorizzi i dati.

Puoi avere una gerarchia molto più complessa, ecc. e una struttura con XML vs. CSV. Offre molta più flessibilità.

Ho trovato un interessante test delle prestazioni in rete. Dio esempio di svantaggi di XML quando le funzionalità di XML non sono necessarie.

" Ho provato l'esperimento di Steven da un'altra angolazione. Ho riempito un Excel XP foglio di calcolo con un numero a una cifra, salvato in XML e in a file di testo delimitato da virgole (CSV). Ho quindi compresso entrambi con WinZip e poi aperto entrambi con Excel. Ecco cosa ho trovato:

Il file XML era 840 MB, il CSV 34 MB - una differenza del 2.500% Compresso, il file XML era 2,5 MB, il CSV 0,00015 MB (150 KB) - un 1,670% differenza.

Altrettanto drammatico è il tempo impiegato per decomprimere e rendere i file come un foglio di calcolo Excel: ci sono voluti circa 20 minuti con il file XML; il CSV ha impiegato 1 minuto - una differenza del 2000%. "

http://www.xml.com/pub/ a / 2004/12/15 / deviant.html

Naturalmente a volte è alla moda e degno di nota. Tutto dipende dalla tua applicazione. Preferisco i file di configurazione in XML perché sono facili da analizzare. Considerando che, utilizzo i file CSV per DataGridView o i dump del database.

Questo WTF giornaliero: XML vs CSV La scelta è ovvia ti aiuterà a prendere una decisione ;)

XML è preferibile rispetto a CSV quando i dati non sono strutturati (schema sconosciuto) e saranno letti da un essere umano.

Probabilmente, a meno che i dati non contengano prevalentemente testo, CSV è destinato anche al consumo umano.

Anche rilevante, è se i tuoi dati sono bidimensionali o tridimensionali. CSV è più adatto per il testo bidimensionale e, grazie alla sua "verbosità, XML funziona bene con i dati tridimensionali.

L'intero " standardness " di XML è iperbole e non dovrebbe essere preso alla lettera. XML presenta enormi problemi tecnici e molte delle soluzioni non sono particolarmente eleganti, o in molti casi utili:

  1. Usa il testo per specificare la propria codifica (pollo e uovo?)
  2. Nessuno dei linguaggi di schema più comuni per XML funziona particolarmente bene.
  3. Il modo antico e banale di creare linguaggi di markup usando <tags> non è particolarmente utile come standard.
  4. XML tenta di retrodividere in modo retroattivo linguaggi di markup più potenti come quelli basati su SGML, creando in sé un pasticcio di eredità incompatibile.
  5. Resta ancora da stabilire se le sequenze di escape del testo XML possono funzionare o meno per qualsiasi cosa tranne i casi più semplici (ad es. dati amichevoli).

Per essere chiari, XML è probabilmente la scelta errata per il 90% dell'interscambio di dati per il quale viene attualmente utilizzato, poiché tali usi infrangono alcune o tutte le ipotesi di cui sopra.

Oltre alle altre risposte, XML consente di specificare in quale set di caratteri si trova il documento.

Ho scoperto che i maggiori vantaggi dell'XML sono la funzionalità di analisi e la rigorosa convalida che è pronta all'uso con la maggior parte delle librerie XML. L'insistenza sulla formalità e il messaggio di errore di facile comprensione (xyz non chiuso nella riga x, colonna y) sono di reale aiuto rispetto alla ricerca di valori rotti o comportamenti sconosciuti, a causa di un errore nel file CSV.

CSV è più leggero se si desidera spostare le cose poiché è normalmente 2 volte più piccolo di XML

XML è standard e non sarà colpito dalla versione di CSV di diversi sistemi operativi

Non ho abbastanza reputazione per commentare la risposta pertinente, ma qualcuno ha suggerito di comprimere l'XML come un modo per ottenere parità di dimensioni con i formati CSV. Anche se questo è vero, a volte la compressione XML può tornare a morderti. Se stai trasferendo dati XML da un punto all'altro e non riesce, è bello poter leggere l'XML e capire cosa è andato storto. Se l'XML è compresso e il trasferimento non riesce, a volte non è possibile decomprimerlo ed esaminarne il contenuto. In altre parole, la compressione di XML annulla il vantaggio di leggibilità umana che ha.

Direi che usi XML (e o JSON) perché un giorno tu o qualcuno (con un carattere irascibile e una grande collezione di armi) potresti dover trovare un errore nei dati CSV.

Quindi sì, sto dicendo leggibilità, non dimenticare di pensare all'altro ragazzo! Potrebbe pensare a te.

XML fornisce un modo per taggare i tuoi dati con metadati (forniti dai nomi dei tag e dai nomi degli attributi), mentre CSV no. Associare ciò alla capacità di definire gerarchie strutturate e rendere XML più semplice da comprendere se fornito solo con i dati, mentre CSV richiederebbe uno strumento o un documento di accompagnamento per descrivere come ogni valore viene interpretato.

Puoi attraversare facilmente i dati XML anche quando disponi di dati complessi.

Controlla questi collegamenti:

E ancora una volta per XML: la X in XML sta per E xtensible (lo so, non proprio mnemonico :-P). Ciò significa che, con l'aiuto del meccanismo dello spazio dei nomi XML, puoi unire due lingue XML che ti piacciono e combinarle nel documento stesso . Dato che esiste un solo "linguaggio" CSV (senza contare le miriadi di stili delimitatori), XML può gestire molta complessità e questo in modo modulare.

Questo, tuttavia, è il vantaggio di CSV: se disponi davvero di dati tabulari, la sintassi XML è molto spesso eccessiva.

Ho anche scoperto che alcuni generatori / parser di cv hanno molte difficoltà con i dati di testo generali. Stringhe di testo lunghe con molti ritorni a capo e virgole e virgolette, ecc. Ecc., Rendono la vita davvero difficile quando si tratta di manipolare un CV.

A SSMS piace troncare il CSV per divertimento.

Strutturato, leggibile dall'uomo, più facile da modificare, validazione, analizzabilità, trasformabilità, digitazione, spazi dei nomi, potenti librerie dietro di esso, sono tutti tra i molti motivi.

Soprattutto sebbene sia standard.

  1. Esistono parser ed emettitori esistenti in ogni lingua e database
  2. Si occupano della codifica per me
  3. Hanno a che fare con la fuga per me

Questo è tutto ciò che conta per me.

Certo, c'è un modo semi-standard per scappare in CSV (cioè " il modo in cui Excel lo fa "), e non è esattamente difficile scrivere te stesso, ma ci vuole un po ' tempo. E poi devi essere implicitamente d'accordo su un personaggio che codifica fuori banda. Ma poi, poiché è così semplice, le persone cercano di scriverlo da soli e invariabilmente rovinano il n. 2 o il n. 3.

JSON incontra anche # 2 e # 3 e si sta avvicinando al soddisfacente numero 1. È anche probabilmente più semplice, almeno per i file non documentali. Non sorprende, mi ritrovo a usarlo sempre di più, internamente ed esternamente.

E lo preferisco anche perché è molto più leggibile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top