Perché continuiamo a utilizzare CSV? [chiuso]

Nel tuo caso, sembra che CSV non sia una buona scelta a causa della mancanza di specifiche rigide.

Per dati non banali non è la scelta giusta.

Perché / Quando CSV è una buona scelta? Probabilmente troppi esempi da menzionare, i vantaggi della semplicità per i dati flat sono ovvi. Finché i dati sono disinfettati / fugati correttamente non ci sono problemi. In generale, comunque, tutti questi casi sarebbero semplici / banali. Ovviamente, il delimitatore standard che appare nel contenuto è spesso un problema quando si ha a che fare con CSV.

Ma se stai facendo qualcosa di più complicato che ottenere un client non tecnico per inviare dati da un foglio Excel o qualche altro caso d'uso simile, allora CSV è probabilmente insufficiente per qualsiasi uso serio.

L'XML è un adattamento molto migliore (sì ancora di più di JSON) dal momento che è possibile fare specifiche dettagliate dello schema standardizzate per esso. (Senza contare che le specifiche / gli schemi godono della flessibilità di più stili di implementazione, XSD, DTD e Relax NG)

Per i sistemi a ciclo chiuso, specialmente dove la larghezza di banda è un problema, JSON può essere più adatto di XML, ma la mancanza di linguaggio di specifica dello schema spesso lo preclude dalle applicazioni di livello enterprise.

Consentitemi di buttare alcuni punti a favore del CSV:

• CSV è semplice (rispetto a qualsiasi alternativa suggerita in OP) per implementare e analizzare
• CSV è compreso da quasi tutti i software del pianeta (passati e presenti)
• CSV impone uno schema abbastanza piatto e semplice (esiste un unico elenco di campi semplice)
• CSV è più leggibile dall'uomo di XML, JSON o (UGH!) HL7 (V2.x, pre-xml)

Compatibilità con le versioni precedenti. Se il servizio Web delle organizzazioni esterne gestisce CSV e tutti gli strumenti esistenti gestiscono CSV, nessuna delle parti ha alcuna motivazione per passare a un nuovo servizio. Perché la tua organizzazione esterna inizierà a supportare un formato diverso? Nessuno con cui lavora può usarlo! Perché dovresti iniziare a produrre un formato diverso? Nessuna delle organizzazioni con cui lavori lo accetta!

Il problema reale che vedo qui è, perché i tuoi sviluppatori lanciano il loro codice CSV ogni volta? Se usavano una libreria CSV stabile e solida come la roccia, non avrebbe i problemi che descrivi. I problemi sono causati dagli sviluppatori che lanciano la propria soluzione invece di usare una libreria e onestamente non vedo come lo spostamento verso JSON o XML lo risolva magicamente. Avresti ancora persone che cercano di reindirizzarli invece di usare una libreria.

CSV è un po ' più veloce , di dimensioni più ridotte , molto facile da gestire (anche in Excel) e molte applicazioni esistenti lo capiscono, è uno standard ampiamente utilizzato

È ancora una prima scelta in molte situazioni.

Personalmente mi piace ancora molto quel formato. Ma io uso anche JSON, ma per altre applicazioni come l'interfaccia utente web.

Prima di tutto perché, anche se i consumare dati CSV possono essere (leggermente) non banali, la generazione è estremamente facile.

Vorrei anche sottolineare che né JSON né XML sono davvero più facili da ottenere (sia per il produttore che per il consumatore). In effetti, si deve a malapena guardarsi attorno per sapere che molti di persone cercano di usare espressioni regolari per analizzare i dati XML, anche se non c'è assolutamente dubbio che farlo non possa e non funzioni.

La maggior parte dei problemi che possono sorgere (e si verificano) con CSV possono (e lo sono) anche con JSON e XML. XML, in particolare, aggiunge molti più potenziali problemi. Una libreria per analizzare i dati XML è generalmente più grande, più lenta e più difficile da usare rispetto a una libreria simile per i dati CSV.

In primo luogo, sono d'accordo sul fatto che ci sono alcuni problemi molto reali con il formato:

