Convertire CSV in TSV

Una grande parte dei file che arrivano con estensione .csv sono separati da punto e virgola. Excel li scrive così in ogni locale in cui la virgola è il separatore decimale, che è la maggior parte dell’Europa continentale e gran parte del Sud America, perché un file che usa la virgola per entrambi i compiti sarebbe illeggibile. Anche gli export delimitati da pipe compaiono, per lo più da sistemi bancari e di telecomunicazioni più vecchi.

Il parser qui capisce quale carattere sia guardando al file piuttosto che al suo nome, quindi un export con punto e virgola si converte senza che gli si dica nulla. Dove questo fallisce è un file a colonna singola: senza alcun separatore presente ovunque, ogni candidato è ugualmente assente e il rilevamento non ha nulla su cui basarsi. È a questo che serve il controllo del separatore su questa pagina, ed è l’unica situazione in cui ne avete bisogno.

Una virgola è un cattivo delimitatore per la ragione specifica che appare costantemente nei dati reali. Gli indirizzi hanno virgole. Le descrizioni dei prodotti hanno virgole. I nomi di aziende che finiscono in «, Inc.» hanno virgole. Ognuno di quei campi deve essere avvolto in virgolette, e ogni consumatore del file deve implementare correttamente la convenzione delle virgolette, comprese le virgolette raddoppiate dentro un campo tra virgolette e i newline dentro uno, prima di poter ritrovare i confini delle colonne.

I tabulatori sono quasi assenti dal tipo di dati che le persone mettono nelle tabelle, quindi il delimitatore e il contenuto smettono di competere. Dopo questa conversione il campo «Berlin, Germany» appare nel file esattamente così, senza virgolette sulla riga, e qualsiasi cosa si divida su un tabulatore lo recupera. Questo è l’intero argomento, ed è un argomento di affidabilità piuttosto che di dimensione o velocità.

Il controllo offre rilevamento automatico, virgola, punto e virgola, tabulatore e pipe. L’automatico funziona quasi sempre, perché un file con più colonne dà al rilevatore abbondanza di prove ed è bravo a leggerle.

Nomina il separatore esplicitamente in due casi. Il primo è un file a colonna singola, dove non c’è nulla da rilevare. Il secondo è un file in cui un campo è stipato del carattere sbagliato (una colonna di note piena di punti e virgola in un export delimitato da virgole) il che può lasciare il rilevatore scegliere il carattere che appare più spesso piuttosto che quello che significa qualcosa. Se l’anteprima del risultato ha una colonna dove vi aspettavate sei, o sei dove ne aspettavate una, quella è l’impostazione da cambiare per prima.

I tabulatori si trovano dentro i campi CSV, di solito perché qualcuno ha incollato da una pagina web o da un altro foglio di calcolo in una cella. Nel file sorgente è innocuo: il delimitatore è una virgola, quindi il tabulatore è un carattere ordinario. Nell’output non lo è, e il convertitore lo gestisce avvolgendo quel campo in virgolette doppie.

Il risultato è corretto e un parser completo lo gestisce. Il problema è che TSV viene scelto proprio da persone che non useranno un parser completo: `cut -f` conta i caratteri di tabulazione e non ha mai sentito parlare di un segno di virgoletta, quindi da quella riga in poi vede un campo di troppo e ogni colonna dopo è spostata di uno. Se una pipeline sta producendo output disallineato su una manciata di righe su migliaia, questa è quasi sempre la causa. Eliminate i tabulatori dalla sorgente prima di convertire piuttosto che rattoppare a valle.

Un export europeo delimitato da punto e virgola di solito scrive 1234,56 dove un file in locale inglese scrive 1234.56. La conversione non traduce quello, e non dovrebbe: non ha modo di sapere se 1.234 significhi uno e qualcosa o milleduecentotrentaquattro, e indovinare corromperebbe ogni prezzo nel file.

Ciò che accade invece è che il valore resta esattamente come scritto, e poiché non sembra un numero al parser, resta testo. Quindi una colonna di prezzi europea arriva nel TSV intatta e incolume, e qualunque cosa legga il file dopo deve essere informata della convenzione decimale. In R è `dec = «,»` sulla lettura; in pandas è `decimal=«,»`. Impostarlo lì è più sicuro che fare un trova-e-sostituisci sul file, che riscriverebbe anche i separatori delle migliaia e qualsiasi virgola rimasta nelle colonne di testo.

