{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/json","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/json/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/json/"},"term":{"en":"JSON","da":"JSON"},"aka":{"en":["JavaScript Object Notation"],"da":["JavaScript Object Notation"]},"domain":["cs"],"cluster":"web","layer":"application","status":"current","era":2001,"summary":{"en":"A simple text format for writing down data as named values and lists, easy for both people and programs to read.","da":"Et enkelt tekstformat til at skrive data ned som navngivne værdier og lister, let at læse for både mennesker og programmer."},"body":{"formal":{"en":"A text format built from just a few pieces - objects of name and value pairs in curly brackets, lists in square brackets, and values that are text, numbers, true, false or null - that can be nested inside each other.","da":"Et tekstformat bygget af ganske få dele - objekter med par af navn og værdi i { }, lister i [ ] og værdier, der er tekst, tal, true, false eller null - som kan lægges inden i hinanden."},"plain":{"en":"Like a neatly filled-in form where every box has a label, so anyone picking it up knows which answer belongs to which question.","da":"Som en pænt udfyldt blanket, hvor hvert felt har en overskrift, så enhver, der samler den op, ved, hvilket svar der hører til hvilket spørgsmål."},"inPractice":{"en":"A developer at a region looks into a fault in a patient app and sees that the server's JSON reply for a booking has the field for the appointment time left empty, so the app shows no time.","da":"En udvikler i en region undersøger en fejl i en patientapp og ser, at serverens JSON-svar for en booking har feltet med aftaletidspunktet tomt, så appen ikke viser noget tidspunkt."},"whyItMatters":{"en":"Because almost every language can read and write it, it has become the common way programs swap data over the web; reading untrusted JSON carelessly is also a known source of flaws.","da":"Fordi næsten alle sprog kan læse og skrive det, er det blevet den almindelige måde, programmer udveksler data på over nettet; at læse JSON fra ukendte kilder uden omtanke er også en kendt kilde til fejl."}},"deepDive":{"en":"JSON was popularised by Douglas Crockford from around 2001 as a subset of JavaScript literal syntax. It was first described in RFC 4627 (2006), and today two aligned specifications define it: RFC 8259 (December 2017, Internet Standard STD 90) and ECMA-404 (2nd edition, 2017). The grammar is tiny: objects, arrays, strings, numbers and the literals true, false and null. Insignificant whitespace is limited to space, tab, line feed and carriage return; there are no comments, no trailing commas, no single-quoted strings and no NaN or Infinity. Control characters U+0000 to U+001F must be escaped in strings, and characters outside the Basic Multilingual Plane are written as \\u escape surrogate pairs. The media type is application/json.\n\nThe interoperability gaps are deliberate and matter in practice. RFC 8259 §4 says member names SHOULD be unique but leaves duplicates undefined: JavaScript's JSON.parse keeps the last value, other parsers keep the first or reject the document. When a security filter and a back-end use different parsers, a duplicated key can mean one thing to the check and another to the consumer. Numbers have no precision limit in the grammar, but §6 notes that IEEE 754 binary64 is widely implemented, so integers outside the range -(2^53)+1 to (2^53)-1 lose precision in JavaScript; this is why APIs often ship large identifiers as strings. §8.1 requires UTF-8 for JSON exchanged between systems that are not part of a closed ecosystem. The I-JSON profile (RFC 7493) closes these gaps by forbidding duplicate names and constraining numbers and encoding.\n\nSecurity issues come mostly from what happens after parsing. Early code evaluated JSON with eval(), which executed any embedded script. In JavaScript, merging parsed objects that contain a \"__proto__\" key can cause prototype pollution. Libraries that instantiate types named in the input, such as polymorphic typing in Jackson or TypeNameHandling in Json.NET, have produced remote-code-execution bugs classed as insecure deserialization (CWE-502). Deeply nested or huge input can exhaust stack or memory, so parsers need depth and size limits. For signatures, JOSE (JWS, RFC 7515; JWT, RFC 7519) signs the base64url-encoded bytes to avoid canonicalisation, while the JSON Canonicalization Scheme (RFC 8785) defines a canonical form where one is needed.\n\nAround the core sits an ecosystem: JSON Schema (draft 2020-12, also used by OpenAPI 3.1) for validation, JSON Pointer (RFC 6901), JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) for partial updates, and newline-delimited JSON for streaming. Compared with XML, JSON has no attributes, namespaces or entity expansion, so XXE-style attacks do not apply; YAML 1.2 is designed as a superset of JSON; and Protocol Buffers trade readability for a compact binary encoding with a mandatory schema.","da":"JSON blev udbredt af Douglas Crockford fra omkring 2001 som en delmængde af JavaScripts syntaks for literaler. Formatet blev først beskrevet i RFC 4627 (2006), og i dag definerer to afstemte specifikationer det: RFC 8259 (december 2017, internetstandard STD 90) og ECMA-404 (2. udgave, 2017). Grammatikken er lille: objekter, arrays, strenge, tal og literalerne true, false og null. Betydningsløst whitespace er begrænset til mellemrum, tabulator, linjeskift og vognretur; der er ingen kommentarer, ingen afsluttende kommaer, ingen strenge i enkelte anførselstegn og ingen NaN eller Infinity. Kontroltegn fra U+0000 til U+001F skal escapes i strenge, og tegn uden for Basic Multilingual Plane skrives som \\u-escapede surrogatpar. Medietypen er application/json.\n\nHullerne i interoperabiliteten er bevidste og har betydning i praksis. RFC 8259 afsnit 4 siger, at navne i et objekt SHOULD være unikke, men lader dubletter være udefinerede: JavaScripts JSON.parse beholder den sidste værdi, andre parsere den første, eller de afviser dokumentet. Når et sikkerhedsfilter og en back-end bruger forskellige parsere, kan en dubleret nøgle betyde én ting for kontrollen og noget andet for modtageren. Tal har ingen præcisionsgrænse i grammatikken, men afsnit 6 bemærker, at IEEE 754 binary64 er udbredt, så heltal uden for intervallet -(2^53)+1 til (2^53)-1 mister præcision i JavaScript; derfor sender API'er ofte store id'er som strenge. Afsnit 8.1 kræver UTF-8 for JSON, der udveksles mellem systemer uden for et lukket økosystem. I-JSON-profilen (RFC 7493) lukker hullerne ved at forbyde dubletnavne og begrænse tal og tegnkodning.\n\nSikkerhedsproblemer opstår mest efter parsingen. Tidlig kode evaluerede JSON med eval(), som udførte ethvert indlejret script. I JavaScript kan sammenfletning af parsede objekter med en \"__proto__\"-nøgle føre til prototype pollution. Biblioteker, der instantierer typer navngivet i input, som polymorf typning i Jackson eller TypeNameHandling i Json.NET, har givet fejl med fjernkørsel af kode, klassificeret som usikker deserialisering (CWE-502). Dybt indlejret eller enormt input kan opbruge stak eller hukommelse, så parsere har brug for grænser for dybde og størrelse. Til signaturer signerer JOSE (JWS, RFC 7515; JWT, RFC 7519) de base64url-kodede bytes for at undgå kanonisering, mens JSON Canonicalization Scheme (RFC 8785) definerer en kanonisk form, hvor der er brug for en.\n\nOmkring kernen findes et økosystem: JSON Schema (draft 2020-12, også brugt af OpenAPI 3.1) til validering, JSON Pointer (RFC 6901), JSON Patch (RFC 6902) og JSON Merge Patch (RFC 7396) til delvise opdateringer samt linjeopdelt JSON til streaming. Sammenlignet med XML har JSON ingen attributter, navnerum eller entitetsudvidelse, så XXE-lignende angreb er irrelevante; YAML 1.2 er designet som en overmængde af JSON; og Protocol Buffers bytter læsbarhed for en kompakt binær kodning med obligatorisk skema."},"edges":[{"type":"used-with","to":"cs/rest-api","why":{"en":"Most REST APIs send and receive their data as JSON.","da":"De fleste REST API'er sender og modtager deres data som JSON."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"cs/web-application","confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/structured-output","why":{"en":"JSON is the usual shape a structured-output reply is forced into.","da":"JSON er den sædvanlige form, et struktureret output tvinges ind i."},"confidence":"medium","strength":"normal"},{"type":"used-with","to":"ai/model-context-protocol","why":{"en":"MCP messages are written as JSON, so any app or server can read the other side's requests and answers with ordinary tools.","da":"MCP-beskeder skrives som JSON, så enhver app eller server kan læse den anden sides anmodninger og svar med almindelige værktøjer."},"confidence":"medium","strength":"normal"}],"depth":0,"sources":[{"title":"RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format","url":"https://www.rfc-editor.org/rfc/rfc8259","tier":"standard","publisher":"IETF"},{"title":"ECMA-404 - The JSON Data Interchange Syntax","url":"https://ecma-international.org/publications-and-standards/standards/ecma-404/","tier":"standard","publisher":"Ecma International"}],"draft":true}