Dataformat: JSON och XML

Ett protokoll flyttar byte. Ett dataformat, även kallat dataprotokoll, bestämmer vad de byten säger, så att maskinen i andra änden kan plocka isär dem igen och hitta temperaturen.

Två format används allmänt: JSON och XML. Om du är ny inom IoT och aldrig har behövt läsa något av dem är det här sidan att läsa noga, eftersom nästan varje payload, API-svar och konfigurationsfil du möter härifrån och framåt kommer att vara det ena eller det andra.

JSON

JSON, JavaScript Object Notation, är ett lättviktigt textformat för strukturerad data. Det är text, så du kan läsa det, och det är strikt, så en maskin kan tolka det utan tvetydighet. Det är det vanliga valet för modernt IoT-arbete.

Här är en komplett IoT-payload:

{
  "deviceId": "sensor-042",
  "timestamp": "2026-08-14T09:15:00Z",
  "temperature": 25.5,
  "humidity": 41,
  "batteryOk": true,
  "errorMessage": null,
  "location": {
    "building": "Stadsbiblioteket",
    "floor": 2
  },
  "recentReadings": [25.1, 25.3, 25.5]
}

Allt i JSON är byggt av två behållare och fyra enkla värden.

De två behållarna

Ett objekt är en oordnad samling av namn- och värdepar, omslutet av klammerparenteser. Namnet är alltid en sträng inom dubbla citattecken, följt av kolon och sedan värdet. Paren separeras med kommatecken.

{"temperature": 25.5, "humidity": 41}

En array är en ordnad lista av värden, omsluten av hakparenteser och separerad med kommatecken. Värdena behöver inte vara av samma typ, även om de i praktiken oftast är det.

[25.1, 25.3, 25.5]

Datatyperna

Typ	Skrivs som	Exempel	Noteringar
Sträng	Dubbla citattecken	"Stadsbiblioteket"	Alltid dubbla, aldrig enkla
Nummer	Enbart siffror	25.5, 41, -3, 1.2e6	Inga citattecken, ingen enhet, ingen skillnad mellan heltal och decimaltal
Boolean	true eller false	true	Gemener, inga citattecken
Null	null	null	Betyder "inget värde", vilket inte är samma sak som 0 eller ""
Objekt	{ }	{"floor": 2}	Kan innehålla vad som helst av detta, inklusive fler objekt
Array	[ ]	[1, 2, 3]	Kan innehålla vad som helst av detta, inklusive fler arrayer

Det är hela typsystemet. Det finns medvetet inget mer, och konsekvenserna av det är värda att förstå.

Observera också att decimaltal i JSON alltid skrivs med punkt, inte komma. 25.5 är ett tal; 25,5 är inte giltig JSON.

Nästling

Objekt och arrayer innehåller varandra, vilket är hur JSON uttrycker struktur på godtyckligt djup. I payloaden ovan är location ett objekt inuti huvudobjektet, så floor ligger en nivå ned. Du refererar till ett värde med dess sökväg uppifrån:

temperature          → 25.5
location.building    → "Stadsbiblioteket"
recentReadings[0]    → 25.1

Den punktnotationen är hur de flesta verktyg, inklusive translatorer och regelvillkor, adresserar ett fält. Att arrayer räknas från noll är en vanlig källa till fel på ett steg.

En array av objekt är det vanliga sättet att skicka flera mätvärden på en gång:

{
  "deviceId": "sensor-042",
  "readings": [
    {"time": "2026-08-14T09:00:00Z", "temperature": 25.1},
    {"time": "2026-08-14T09:05:00Z", "temperature": 25.3},
    {"time": "2026-08-14T09:10:00Z", "temperature": 25.5}
  ]
}

Reglerna som ställer till det

JSON är strikt, och felmeddelandena är ofta till liten hjälp. De vanliga misstagen:

• Nycklar måste stå inom dubbla citattecken. {temperature: 25.5} är inte JSON, även om det ser ut som att det borde vara det.
• Enkla citattecken är aldrig giltiga. {'a': 1} är inte JSON.
• Inget avslutande kommatecken. {"a": 1, "b": 2,} är ogiltigt, och det här är det absolut vanligaste felet.
• Inga kommentarer. Det finns inget sätt att kommentera JSON, vilket är varför konfigurationsfiler som behöver kommentarer ofta använder något annat.
• true, false och null skrivs med gemener och utan citattecken. "true" är en sträng, och en regel som testar mot en boolean matchar den inte.
• Nummer bär ingen enhet och ingen garanti om precision. 25.5 kan vara Celsius, Fahrenheit eller något helt annat; bara fältnamnet eller en datamodell säger vilket.
• Det finns ingen datumtyp. Tidsstämplar är strängar och bör använda ISO 8601 i UTC, som "2026-08-14T09:15:00Z", vilket sorterar rätt som text och tar bort varje fråga om tidszon.
• Specialtecken inuti strängar escapas med bakstreck: \" för citattecken, \\ för bakstreck, \n för radbrytning.