La conversione non è una sostituzione a livello di byte di un separatore con un altro. Il file è analizzato in righe e scritto di nuovo, e lungo il percorso i valori che sembrano numerici sono letti come numeri. `1e5` diventa 100000. `true` e `false` diventano booleani e sono riscritti come parole minuscole. Un campo vuoto diventa un null ed è riscritto come campo vuoto, che è l’unico caso in cui nulla di visibile cambia.

La vittima è lo zero iniziale. Una colonna di codici postali che contiene 01234 arriva nel TSV come 1234, e un numero di parte con padding di zeri perde il suo padding silenziosamente. Il test per capire se una colonna è a rischio è se sommare due dei suoi valori significherebbe qualcosa: codici postali, numeri di telefono, riferimenti di conto e numeri di parte falliscono tutti il test. Se il vostro file ha una tale colonna, guardatela nell’output prima di caricare il risultato ovunque.

I campi sono quotati nel TSV solo quando devono esserlo: quando contengono un tabulatore, una doppia virgoletta o un’interruzione di riga. Tutto il resto è scritto nudo. Un CSV che è arrivato con virgolette attorno a ogni campo (alcuni esportatori lo fanno incondizionatamente) esce con quasi nessuna, che è una riduzione sostanziale di dimensione su un file largo e un grande guadagno di leggibilità quando lo aprite.

Una doppia virgoletta dentro un campo che ha bisogno di virgolette viene raddoppiata, la stessa convenzione che usa CSV. Vale la pena saperlo se il file va da qualche parte che si divide ingenuamente, perché una colonna di testo libero che contiene segni di virgoletta è l’altra cosa che produce un campo quotato in un formato in cui nessuno se lo aspetta.

Le righe sono separate da un singolo newline piuttosto che da una coppia ritorno a capo e newline, e il testo è UTF-8 senza byte order mark. È ciò che si aspettano una pipeline Unix, un Git diff, R e pandas, ed è ciò che la maggior parte degli strumenti Windows ora accetta anch’essi.

L’assenza di un byte order mark vale la pena nominarla perché ha una conseguenza: facendo doppio clic sul file per aprirlo in Excel su Windows mostrerà i caratteri accentati come mojibake, dato che Excel ripiega sulla code page di sistema quando non c’è un marchio che gli dica altrimenti. Aprire il file tramite Dati, Ottieni dati, Da testo/CSV e scegliendo UTF-8 lo evita. Se la destinazione è Excel piuttosto che uno script, convertire invece in XLSX elimina la questione.

Entrambi i formati sono testo semplice ed entrambi i lettori sono semplice JavaScript, quindi la conversione gira interamente su questa pagina. Nessuna richiesta porta il file da nessuna parte, non c’è coda e non c’è livello, il che conta perché un CSV è molto spesso un elenco di clienti, un export di ordini o un dump di sistema che sarebbe imbarazzante da spiegare di aver caricato.

Il limite è la memoria piuttosto che la policy. Il file è letto in righe e l’intera tabella esiste in una volta prima che qualcosa venga scritto, quindi decine di megabyte è routine e le centinaia sono dove una scheda del browser comincia a faticare. Oltre quello, un parser in streaming in uno script è lo strumento appropriato, e dirlo è meglio che fallire a metà di un export molto grande.

Se la destinazione è una schermata di import che dice CSV, lasciatelo come CSV. Un numero sorprendente di esse intende la parola letteralmente e rifiuterà un file delimitato da tabulazione per quanto sensata sia la scelta, e litigare con un modulo di caricamento non è una lotta che vale la pena combattere.

L’output separato da tabulazioni guadagna il suo posto quando qualcosa sta per dividere il file su un carattere piuttosto che analizzarlo: una pipeline di shell, uno script R, un incolla in un programma con un import delimitato da tabulazione, un’occhiata veloce con `cut`. Se invece i valori devono mantenere i loro tipi lungo il percorso, nessun formato delimitato può aiutare: un file di testo non può distinguere il numero 7 dalla stringa «7», e JSON, NDJSON o Parquet è la destinazione onesta.