È CSV considerato una buona opzione contro XML e JSON per i linguaggi di programmazione?
Generalmente uso XML e JSON (o talvolta un file di testo normale) come memoria di file piatta. Tuttavia, recentemente mi sono imbattuto in un'implementazione CSV in PHP . Generalmente ho visto CSV utilizzato per gli input nei file Excel , ma non l'ho mai usato con la programmazione. Sarebbe meglio di XML o JSON in qualche modo?
La risposta è, dipende.
CSV è ottimo per determinati casi d'uso. Ad esempio, come formato "streaming" per dataset di grandi dimensioni, è più semplice eseguire lo streaming rispetto a XML / JSON e i file CSV occupano molto meno spazio di archiviazione. Lo uso per lo streaming di set di dati nell'intervallo di gigabyte in cui altri formati sono poco pratici.
È anche veramente comune in alcuni settori quando si tratta di sistemi e flussi di lavoro legacy. Prova a importare JSON in MS Excel.
L'ODI ha recentemente commentato il CSV, definendo il 2014 "L'anno del CSV"
Per una "corretta" formattazione CSV, considera l'utilizzo del tipo mime CSV nelle risposte HTTP.
Sicuramente no.
CSV è un formato di tabella che si adatta molto bene ai set di dati o ad altri dati tabulari. Ma non tutti i dati sono tabulari! Più in generale, vogliamo serializzare grafici oggetto . Questo può essere difficile nei seguenti casi:
Vogliamo inoltre essere in grado di de-serializzare in modo affidabile gli oggetti dal nostro formato di archiviazione.
È principalmente una lingua markup estensibile. Può anche essere dotato di cornici per scarpe per archiviare strutture di dati generali. Il supporto linguistico per ID significa che è possibile creare grafici complessi, sebbene sia meglio utilizzare per gli alberi. Un documento può essere testato per la correttezza rispetto a una specifica. Ci sono vari problemi con questo formato che possono renderlo poco pratico, come l'estrema verbosità.
È principalmente un modo per memorizzare oggetti semplici alberi . Non c'è supporto per i grafici generali. JSON non ha concetto di tipo oltre i primitivi string , intero , float , booleano , null e i tipi di raccolta array e oggetto .
Più facilmente inteso come estensione di JSON. Ha una nozione di alias che consente di creare grafici di oggetti con complessità arbitraria. Ha un concetto di metadati come tag che può essere usato per una corretta digitazione.
Non ha nulla, tranne un singolo tavolo. Se vogliamo archiviare i grafici degli oggetti, dovremmo usare uno schema come
#ID,Type,Field1,Field2,...,FieldN
1,String,foo
2,String,bar
3,Array<String>,1,2
Ci sono molti dialetti di CSV che non concordano su delimitatori, terminatori di riga, citazioni, caratteri di escape e molti altri problemi che lo rendono inadatto per dati generali (binari). Tutto ciò rende piuttosto difficile l'elaborazione dei dati CSV.
In pratica, le cose semplici sono difficili o impossibili con CSV quando lo si utilizza come formato di serializzazione generale.
Questa critica non si applica quando la si utilizza per archiviare dati veramente tabulari come fogli di tempo o una serie di misurazioni. Qui, CSV (spesso nella variante dei valori separati da tabulazioni) è solitamente più compatto e più facile da usare rispetto agli altri formati di dati.
Devo anche dire che dipende da cosa stai cercando di ottenere. Per molti problemi non importa molto quello che si sceglie se il problema è abbastanza piccolo e la scelta si adatta bene al sistema esistente.
Avere un sistema legacy e provare a calzare in un nuovo formato a volte può essere un problema in quanto hai introdotto più complessità e hai un nuovo sistema di input per il debug. L'ho visto molto quando le nuove persone preferiscono qualcosa di diverso da ciò che esiste, o quando appare un nuovo formato e vogliono sperimentarlo. Questa può o non può essere una buona idea, dipende dalle circostanze.
Anni fa ho lavorato su un sistema di database grafico di ricerca che dipendeva da file CSV di vari formati. L'importatore di file CSV creava grafici per noi e aveva molti anni di lavoro per eseguire il debug e ottimizzare il codice. Era veloce e flessibile e lo useremmo volentieri per avviare grandi progetti di ricerca. Quando XML è apparso sulla scena, abbiamo aggiunto un importatore XML, ma non era necessariamente un miglioramento in termini di velocità o di complessità, e certamente XML non era più adatto a esprimere strutture di grafici rispetto a CSV. JSON è molto più bello (e terser) di XML ma è simile sotto molti aspetti quindi mi aspetterei un risultato simile quando creo un nuovo importatore su quel sistema.
Ad un certo punto nel tempo avevamo un cliente che portava una grande quantità di dati nel formato "cobol" (come lo chiamavamo noi), file con linee di lunghezza variabile contenenti marcatori che indicava come interpretare i byte che seguivano su quello linea. Veniva da un tempo in cui lo stoccaggio era costoso, quindi la compattezza era un requisito. Abbiamo importato tali dati convertendoli in formato CSV al volo e inserendoli nell'importatore CSV. È stato facile da fare e ha ridotto al minimo la quantità di debug e di manutenzione, che sono buone cose. Se dovessimo importare quel tipo di dati per tutto il tempo, potremmo averlo integrato direttamente nel sistema per ottenere miglioramenti in termini di prestazioni ed efficienza.
Quindi, dipende da cosa stai facendo e da cosa fa il sistema sottostante. Nel mio esempio l'importatore CSV è stato solidamente ingegnerizzato e affidabile. Esiterei a dirti che un formato era migliore o peggiore senza capire cosa succede negli altri livelli che sto costruendo. Adoro JSON e lo preferisco, ma so che date certe strutture dati complesse e set di dati abbastanza grandi, i file CSV possono essere fatti funzionare molto bene.
No.
CSV non è davvero un singolo formato. Esiste un'ampia varietà di stili per l'escape, i separatori e altri problemi di formattazione che hanno molti file CSV in the wild.
Se lo utilizzerai come archivio di file flat, l'uso di JSON ti servirà molto meglio. JSON esegue il mapping da e verso gli oggetti con molto meno fastidio di quanto non possa fare a meno di CSV per farlo.
Vorrei strongmente sconsigliarlo. Potrei essere OK per l'output CSV ad un certo punto (se l'utente lo richiede). Ma non è adatto per scopi di archiviazione / importazione. Ciò è dovuto principalmente al fatto che "CSV" è molto mal definito. La "C" indica "virgola" o "carattere" separati? Come trattate le stringhe di testo che contengono caratteri di escape come "? Ogni dannata implementazione CSV tratta i caratteri di escape ecc. In modo diverso, il che porta a file che possono essere esportati, ma non importati, ecc.
Excel è una buona dimostrazione: nella versione inglese usa "," come separatore. In Germania usa ";". Quindi una versione tedesca soffoca sui file CSV in inglese e viceversa ...
Il suo punto di forza è la leggibilità umana, che non dovrebbe essere sottovalutata. Ma non mi fare affidamento su di esso come un formato di archiviazione, è troppo fragile per questo scopo. Se devi esportare file per umani, potresti usare CSV ma anche in quel caso proverei ad usare una libreria che scrive su file xlsx (sono disponibili gratuitamente).
In generale NO. Perché? JSON e XML ci sono fondamentalmente per sbarazzarsi del temuto CSV. Sono gli approcci strutturati di ciò che è stato fatto per lungo tempo non strutturato con CSV. Sì, ci sono alcuni casi d'uso in cui il CSV è ancora preferito, ma in generale in 9 casi su 10 è meglio non usare CSV.
Leggi altre domande sui tag programming-practices csv