Die Concise Binary Object Representation (CBOR) ist ein binäres kompaktes Datenformat zur Serialisierung. Es orientiert sich an JSON und dient wie dieses dem Datenaustausch zwischen Anwendungen. Es soll höhere Prozessierungs- und Übertragungsgeschwindigkeit ermöglichen, opfert dafür jedoch die Klartextlesbarkeit. CBOR ist durch die IETF als Internetstandard in RFC 8949 spezifiziert.[1]
| Concise Binary Object Representation | |
|---|---|
| Dateiendung: | .cbor
|
| MIME-Type: | application/cbor
|
| Entwickelt von: | Carsten Bormann
Technologie-Zentrum Informatik und Informationstechnik, Universität Bremen |
| Erstveröffentlichung: | 2013 |
| Art: | binär |
| Container für: | z. B. JSON, CBOR (durch Tagging) |
| Standard(s): | RFC 8949[1] |
| cbor.io | |
Motivation und Vergleich mit ähnlichen Technologien
BearbeitenEs gibt eine Vielzahl von zu CBOR ähnlichen Formaten zur binären Darstellung strukturierter Daten. Nach Ansicht der Autoren folgt jedoch keines den speziellen Entwicklungszielen, die CBOR zu Grunde liegen:[1]
- eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON bietet plus binäre Zeichenketten)
- kompakter Code für Kodierer sowie Dekodierer, so dass Systeme mit eingeschränkter Leistungsfähigkeit in Bezug auf Prozessorleistung, Speicher und Befehlssatz als Zielsysteme dienen können
- Daten sollten ohne Notwendigkeit eines Schemas dekodiert werden können, d. h. die kodierten Daten sollten selbst-beschreibend sein.
- Die Serialisierung sollte „halbwegs“ kompakt sein. Wobei eine äquivalente JSON-Kodierung als obere Grenze angesehen wird. Der Wunsch nach Kompaktheit ist jedoch dem nach Einfachheit des (De-)Kodierers nachrangig.
- Anwendbarkeit in „beschränkten“ als auch in „High-Volume“-Umgebungen, d. h. in Bezug auf Prozessorleistung sollten Implementierungen genügsam sein, so dass sie einerseits auf kleinsten Hardwareeinheiten eingesetzt werden können, gleichzeitig aber auch hohen Durchsatz auf High-End-Systemen bieten können.
- Das Format sollte alle JSON-Datentypen von und nach JSON umwandeln können.
- Das Format sollte erweiterbar sein und erweiterte Daten müssen rückwärtskompatibel sein, d. h. von älteren Implementierungen gelesen werden können. Das Format ist auf jahrzehntelange Nutzung ausgelegt.
In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:[1]
- ASN.1 DER, BER, PER
- MessagePack – hat ähnliche Eigenschaften und ist relativ weit verbreitet. Wird neben JSON-ähnlicher Serialisierung auch noch für Langzeitdatenarchivierung verwendet. Ist nur schlecht erweiterbar und die Weiterentwicklung wird durch den Wunsch nach Rückwärtskompatibilität mit existierenden Daten behindert.
- BSON – „binäres JSON“, eingeführt von der NoSQL-Datenbank MongoDB. Ist weniger kompakt und deutlich auf den Einsatz in der Datenbank hin optimiert. Erweiterbarkeit unklar.
- UBJSON – Setzt nur exakt das JSON-Datenmodell um. Serialisierung eher auf Menschenlesbarkeit als auf Kompaktheit ausgerichtet.