Concise Binary Object Representation
| 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 | |
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]
Motivation und Vergleich mit ähnlichen Technologien
[Bearbeiten | Quelltext bearbeiten]Es 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.