Skip to content

Alt om WordPress, webutvikling — og mer til

JSON: formatering, validering og reparasjon av ødelagt

JSON: formatering, validering og reparasjon av ødelagt

Lim inn et API-svar, en konfigurasjon eller et loggutdrag — du får en lesbar visning, et tre og en liste over alt som ikke følger standarden, med nøyaktig linje og posisjon. Alt tolkes i nettleseren din: dataene sendes ingen steder og lagres ingen steder.

Slipp en .json her — filen leses lokalt. Du kan også lime inn noe som ennå ikke er gyldig JSON: en logg, et API-svar med kommentarer, et utdrag med avsluttende komma.
Behandling

Nøkler og rekkefølge er bevart, tallenes skrivemåte er uendret.

Lim inn JSON over og trykk «Behandle».

Dataene forlater ikke nettleseren din — tolking og formatering skjer lokalt, uten at noe sendes til en server.

Fire utgaver av standarden og hvordan de skiller seg

JSON beskrives av flere dokumenter, og de er ikke identiske. Valget av spesifikasjon endrer hva verktøyet regner som en feil. RFC 4627 (2006) — den opprinnelige. Et dokument på øverste nivå kan bare være et objekt eller et array; et enkeltstående tall eller en streng er ikke tillatt. Nettopp denne utgaven støtter enkelte gamle biblioteker seg fortsatt på. RFC 7159 (2014) — tillot enhver verdi på øverste nivå. Siden da er 42 og «tekst» selvstendige JSON-dokumenter. RFC 8259 (2017) — den gjeldende. Den la til kravet om UTF-8 for utveksling mellom systemer og slo fast at navn i ett og samme objekt må være unike. ECMA-404 — beskriver bare syntaksen. Den forbyr ikke dupliserte nøkler og nevner ikke enslige surrogater, så settet med advarsler er kortest her. Er du i tvil, behold RFC 8259: det er det strengeste av de gjeldende regelverkene, og det som består det, blir godtatt overalt.

Hvorfor egen tolking og ikke nettleserens JSON.parse

Den innebygde tolkeren er laget for fart, ikke for diagnostikk. På samme data tier den der et verktøy burde snakke: En melding uten koordinater. Nettleseren sier «Unexpected token» og en forskyvning i tegn; her får du linjen, posisjonen og hva som nøyaktig ble forventet. Én feil for hele dokumentet. Etter den første svikten tar tolkingen seg inn igjen og viser resten i stedet for å tvinge deg til å rette én om gangen. Dupliserte nøkler passerer i stillhet. JSON.parse beholder den siste verdien, og tapet oppdages først i produksjon. Tallenes skrivemåte går tapt. 1.0 blir 1, og et heltall over ni billiarder endrer de siste sifrene — nettopp slik ryker identifikatorer fra databasen. Rekkefølgen på nøklene i utdataen beholdes som i kilden helt til du selv ber om sortering. Tall skrives her som standard nøyaktig slik de ble skrevet: verktøyet viser dokumentet, ikke resultatet av å tolke det.

Hva rettemodusen faktisk reparerer

Virkelige data er sjelden ren JSON. Reparasjonsmodusen bringer det som kommer fra konfigurasjoner, logger og andres API-er i tråd med standarden: kommentarer // og /* */ fjernes; komma foran en avsluttende parentes tas bort; enkle og typografiske anførselstegn normaliseres til doble; nøkler uten anførselstegn og numeriske nøkler settes i anførselstegn; True, NULL, None, undefined blir true, false, null; NaN og Infinity blir null, siden JSON ikke har tall uten endelig verdi; tallenes skrivemåte — overflødig pluss, punktum i kanten, innledende nuller; kontrolltegn i strenger escapes; BOM i starten av filen og JSONP-innpakningen fjernes. Ingen rettelse skjer i stillhet: hver enkelt havner i listen med antall tilfeller. Passer ikke resultatet, slår du av avkrysningsboksen, og dokumentet kontrolleres som det er.

Vanlige spørsmål