XLSX naar TSV omzetten

De reden om tab-gescheiden uitvoer te verkiezen is smal en praktisch. Adressen bevatten kommas. Productomschrijvingen bevatten kommas. Getallen genoteerd in de helft van Europa bevatten kommas. In een kommagescheiden bestand moet elk daarvan tussen aanhalingstekens, en elke afnemer van het bestand moet aanhaling correct implementeren om de kolomgrenzen terug te vinden.

Tabs komen zelden in de data voor, dus het scheidingsteken en de inhoud concurreren niet meer. Deze omzetting schrijft een cel met "Widget, klein" precies zo, zonder aanhalingstekens. `cut -f2` vindt het. `awk -F"\t"` vindt het. Er hoeft niets geparst te worden; er hoeft alleen gesplitst te worden.

Tabs komen af en toe toch in rekenbladcellen terecht — geplakt, per ongeluk getypt, meegekomen uit een systeemexport. Dan schrijft de omzetting die cel tussen dubbele aanhalingstekens, want het alternatief is een rij die stilletjes een extra kolom krijgt.

Dat is correcte uitvoer en een volwaardige parser handelt het af, maar de shelltools waarvoor dit formaat wordt gekozen doen dat niet: `cut -f` telt tabs en weet niets van aanhalingstekens. Levert een pijplijn misvormde uitvoer op een handvol rijen, dan is dit vaak de oorzaak. Verwijder tabs in het bronblad in plaats van downstream te patchen.

Een werkmap kan dertig bladen bevatten. Een tab-gescheiden bestand bevat één tabel met één koprij, en er is geen syntax voor iets anders. De omzetting neemt daarom het eerste blad en laat de rest liggen — het enige gedrag dat niet stilletjes een samengevoegd bestand oplevert dat niemand vroeg.

Is het gewenste blad niet het eerste, verplaats het dan in de werkmap en zet opnieuw om. Heb je meerdere bladen nodig, zet dan meerdere keren om en houd de uitvoer apart — dat is wat een pijplijn toch wil.

Een rekenblad bewaart geen datum. Het bewaart een dagteller en een weergaveformaat, en de kalender die je in de cel ziet, is het formaat dat zijn werk doet. Omzetten leest de waarde, niet het kostuum, dus 1 januari 2024 komt aan als 45292.

De telling begint eind december 1899, wat verklaart waarom de getallen in de veertigduizenden liggen voor iets recents. Reken ze om waar ze naartoe gaan, in plaats van het rekenblad eerst te herformatteren, want een als tekst geschreven datum is een nieuw parseerprobleem in plaats van een rekenprobleem.

De koprij levert de kolomnamen, en de verzameling kolommen is de vereniging van de sleutels gevonden over elke rij in plaats van alleen de eerste. Een blad waar een later blok rijen een extra veld draagt, geeft toch een bestand met dat veld in de koprij.

Lege cellen blijven lege velden in plaats van te verdwijnen, dus elke regel heeft hetzelfde aantal tabs en het bestand blijft rechthoekig. Dat is precies wat een positioneel hulpmiddel nodig heeft.

Een code opgeslagen als tekst in de werkmap komt met zijn nullen intact terug: 007 blijft 007. Dat is de moeite waard om te vermelden, want het tegenovergestelde is zo gewoon — een CSV geopend in Excel en opnieuw opgeslagen maakt zulke kolommen tot getal.

Wat dit niet kan herstellen, is schade die al gebeurd is. Bevat de werkmap zelf al 7 omdat iemand vorige maand achteloos een CSV importeerde, dan bevat de TSV ook 7. Controleer een codekolom in het bronblad voor het omzetten.

Regels worden gescheiden door een enkele newline in plaats van een carriage-return-paar, en de tekst is UTF-8. Dat is wat een Unix-pijplijn, een Git-diff en de meeste moderne importtools verwachten.

De uitvoer is platte tekst en overleeft dus ook plakken in plaats van uploaden — in een databaseclient, een formulierveld, een chatbericht, een teksteditor. Die route is de moeite waard te onthouden wanneer de bestemming een importscherm heeft dat je niet vertrouwt.

Postgres leest deze vorm rechtstreeks met COPY, en het detail om te kennen is wat het met lege velden doet: in zijn tekstformaat is een leeg veld een lege string, geen null — alleen het teken \N betekent null.

R leest het met `read.delim`, dat al tab aanneemt, en pandas met `sep="\t"`. Geef in elk daarvan expliciet het type op voor alles dat een identifier is in plaats van een hoeveelheid.

Het parsen en schrijven gebeuren allebei in je browser, dus er wordt niets geüpload en er is geen wachtrij, geen niveau en geen rijlimiet anders dan het geheugen van je machine. Een werkmap van vijftigduizend rijen over zes kolommen zet in een moment om.

De grens is het hele bestand tegelijk in het geheugen houden, wat tientallen megabytes ruim binnen bereik brengt en honderden op het punt waar een tabblad gaat kraken. Daarboven is een streamende lezer in een script het juiste gereedschap.

Kies CSV als de bestemming een importscherm is dat het met naam noemt, want een tool die CSV zegt, bedoelt dat vaak letterlijk. Kies NDJSON als de waarden hun type moeten behouden onderweg, want een gescheiden bestand kan het getal 7 niet onderscheiden van de tekst "7".

Kies SQL als de rijen naar een bestaande tabel gaan, en Parquet als ze naar een analyse-engine gaan die ze herhaaldelijk bevraagt. TSV is het juiste antwoord voor één specifiek geval: teksttools die op een teken splitsen, waar dat teken niet in de data mag voorkomen.