„Concise Binary Object Representation“ – Versionsunterschied
| [gesichtete Version] | [gesichtete Version] |
Inhalt gelöscht Inhalt hinzugefügt
Xenein (Diskussion | Beiträge) Linkvorschlag-Funktion: 3 Links hinzugefügt. |
|||
| Zeile 18: | Zeile 18: | ||
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:<ref name="RFC8949" /> |
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:<ref name="RFC8949" /> |
||
# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON bietet plus binäre Zeichenketten) |
# 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 |
# 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. |
# 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. |
# 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. |
||
| Zeile 29: | Zeile 29: | ||
* [[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. |
* [[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. |
* [[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. |
* [[UBJSON]] – Setzt nur exakt das JSON-Datenmodell um. Serialisierung eher auf [[Menschenlesbarkeit]] als auf Kompaktheit ausgerichtet. |
||
== Einzelnachweise == |
== Einzelnachweise == |
||
Aktuelle Version vom 13. November 2024, 00:24 Uhr
| 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.