NDJSON naar INI omzetten

De mismatch is compleet, en dat verdient het eerst genoemd te worden. Een INI-bestand is een verzameling genoemde secties met platte sleutel-waardeparen — de beschrijving van één ding, meestal één toepassingsconfiguratie. Een NDJSON-bestand is een reeks records zonder naam, zonder betekenisvolle volgorde en zonder vaste lengte.

Er is geen weergave die beide recht doet. De omzetting gebruikt de enige naam die een record in een lijst heeft: zijn positie. De eerste regel wordt [0], de tweede [1], enzovoort. Dat is getrouw, er gaat niets verloren, en het levert een bestand op waarvan de sectienamen niets betekenen.

Zijn de records werkelijk losse configuraties — één per host, per omgeving, per klant — dan maakt het hernoemen van [0] en [1] naar de echte namen er een bruikbaar bestand van, en dat is de hele klus. De sleutels eronder kloppen al.

Zijn de records data in plaats van configuratie, dan helpt hernoemen niet. Honderd secties genoemd naar posities is geen configuratiebestand maar een tabel in de verkeerde notatie. CSV, JSON of een database is dan wat je zoekt, en elk daarvan is één omzetting verwijderd van dezelfde bron.

Dit is waar mensen op vastlopen. Een bestand met precies één regel is nog steeds een lijst van één, en het resultaat is een sectie [0] met elk veld van dat record erin — niet de nette INI die je van hetzelfde object apart zou krijgen.

De oplossing zit in het bronformaat, niet in het resultaat: sla die ene regel op als .json en zet JSON om naar INI. Daar worden de sleutels van het record rechtstreeks de sectiekoppen, en het bestand ziet eruit alsof iemand het schreef.

INI ondersteunt secties en niets binnen secties. Op dit paar is dat ene niveau al ingenomen door het recordnummer, dus elk veld van een record — inclusief eventuele nesting — moet in de sleutelnaam passen.

Een record met een server-object met een poort geeft een regel server.port binnen de genummerde sectie. Niets gaat verloren, maar twee records met dezelfde geneste structuur delen structureel niets meer: het zijn twee secties die toevallig dezelfde sleutelspelling hebben.

Een record met een lijst toegestane hosts levert sleutels op genaamd 0, 1 en 2 onder het pad van dat veld. Samen met de genummerde secties kan een uitvoer eindigen met een regel hosts.0 binnen een sectie genaamd [2] — leesbaar en niet fraai.

INI-parsers die lijsten begrijpen, verwachten meestal één regel met kommagescheiden waarden. Heeft de toepassing die conventie, voeg de array dan vóór het omzetten samen tot één string in de bron — dat is minder werk dan achteraf elke groep met de hand aanpassen.

Een JSON-waarde true wordt true, een getal zijn cijfers, een null de sleutel met niets na het isgelijkteken, en een string precies zoals hij was. Aanhalingstekens komen alleen waar de waarde er anders niet gelijk zou uitkomen: rond een waarde met een spatie aan begin of eind, een waarde die al met aanhalingstekens begint en eindigt, en een waarde met een regeleinde.

Een regeleinde in een waarde is de zaak om te noemen, want een INI-item is één regel. Het wordt geschreven als een backslash gevolgd door een n binnen de aanhalingstekens, wat voorkomt dat de tekst erna losse regels wordt — of, waar een vervolgregel op een sectiekop lijkt, een sectie die in geen enkel record voorkwam.

INI ondersteunt commentaar — een regel die begint met een puntkomma of een hekje — en de lezer van deze site respecteert beide in de andere richting. JSON kent geen commentaar, dus het omgezette bestand komt zonder aan.

Omdat de reden om een INI te maken bijna altijd is dat iemand het gaat lezen of bewerken, is het schrijven van die regels de eerste zinvolle bewerking. Welke sectie omgevingsspecifiek is, welke waarde ergens anders moet matchen: dat kon de bron nooit meedragen en is precies waar het doelformaat voor is.

Elke waarde in een INI-bestand is tekst. Of 8080 een getal is, of true een boolean is en of 007 zijn nullen houdt, beslist wat het bestand leest — Python's configparser maakt het expliciet met getint en getboolean.

Dat is een verlies ten opzichte van de bron, waar de types wel vaststonden, en meestal geen probleem, want een toepassing die INI leest, weet al wat elke instelling hoort te zijn. Waar het wel telt is bij identifiers met voorloopnullen.

De eerlijke stopregel voor dit paar: als het resultaat meer dan een handjevol genummerde secties heeft en je kunt ze geen echte naam geven, dan heeft de omzetting een andere vraag beantwoord dan je stelde. INI beschrijft één ding; een lijst records is niet één ding.

De alternatieven vanuit hetzelfde bestand liggen een klik verderop en zijn allemaal beter voor dat geval. CSV of een werkmap als iemand naar de records gaat kijken, SQL of Parquet als een machine ze gaat bevragen, TOML als je eigenlijk een lijst records in een configuratiebestand wilde — dat kent een array-of-tables-constructie die INI simpelweg mist.

De omzetting is gewone JavaScript in dit tabblad. Er wordt niets geüpload, er is geen account of wachtrij, en de gratis versie accepteert tot 100 MB — een limiet die geen configuratiebestand ooit haalt.

Dat weegt zwaarder dan de bestandsgrootte suggereert. Instellingendumps bevatten connectiestrings, API-endpoints, interne hostnamen en, vaker dan iemand toegeeft, een wachtwoord dat eigenlijk een omgevingsvariabele had moeten zijn.