Varför det passar IoT

JSON är kompakt nog för resursbegränsade länkar, kräver inget schema för att gå att läsa, och varje språk och verktyg tolkar det direkt. En människa kan öppna en payload och förstå den, vilket betyder mer under driftsättning än någon teoretisk elegans.

Begränsningarna är baksidan av samma enkelhet. Ingenting i JSON säger vad ett fält betyder, vilken enhet det är i, eller vilka fält som krävs. Det är precis den luckan som datamodeller fyller.

XML

XML, eXtensible Markup Language, är det äldre av de två och beskriver data med nästlade taggar. Det är mer utförligt än JSON, och därmed också mer explicit.

Samma payload i XML:

<?xml version="1.0" encoding="UTF-8"?>
<measurement deviceId="sensor-042">
  <timestamp>2026-08-14T09:15:00Z</timestamp>
  <temperature unit="C">25.5</temperature>
  <humidity unit="%">41</humidity>
  <batteryOk>true</batteryOk>
  <location>
    <building>Stadsbiblioteket</building>
    <floor>2</floor>
  </location>
  <recentReadings>
    <reading>25.1</reading>
    <reading>25.3</reading>
    <reading>25.5</reading>
  </recentReadings>
</measurement>

Delarna

• Deklarationen, första raden, anger XML-version och teckenkodning.
• Ett element är en starttagg, innehåll och en matchande sluttagg: <floor>2</floor>. Varje element måste stängas, och ett tomt får stänga sig självt som <floor/>.
• Element nästlas, och det måste finnas exakt ett rotelement som innehåller alla andra. Här är det measurement.
• Ett attribut är ett namn och ett värde på starttaggen: unit="C". Attributvärden är alltid citerade.
• Kommentarer skrivs <!-- så här -->, vilket XML tillåter och JSON inte gör.

Element eller attribut

XML låter samma information uttryckas på båda sätten, vilket är dess vanligaste designdiskussion:

<temperature unit="C">25.5</temperature>
<temperature><value>25.5</value><unit>C</unit></temperature>

Konventionen de flesta landar i är att attribut bär metadata om elementet, som en enhet eller en identifierare, medan element bär själva datan. Attribut kan inte nästlas eller upprepas, vilket avgör saken så snart värdet har egen struktur.

Namnrymder och scheman

Två funktioner förklarar varför XML lever kvar i stora system.

En namnrymd låter dokument från olika vokabulär kombineras utan att namnen krockar, genom att binda ett prefix till en URI:

<rec:Building xmlns:rec="https://w3id.org/rec/">
  <rec:name>Stadsbiblioteket</rec:name>
</rec:Building>

Ett schema, oftast XSD, är ett separat dokument som formellt definierar vilka element som får förekomma, i vilken ordning, hur många gånger och av vilken typ. En parser kan sedan validera ett dokument mot det och avvisa allt som inte följer det, innan någon applikationskod körs. Den garantin är varför XML är fortsatt vanligt där korrekthet är avtalsbunden.

Var du möter det i IoT

XML förekommer i integrationer mot verksamhetssystem, i SOAP-webbtjänster, i ett antal fastighets- och industrisystem, och i utbytesformat som de i Open BIM-familjen. Varje plattform som ska integrera mot ett befintligt bestånd behöver kunna läsa det.

De två sida vid sida

	JSON	XML
Struktur	Objekt och arrayer	Nästlade element
Metadata	Fält i objektet	Attribut eller underelement
Kommentarer	Stöds inte	Stöds
Schemavalidering	Valfritt, via JSON Schema	Moget och brett använt, via XSD
Namnrymder	Inte inbyggt	Inbyggt
Storlek på tråden	Mer kompakt	Mer utförligt
Typisk användning i IoT	Enheters payloads, REST-API:er, MQTT	Verksamhets-, fastighets- och industriintegrationer

Båda uttrycker samma information. JSON är det vanliga valet för nytt IoT-arbete, och XML är det som en stor mängd befintlig infrastruktur redan talar, så en horisontell plattform hanterar båda och konverterar mellan dem där det behövs.

Vad inget av dem berättar

Titta på JSON-payloaden högst upp på sidan igen. Den säger "temperature": 25.5. Den säger inte vilken enhet det är, vilken precision att förvänta sig, om fältet är obligatoriskt, vilken fysisk sak som mättes, eller vilket rum den tillhör.

Format bär struktur. Innebörden kommer från lagret ovanför, vilket är där datamodeller kommer in.