• È scritto a caratteri stringenti.
  • Senza distinzione tra testo e valori numerici, Excel indovina e sbaglia i tuoi codici postali e numeri di carta di credito.
  • Non esiste un modo standard per rappresentare i dati binari.
  • Non esiste un modo standard per distinguere tra NULL e '' , che è un problema quando si importano file CSV in database SQL.
• Supporto scarso per "caratteri speciali".
  • La mancanza di riferimenti ai caratteri numerici come (XML &#xNNNN; o JSON \uNNNN ) significa che non esiste un modo standard per rappresentare caratteri di controllo o caratteri non ASCII.
  • Molte implementazioni non implementano correttamente interruzioni di riga all'interno di un campo.
• La mancanza di uno standard. C'è RFC 4180 , ma non è seguito universalmente.

Ma d'altra parte:

• Le alternative sono peggiori. JSON e XML, progettati attorno agli alberi, sono inadatti ai dati basati su tabelle, in particolare in termini di ...
• COMPATTEZZA! In XML, devi avere un tag iniziale e un tag finale per ogni colonna nella riga ogni . In CSV, scrivi solo le intestazioni delle colonne una volta.
• CSV è molto facile da generare.
• I non programmatori possono aprire file CSV in Excel.

Poiché molti analisti usano Excel (per le tabelle pivot e simili), ed è molto più facile generare CSV che stampare il formato nativo di Excel.

Nota a margine: visto quanti problemi ho riscontrato con Excel nella gestione dei file CSV, come la rimozione degli zeri iniziali e la perdita di precisione, probabilmente è un falso senso di semplicità.

Se c'è una cosa che non va in CSV, è che CSV appare così semplice che molti sviluppatori cercano di inventare i propri parser / scrittori e successivamente incolpare CSV per non aver gestito correttamente l'escape. Con un buon parser CSV (molti buoni là fuori), non ci saranno problemi.

Qualcuno citato CSV non è buono per dati non banali, ma non sono d'accordo. L'XML consente di dati non banali perché il set di dati diversi può essere inserito in diversi tag "container". Con CSV, puoi sempre inserire dati diversi in file diversi per ottenere lo stesso effetto.

Inoltre, a mio parere, l'uso dell'XML per il trasferimento dei dati fondamentalmente va contro lo scopo dell'XML: il trasferimento dei dati di solito implica un contratto stabile tra fornitori e consumatori mentre XML è destinato a trasportare informazioni espandibili soggette a interpretazione al momento del consumo.

Suppongo che i CSV siano buoni solo quando hai solo dati di testo semplici, con solo virgole e punto e virgola alla fine.

Dati architettonici dell'albero o dati compositi difficilmente possono essere utilizzati con CSV.

CSV è solo una semplice matrice 2D di testo come in Excel, niente di molto ...

Si tratta davvero di mainframe ed eccelle qui.

I mainframe perché quei vecchi sistemi hanno capito come comunicare usando CSV. Quindi le grandi app che eseguono il dump dei dati possono leggerle e scriverle e non hanno motivo di cambiare ora.

Excel perché può aprire direttamente i CSV. In effetti, prende l'estensione .csv quando lo si installa. Gli utenti fanno semplicemente clic sull'icona dell'excel dall'aspetto un po 'buffo e si apre e crea una bella griglia con cui possono interagire.

Ora, le versioni moderne di Excel sono perfettamente in grado di leggere, per esempio, XML, direttamente. Ma per farlo, un utente deve capire un po 'di più che "doppio clic su quella foto". E fare doppio clic sull'immagine a destra può essere troppo chiedere in alcuni settori. . .

Ho visto molte risposte tecniche, ma sospetto che la ragione per cui le persone usano CSV è la stessa ragione per cui le persone usano molte altre tecniche / tecnologie: perché è quella con cui sono più familiari

perché lo uso?

1. il cliente lo desidera
2. è più veloce di xml sulla rete (carico di rete inferiore)
3. non è necessario nulla di più complesso per ottenere i dati
4. cross platform
5. leggibile dall'uomo
6. facile implementare lettori e autori per questo

ecc. ecc.