De eerste keer dat YAML me goed verbrandde, was het een landcode. Ik verplaatste een locale configuratie uit een Laravel-project JSON-bestanden naar een implementatievriendelijk YAML-formaat, met de hand converteren terwijl ik ging omdat "het gewoon een beugel veranderde in deuk." Een van de inzendingen was Noorwegen: "country": "NO". In YAML, niet geciteerd, dat' is geen string - onder de YAML 1.1-regels die PyYAML en tal van andere parsers nog steeds toepassen, NO is de booleaans false. Het implementatiescript, geschreven in Python, evalueerde vrolijk Noorse gebruikers als country: false en stuurde ze naar de uitwijklocatie. Deze bug heeft een naam - de gemeenschap noemt het het Noorwegen-probleem - en ik leerde het op ambachtelijke wijze ontdekken, één verward ondersteuningsticket tegelijk.
Hand-converting JSON naar YAML ziet er triviaal uit en is eigenlijk een mijnenveld, omdat de twee formaten totaal verschillende ideeën hebben over wat een bloot woord betekent. In JSON is alles expliciet: strings hebben aanhalingstekens, cijfers niet, true/false/null zijn trefwoorden, einde verhaal. In YAML krijgt een niet-geciteerde scalaire uitgelegdpiepsel no wordt vals, 3000 wordt een geheel getal, 1.10 wordt de vlotter 1.1 (tot ziens, versie string), 08 verstikt sommige parsers als een ongeldig octaal, en een waarde met een verdwaalde dubbele puntruimte wordt een geneste kaart wanneer je het het minst verwacht. Elk van deze is een stille gegevenscorruptie - het bestand parseert prima, de typen zijn gewoon verkeerd.
a JSON naar YAML-converter dat begrijpt deze regels levert je de leesbaarheid op waarvoor YAML is uitgevonden zonder het type roulette degene die ik voor Toolz.dev heb gebouwd, detecteert elke dubbelzinnige scalair - booleaanse look-alikes, getal-look-alikes, YAML 1.1 oudere waarden, tekenreeksen met speciale tekens - en citeert precies die, dus wat een tekenreeks in je JSON was, is nog steeds een tekenreeks nadat de volgende tool de YAML parseert. Dat " precies die " is belangrijk: citeren alles Zou ook veilig zijn, maar de output ziet er niet meer uit als idiomatische YAML, en idiomatisch is het hele punt.
Deze gids behandelt hoe de conversie omgaat met de scherpe randen van YAML, waarom JSON technisch gezien al YAML is (en waarom dat feit u niet helpt), en de Kubernetes-, CI- en Docker-workflows componeren waar deze conversie wekelijks plaatsvindt.
tl;dr: Plak Json in de Toolz.dev JSON naar YAML Converter, kies 2 - of 4-spatie inspringing, en krijg schone blok-stijl YAML met type-veilige citaat -
"3000"blijft een touwtje,"no"blijft een touwtje,"1.10"Blijft een versie. de belangrijkste volgorde is bewaard, lege collecties komen uit als[]en{}, en alles draait aan de clientzijde, dus configuraties met geheimen verlaten uw browser nooit. Terugreis met de YAML-validatoren formatteer eerst de bron met de JSON-formatter.
Is JSON al geldig YAML?
Ja - en het' is de meest nutteloze "ja" in configuratiebeheer YAML 1.2 is expliciet ontworpen als een superset van JSON: elk geldig JSON-document parseert als geldige YAML. Je zou ruwe JSON in een Kubernetes-manifest kunnen plakken en kubectl zou het accepteren.
Niemand doet dit, omdat de reden dat YAML bestaat is Menselijke ergonomie. Kubernetes manifesteert zich, GitHub Actions-workflows, Docker Compose-bestanden, Ansible-afspeelboeken, Home Assistant-configures - dit zijn YAML omdat mensen ze voortdurend lezen en met de hand bewerken, en replicas: 3 onder een ingesprongen blok scant beter dan {"replicas":3} in beugels genesteld. Als iemand zegt "convert JSON naar YAML", bedoelen ze blokstijl Yaml: inspringing in plaats van beugels, - streepjes in plaats van arrays tussen haakjes, geen aanhalingstekens waar geen nodig zijn.
Die laatste clausule is waar de moeilijkheid leeft. Van JSON's alles-expliciete syntaxis naar de minimale syntaxis van YAML gaan Beslissen, voor elke string, of het zijn aanhalingstekens veilig kan verliezen- en die beslissing vereist het kennen van YAML's scalaire resolutieregels beter dan de meeste mensen betrouwbaar doen om 17.00 uur op vrijdag. Dat' is de werkelijke taak van een converter; het gedeelte tussen accolades en inkepingen is triviaal.
Wat breekt stilletjes als je met de hand converteert?
De mislukkingsgevallen vallen in vier families en ik heb ze allemaal in echte configuraties geraakt:
Booleaanse look-alikes. YAML 1.1 lost op yes, no, on, off, y, n (in verschillende behuizingen) als Booleans, en YAML 1.2 houdt true/false. PyYAML - nog steeds de standaard YAML-bibliotheek in de meeste Python-codebases - implementeert 1.1. Dus "debug": "no" met de hand omgezet naar debug: no HALD debug: false in uw Python Implementeer Tooling. het probleem van Noorwegen (NO → false) en zijn neef het Ontario-probleem (ON → true) zijn de grootste hits van deze familie.
nummers op nummer. "port": "3000" bekeerde tot port: 3000 is nu een geheel getal. Kubernetes doet ' Het kan je op sommige gebieden schelen en op andere gebieden moeilijk falen - env var-waarden moeten bijvoorbeeld strings zijn, en kubectl apply zal daar een geheel getal weigeren met een fout die het veld een naam geeft, maar niet de waarom. Versiestrings zijn erger omdat niets faalt: version: 1.10 parsen als de vlotter 1.1, en je implementatiescript rapporteert voor altijd met plezier de verkeerde versie. Leidende nullen - postcodes, telefoonnummers, octaal ogende ID's zoals 0755- rond de familie af.
speciale tekens. Een dubbele punt gevolgd door een spatie binnen een niet-geciteerde waarde begint een toewijzing (message: error: not found is een parseerfout of een geneste kaart, afhankelijk van de parser). a # Start een opmerking midden in de waarde. toongevend *, &, ! botsen met YAML's anker, alias en tagsyntaxis. Strings met nieuwe lijnen moeten ontsnappen of blokkeren scalaire.
de lege string. Ongeciteerde leegte in YAML is null, niet "". Elk JSON-veld met een lege tekenreeks moet geciteerd uitkomen of het verandert van type.
de bekeerder controleert elke string op alle vier de families en citeert degenen die deze nodig hebben - en alleen degenen die dat nodig hebben. production komt kaal uit de buurt omdat het ondubbelzinnig is; "3000", "no", "1.10", en "" Kom geciteerd omdat ze dat niet zijn. Er is ook een "quote alle snaren" twitteren voor wanneer je een parser voedt die je niet vertrouwt en wilt dat er helemaal geen scalaire resolutie gebeurt.
Hoe converteer je JSON naar YAML met de tool?
Stap 1: Plak je JSON
Elke geldige JSON werkt - objecten, arrays, diepe nesten, unicode. De knop Voorbeeld laden geeft u een realistische serviceconfiguratie die de interessante gevallen uitoefent: een numerieke tekenreekspoort, een boolean, een lege array, geneste kaarten Als uw invoer syntaxisproblemen heeft, rapporteert de converter de parser' exacte fout in plaats van een ingekort document te converteren; voor het zoeken naar waarheen ook De fout zit in een grote klodder, de JSON-formatter is de betere microscoop.
Stap 2: Kies inspringing
Twee spaties of vier. Twee is de overweldigende conventie: Kubernetes-documenten, voorbeelden van GitHub-acties, Docker Compose-referenties en de yamllint standaard gebruikt alles - maar sommige teams standaardiseren op vier voor leesbaarheid bij deep nesting, wat je ook kiest, de converter is er consistent in, inclusief het subtiele geval van lijstitems onder een sleutel, waarbij inconsistente handinspringing een klassieke bron van " mapping-waarden zijn hier niet toegestaan" fouten.
Stap 3: Converteren en beoordelen
De uitvoer verschijnt met lijn en byte telt Skim het een keer - niet voor correctheid (dat' s de converter' s taak) maar om gezond-heid-controle van de citerende beslissingen tegen uw verwachtingen Zien PORT: "3000" geciteerd terwijl NODE_ENV: production Het is niet de tool die je vertelt welke waarden gevaarlijk waren.
Stap 4: Kopiëren of downloaden
Kopieer naar klembord voor plakken in een bestaand manifest, of download als een .yaml bestand. De uitvoer gebruikt alleen spaties - YAML verbiedt tabbladen voor inspringen, wat de moeite waard is om te weten wanneer u het bestand later bewerkt in een editor die is geconfigureerd voor het inspringen van tabbladen.
JSON versus YAML: Wanneer wint elk formaat?
| Json | lijk heb- | |
|---|---|---|
| gelezen/bewerkt door | machines, API's | Mensen, OPS-teams |
| nadere beschouwing | niet in de specificaties | # reacties - de killer-functie voor configuraties |
| Type explicietheid | Totaal - offertes beslissen alles | Scalaire resolutie - context beslist |
| Meerlijns snaren | \n ontsnapt alleen |
blokkades (` |
| Parse snelheid & alomtegenwoordigheid | Snelste, overal | Langzamer, zwaardere parsers |
| gewapende snufjes | trailing komma's, dat is het zo'n beetje | Noorwegen probleem, tabs, inkeping drift, versie truncation |
| natuurlijke habitat | API-payloads, package.json, data-uitwisseling |
Kubernetes, CI-pijpleidingen, componeren, Ansible |
Het patroon achter de tafel: JSON wint waar een machine schrijft en een machine leest; YAML wint waar een machine leest, maar een mensen- schrijft Configuratie zit vierkant in de tweede categorie, daarom is de JSON-naar-YAML-richting de gebruikelijke - data begint het leven in een API of een database-export en moet iets worden dat een ops-team kan onderhouden De omgekeerde trip, YAML terug naar machinaal leesbare JSON, is wat de YAML-validator handvatten - plak YAML, ontvang validatie plus het equivalente JSON.
Wat zijn de dagelijkse workflows voor deze conversie?
Kubernetes manifesteert zich vanuit API-uitvoer
kubectl get deployment my-app -o json geeft je JSON; het manifest dat je in Git checkt is YAML. Het omzetten van API-reacties in schone YAML is de snelste manier om een manifest op te starten vanaf een live bron: converteren en strippen van de server status en metadata.managedFields blokkeert en je hebt een declaratief startpunt. De typeveilige citaat verdient hier zijn houd: ENV-waarden in Kubernetes moest zijn strings, en de aandrang van de converter op het citeren "3000" is het verschil tussen kubectl apply slagen en falen.
CI-pijplijnconfiguratie
GitHub Actions en GitLab CI zijn alleen YAML-Wanneer I & #39; m programmatisch workflowstappen genereert - een matrix van PHP - en Node-versies voor het testen van WP Adminify tegen, zeg maar - de generator produceert natuurlijk JSON, en de laatste stap is conversie Versiereeksen in testmatrices zijn precies de waarden die verminkt raken door naïeve conversie: een matrix van ["1.9", "1.10", "1.11"] Met de hand omgezet zonder offertetests tegen PHP 1.1 tweemaal. de Verzameling van codeerhulpmiddelen Dekt meer van dit patroon voor het dan converteren van de vorming.
Docker componeren van inspecteren van uitvoer
docker inspect zendt JSON uit; docker-compose.yml wil YAML. Reverse-engineering a Compose file from a running container - ports, volumes, env - is een convert-and-prune job Lege arrays en objecten converteren naar [] en {} Flow-syntaxis, die componeert, accepteert en houdt de snoeifase leesbaar.
Configureerbaar maken
Deze wordt onderschat: JSON-configuraties met tientallen geneste sleutels zijn ellendig bij het beoordelen van de code, deels omdat ze geen opmerkingen kunnen dragen. Converteren naar YAML laat u annoteren waarom rateLimit is 250 direct naast de waarde. voor de beoordeling zelf, het koppelen van de conversie met een structureel diff van voor/na Json houdt de "Wat er werkelijk is veranderd" vraag eerlijk terwijl de YAML-versie de "why."
OpenAPI- en schemadocumenten
OpenAPI-specificaties worden gewoonlijk geschreven in YAML, maar gegenereerd en gediend als JSON. Het converteren van een gegenereerde specificatie naar YAML voor menselijke bewerking - en vervolgens het valideren van de retourvlucht - is de standaard API-teamworkflow, en de getrouwheidsgaranties (sleutelvolgorde behouden, typen geciteerd) zorgen ervoor dat de YAML-versie diffabel blijft ten opzichte van zijn JSON-voorouder.
Waarom is het behoud van de sleutel tot orde van belang?
Volgens de JSON-specificatie heeft de objectsleutelvolgorde geen betekenis - {"a":1,"b":2} en {"b":2,"a":1} zijn hetzelfde object. Dus een converter kan sleutels alfabetisch sorteren en technisch correct zijn. Het zou ook praktisch vijandig zijn, omdat configuratiebestanden zijn zich laten lezen In volgorde: een Kubernetes-implementatie leest op natuurlijke wijze als apiVersion, kind, metadata, spec- het alfabetisch sorteren daarvan levert een manifest op dat identiek parseert en leest als een losgeldbriefje.
De converter zendt sleutels uit in bronvolgorde. Uw mentale model van het document overleeft de conversie, de YAML-diffs clean tegen eerdere conversies van dezelfde bron en conventionele bestellingen (Naam voor waarde, apiVersion eerst) conventioneel blijven. als je vereisen canonieke ordening voor vergelijkingsdoeleinden, dat' is een probleem met verschillende hulpmiddelen: de JSON Diff-checker Vergelijkt per sleutel, ongeacht de volgorde, wat de juiste laag is voor dat probleem.
Is het veilig om configuraties met geheimen te converteren?
Configuratie is de meest geheime-dichte tekst die een ontwikkelaar verwerkt - database-URL's met ingebedde wachtwoorden, API-tokens in env-blokken, interne hostnamen die uw infrastructuur in kaart brengen It' s ook precies wat mensen plakken in online converters, meestal halverwege de implementatie, meestal in een haast.
de Toolz.dev-converter draait volledig in uw browser: parseren, scalaire analyse, serialisatie - het is allemaal JavaScript aan de clientzijde, geen enkel netwerkverzoek bevat uw gegevens en de tool blijft werken met het verbreken van uw verbinding. Dat en#39; is een architectuurfeit, geen belofte op het gebied van privacybeleid. De browser-eerste ontwerpfilosofie achter de hele toolbox is uiteengezet in de Handleiding voor webontwikkelaars; Deze tool is dat filosofie die in uw workflow wordt toegepast, op het meest gevoelige documenttype wordt toegepast.
De voor de hand liggende voorbehoud staat: de conversie van de clientzijde beschermt de verandering. Waar u de output daarna plakt, is zijn eigen beveiligingsbeslissing.
FAQ
Hoe converteer ik JSON online naar YAML?
Plak je JSON in de JSON naar YAML-converter, kies 2 - of 4-spatie inspringing, en klik op Converteren U krijgt blokstijl YAML met typeveilige offerte, klaar om te kopiëren of te downloaden als een.yaml bestand De conversie loopt volledig in uw browser - niets wordt geüpload.
Is JSON al geldig YAML?
Technisch gezien is YAML 1.2 een superset van JSON, dus elk geldig JSON-document parseert als YAML. Maar de JSON-syntaxis verslaat het leesbaarheidsdoel van YAML' Converteren produceert YAML in blokstijl met inspringing in plaats van accolades, wat Kubernetes manifesteert, CI-workflows en Compose-bestanden verwachten dat mensen lezen en bewerken.
Wat is het Noorse probleem in YAML?
Onder de scalaire regels van YAML 1.1, die parsers zoals PyYAML nog steeds toepassen, zijn de niet-geciteerde waarden nee, ja, aan en uit het oog als booleans - dus de landcode NEE wordt stilletjes onwaar. De converter voorkomt dit door automatisch elke string te citeren die een YAML-parser zou kunnen interpreteren als een boolean, getal of nul.
Zullen numerieke strings zoals "3000" strings blijven na conversie?
Ja. De converter detecteert strings die eruitzien als getallen en citeert ze in de uitvoer, dus "3000" blijft een tekenreeks in plaats van het gehele getal 3000 te worden. Dit is van belang voor poorten, versienummers zoals "1.10" (die anders zouden afkorten tot de float 1.1), postcodes en ID's met voorloopnullen.
Bewaart de converter de volgorde van mijn JSON-sleutels?
Ja. Sleutels worden uitgezonden in de volgorde waarin ze verschijnen in de bron JSON. Sorteersleutels zouden technisch geldig zijn - JSON-objectvolgorde heeft geen betekenis per RFC 8259- maar de bronvolgorde houdt configuraties leesbaar in hun conventionele structuur en houdt de YAML diffabel ten opzichte van zijn JSON-bron.
Kan ik de uitvoer rechtstreeks gebruiken in Kubernetes of Docker Compose?
Ja. De uitvoer is standaard YAML in blokstijl, ingesprongen met spaties (nooit tabbladen), die kubectl, Docker Compose, GitHub Actions en GitLab CI allemaal accepteren. Waarden die strings moeten zijn - zoals Kubernetes env var-waarden - komen geciteerd naar buiten, waardoor de typefouten worden vermeden die kubectl verhoogt op niet-geciteerde cijfers.
Hoe converteer ik YAML terug naar JSON?
Gebruik de YAML-validator op Toolz.dev - parseert het uw YAML, rapporteert eventuele syntaxisfouten en voert het equivalente JSON uit Samen met de JSON naar YAML Converter geeft het u een volledige retour tussen de twee formaten.
Is het veilig om configuratiebestanden te converteren die geheimen bevatten?
Ja. de conversie draait volledig in JavaScript in uw browser - geen enkel netwerkverzoek draagt uw gegevens, niets wordt opgeslagen of gelogd, en de tool werkt offline Configureert met database-referenties, API-tokens of interne hostnamen verlaat uw machine nooit.
YAML' s leesbaarheid is echt, en dat geldt ook voor de scherpe randen - het formaat lost typen op uit de context, en de context is precies wat handconversie verkeerd doet Een converter die de scalaire regels kent, geeft u de leesbare configuratie zonder de stille typecorruptie: Converteer uw JSON, slik de citaten die het koos, en verzend een manifest waar Noorwegen nog steeds een land is.
