Il modo migliore per gestire i file delimitati

Quindi in genere un file CSV utilizza una virgola e il carattere restituito come delimitatori di campo e di riga.

Ciò si traduce in ovvi problemi con il testo che può contenere entrambi questi caratteri.

Ovviamente ci sono opzioni lì (scappandole) ma come fanno le persone a gestirlo? Usa personaggi diversi - pipe o tildas? Sfuggirli? Non usare file delimitati, dopo tutto è il 2010 e ora abbiamo XML?

Guardando almeno lo sforzo per una discreta possibilità di non vedere problemi.

(Giusto per essere chiari, questa è una domanda per curiosità piuttosto che per qualcosa di più solido - è qualcosa che mi sono imbattuto di volta in volta giocando con i dati, ci ho sempre aggirato ma normalmente sembra un po ', beh, sporco, e mi chiedevo quale fosse l'esperienza degli altri).

Secondo Wikipedia :

I campi con virgole incorporate devono essere racchiusi tra virgolette doppie.

E inoltre:

I campi con caratteri di virgolette doppie devono essere racchiusi tra caratteri di virgolette doppie e ciascuno dei caratteri di virgolette doppie incorporate deve essere rappresentato da una coppia di caratteri di virgolette doppie.

Non so chi l'abbia inventato, ma dimostra che alla fine devi fuggire. È l'unica soluzione solida. Tutto il resto è solo un nastro adesivo sopra il nastro adesivo: forse funziona per ora, ma alla fine ti imbatterai in un caso in cui hai bisogno di un'eccezione a eccezione di un'eccezione, e non ci vuole molto tempo prima che il tuo groviglio di regole è molto più complesso di quanto non fosse stata una semplice soluzione di carattere di fuga.

Sembra che i creatori di CSV abbiano prima tentato di evitare le virgole sfuggendo presentando una sintassi speciale tra virgolette doppie, che consentiva di salvare le virgole, ma poi qualcuno voleva salvare anche i caratteri con virgolette doppie, quindi hanno dovuto scappare a quel punto - usando stranamente il virgoletta doppia come personaggio di escape. Se avessero deciso di fuggire correttamente in primo luogo, la sintassi sarebbe ora più semplice.

Suppongo che tu abbia qualcosa del genere:

Foo,Baz,,,"Foo,Baz"

Se le stringhe che contengono il delimitatore non vengono quotate o salvate, non esiste un modo realmente affidabile per analizzare il file.

Puoi, tuttavia, esaminare i dati per analizzare e trarre conclusioni come:

• I float separati da virgola devono essere trattati come una stringa
• Se la riga precedente o successiva contiene meno delimitatori, saltare l'analisi di questa riga e registrarla
• Tratta "come"

Devi scrivere un parser per gestire cose del genere, ma non deve essere complicato.

Nella mia esperienza, l'importazione di discariche di massa da qualcosa come Excel comporta sempre la necessità di tornare indietro e rivedere alcune stranezze. La sfida è di dare il vostro programma appena abbastanza buon senso per quanto riguarda i dati in modo che non fa un inserto folle. Quindi rivedere ciò che è stato registrato e lavare / risciacquare / ripetere.

Una volta ho gestito una FAQ interna per una piccola azienda che utilizzava tutte le workstation Ubuntu. Una parte delle FAQ ha dato "scorciatoie da shell", e mi è venuto delimitato da pipe. Bene, le risposte erano anche tipicamente delimitate da pipe (cioè grep foo | qualcosa) e non citate o sfuggite. Sento quel dolore :)

Niente di sbagliato con CSV fino a un certo punto

CSV funziona bene per dati rigidamente definiti che è improbabile che cambino formato e che non generino molte sorprese sul parser del destinatario.

Ecco un utile elenco dei grandi gotcha:

1. Esc "" s entro "" s (il campo contiene delimitatore di campo)
2. "" s contenenti CRLF (il campo contiene delimitatore di riga)
3. Unicode (il formato di testo sottostante potrebbe essere insufficiente)
4. Terminatori di linea diversi per sistemi operativi diversi (è CR o CRLF o LF o NUL?)
5. Commenti incorporati (riga preceduta da #, //, -,; ecc.)
6. Gestione della versione (l'ultima versione del file contiene più o meno campi)
7. Differenziazione tra NULL e dati vuoti (, "", è vuoto ma ,, è nullo?)

Puoi affrontarlo con un'intestazione di metadati che descrive come analizzare i campi, ma puoi anche usare XML. È a causa di questo tipo di pasticcio CSV a forma libera che è stato inventato. L'approccio XML sembra troppo pesante per quello che potrebbe, a prima vista, essere un problema semplice.

Un'alternativa popolare è la strategia "delimitatore di caratteri strani". Questo aggira molti dei problemi di fuga sopra perché usi qualcosa come un | carattere (pipe) per la delimitazione dei campi e un CRLF per la terminazione dei record. Questo non aggira il problema del campo multilinea (a meno che tu non usi un contatore di campi) ma ottieni linee ben formattate per gli umani.

Nel complesso, se stai solo cercando un modo semplice per gestire questo tipo di file, nel mondo Java, potresti semplicemente lanciare OpenCSV . In questo modo si astraggono tutti i problemi in un quadro consolidato.

CSV è ancora un formato valido in molte situazioni, soprattutto perché deve essere ancora il modo più semplice per un cliente di scrivere dati che devono essere importati nella tua applicazione. Pochi dei nostri clienti amano avere a che fare con XML, forse perché è molto dettagliato e ha tutte quelle parentesi angolari "spaventose". È molto più semplice per loro avvolgere il cervello attorno a un semplice elenco di elementi separati da un personaggio concordato e anche concordare che lo stesso personaggio non sarà consentito nel contenuto di un campo.

Detto questo, devi ancora gestire correttamente l'input e verificare le situazioni in cui usano caratteri non validi. Ho iniziato a utilizzare FileHelpers per le mie esigenze di analisi CSV.

di solito mi attengo allo standard e sfuggirli. nella maggior parte dei linguaggi di programmazione è disponibile un buon supporto integrato o una buona libreria.

dipende dalla situazione in quale formato verrà utilizzato e CSV è un formato ragionevole per lo scambio di strutture di formati di dati semplici.

Dimentica CSV, usa JSON . Facile da scrivere, facile da analizzare. XML è così 2005 .

Di solito, quello che mi ritrovo a fare è ottenere un TSV (valori separati da tabulazioni) piuttosto che un file CSV, estrarre il file in Emacs e vedere quale dei pochi caratteri insoliti non utilizza MAI ($ è di solito una buona scelta qui), e poi converto tutte le schede in $.

Da lì, si può dire a GNU AWK di usare $ come separatore di campo e Bob è tuo zio.