Concise Binary Object Representation - Versionsgeschichte

Xenein: /* growthexperiments-addlink-summary-summary:3|0|0 */

2024-11-12T22:24:32Z

Linkvorschlag-Funktion: 3 Links hinzugefügt.

← Nächstältere Version		Version vom 13. November 2024, 00:24 Uhr
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 ==

RolandIllig: /* Motivation und Vergleich mit ähnlichen Technologien */ typo

2024-09-08T18:39:39Z

Motivation und Vergleich mit ähnlichen Technologien: typo

← Nächstältere Version		Version vom 8. September 2024, 20:39 Uhr
Zeile 17:		Zeile 17:
	== Motivation und Vergleich mit ähnlichen Technologien ==		== Motivation und Vergleich mit ähnlichen Technologien ==
	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 ~~anbieten~~ 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.

Bisam: fehlender Buchstabe

2024-06-04T11:01:35Z

fehlender Buchstabe

← Nächstältere Version		Version vom 4. Juni 2024, 13:01 Uhr
Zeile 23:		Zeile 23:
	# 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.		# 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 alle JSON-Datentypen von und nach JSON umwandeln können.
	# Das Format sollte erweiterbar sein und ~~erweitere~~ Daten müssen rückwärtskompatibel sein, d. h. von älteren Implementierungen gelesen werden können. Das Format ist auf jahrzehntelange Nutzung ausgelegt.		# 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:<ref name="RFC8949" />		In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref name="RFC8949" />

PerfektesChaos: tk k

2023-06-16T07:52:55Z

tk k

← Nächstältere Version		Version vom 16. Juni 2023, 09:52 Uhr
Zeile 8:		Zeile 8:
	\| LetzteVersionDatum =		\| LetzteVersionDatum =
	\| Art = binär		\| Art = binär
	\| Container für = z. B. JSON, CBOR (durch Tagging)		\| Container für = z. B. JSON, CBOR (durch Tagging)
	\| Standard = RFC 8949		\| Standard = <nowiki>RFC 8949</nowiki><ref name="RFC8949" />
	\| Website = https://cbor.io/		\| Website = [https://cbor.io/ cbor.io]
	}}		}}

	Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC 8949 spezifiziert.		Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in <nowiki>RFC 8949</nowiki> spezifiziert.<ref name="RFC8949" />

	== Motivation und Vergleich mit ähnlichen Technologien ==		== Motivation und Vergleich mit ähnlichen Technologien ==
	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="~~rfc~~"~~>{{Internetquelle~~ ~~\|autor=Carsten Bormann, Paul Hoffman \|url=https://www.rfc-editor.org/rfc/rfc8949.html \|titel=Concise Binary Object Representation (CBOR) \|sprache=en \|abruf=2020-12-06}}<~~/~~ref~~>		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 anbieten plus binäre Zeichenketten)		# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten 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.
	# 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.		# 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 alle JSON-Datentypen von und nach JSON umwandeln können.
	# Das Format sollte erweiterbar sein und erweitere Daten müssen rückwärtskompatibel sein, d. h. von älteren Implementierungen gelesen werden können. Das Format ist auf jahrzehntelange Nutzung ausgelegt.		# Das Format sollte erweiterbar sein und erweitere 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:<ref name="~~rfc~~" />

		⚫	In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref name="RFC8949" />
	* [[Abstract Syntax Notation One\|ASN.1]] [[Distinguished Encoding Rules\|DER]], BER, PER		* [[Abstract Syntax Notation One\|ASN.1]] [[Distinguished Encoding Rules\|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.		* [[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.
Zeile 34:		Zeile 32:

	== Einzelnachweise ==		== Einzelnachweise ==
	<references />		<references>
			<ref name="RFC8949">
			{{RFC-Internet \|RFC=8949 \|Titel=Concise Binary Object Representation (CBOR) \|Datum= \|Autor=Carsten Bormann, Paul Hoffman}}
			</ref>
			</references>

	[[Kategorie:Datenformat]]		[[Kategorie:Datenformat]]

Fomafix: HTTPS statt HTTP. ASN.1, DER, MessagePack und UBJSON verlinkt.

2023-03-25T13:38:55Z

HTTPS statt HTTP. ASN.1, DER, MessagePack und UBJSON verlinkt.

← Nächstältere Version		Version vom 25. März 2023, 15:38 Uhr
Zeile 10:		Zeile 10:
	\| Container für = z. B. JSON, CBOR (durch Tagging)		\| Container für = z. B. JSON, CBOR (durch Tagging)
	\| Standard = RFC 8949		\| Standard = RFC 8949
	\| Website = ~~http~~://cbor.io/		\| Website = https://cbor.io/
	}}		}}

	Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC 8949 spezifiziert.		Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC 8949 spezifiziert.

	== Motivation und Vergleich mit ähnlichen Technologien ==		== Motivation und Vergleich mit ähnlichen Technologien ==
	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="rfc">{{Internetquelle \|autor=Carsten Bormann, Paul Hoffman \|url=https://~~tools~~.~~ietf~~.org/~~html~~/rfc8949.html \|titel=Concise Binary Object Representation (CBOR) \|sprache=en \|abruf=2020-12-06}}</ref>		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="rfc">{{Internetquelle \|autor=Carsten Bormann, Paul Hoffman \|url=https://www.rfc-editor.org/rfc/rfc8949.html \|titel=Concise Binary Object Representation (CBOR) \|sprache=en \|abruf=2020-12-06}}</ref>

	# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)		# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)
Zeile 28:		Zeile 28:
	In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref name="rfc" />		In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref name="rfc" />

	* ASN.1 DER, BER, PER		* [[Abstract Syntax Notation One\|ASN.1]] [[Distinguished Encoding Rules\|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.		* [[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 ==

91.46.219.199: /* Motivation und Vergleich mit ähnlichen Technologien */

2022-05-26T11:55:29Z

Motivation und Vergleich mit ähnlichen Technologien

← Nächstältere Version		Version vom 26. Mai 2022, 13:55 Uhr
Zeile 24:		Zeile 24:
	# 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.		# 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 alle JSON-Datentypen von und nach JSON umwandeln können.
	# Das Format sollte erweiterbar sein und erweitere Daten müssen rückwärtskompatibel sein, d. h. von ~~ältere~~ Implementierungen gelesen werden können. Das Format ist auf jahrzehntelange Nutzung ausgelegt.		# Das Format sollte erweiterbar sein und erweitere 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:<ref name="rfc" />		In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref name="rfc" />

DavidL: New RFC 8949 for errata

2020-12-06T13:08:30Z

New RFC 8949 for errata

← Nächstältere Version		Version vom 6. Dezember 2020, 15:08 Uhr
Zeile 9:		Zeile 9:
	\| Art = binär		\| Art = binär
	\| Container für = z. B. JSON, CBOR (durch Tagging)		\| Container für = z. B. JSON, CBOR (durch Tagging)
	\| Standard = RFC ~~7049~~		\| Standard = RFC 8949
	\| Website = http://cbor.io/		\| Website = http://cbor.io/
	}}		}}

	Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC ~~7049~~ spezifiziert.		Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC 8949 spezifiziert.

	== Motivation und Vergleich mit ähnlichen Technologien ==		== Motivation und Vergleich mit ähnlichen Technologien ==
	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="rfc">{{Internetquelle \|autor=Carsten Bormann, Paul Hoffman \|url=https://tools.ietf.org/html/~~rfc7049~~.html \|titel=Concise Binary Object Representation (CBOR) \|sprache=en \|abruf=~~2019~~-02-17}}</ref>		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="rfc">{{Internetquelle \|autor=Carsten Bormann, Paul Hoffman \|url=https://tools.ietf.org/html/rfc8949.html \|titel=Concise Binary Object Representation (CBOR) \|sprache=en \|abruf=2020-12-06}}</ref>

	# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)		# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)

Renamed user 381b7f67a48cfabeb476b696d3a9fe64: keine Linkdopplung

2019-07-19T12:36:20Z

keine Linkdopplung

← Nächstältere Version		Version vom 19. Juli 2019, 14:36 Uhr
Zeile 16:		Zeile 16:

	== Motivation und Vergleich mit ähnlichen Technologien ==		== Motivation und Vergleich mit ähnlichen Technologien ==
	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>{{Internetquelle \|autor=Carsten Bormann, Paul Hoffman \|url=https://tools.ietf.org/html/rfc7049.html \|titel=Concise Binary Object Representation (CBOR) \|~~zugriff~~=2019-02-17 ~~\|sprache=en~~}}</ref>		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="rfc">{{Internetquelle \|autor=Carsten Bormann, Paul Hoffman \|url=https://tools.ietf.org/html/rfc7049.html \|titel=Concise Binary Object Representation (CBOR) \|sprache=en \|abruf=2019-02-17}}</ref>

	# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)		# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)
Zeile 26:		Zeile 26:
	# Das Format sollte erweiterbar sein und erweitere Daten müssen rückwärtskompatibel sein, d. h. von ältere Implementierungen gelesen werden können. Das Format ist auf jahrzehntelange Nutzung ausgelegt.		# Das Format sollte erweiterbar sein und erweitere Daten müssen rückwärtskompatibel sein, d. h. von ältere Implementierungen gelesen werden können. Das Format ist auf jahrzehntelange Nutzung ausgelegt.

	In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref~~>{{Internetquelle~~ ~~\|autor~~=~~Carsten~~ ~~Bormann, Paul Hoffman \|url=https://tools.ietf.org/html/rfc7049.html \|titel=Concise Binary Object Representation (CBOR) \|zugriff=2019-02-17 \|sprache=en}}<~~/~~ref~~>		In der CBOR-Spezifikation wird der Vergleich zu den folgenden Formaten gezogen:<ref name="rfc" />

	* ASN.1 DER, BER, PER		* ASN.1 DER, BER, PER

Hellpaso: Grammatik (die Arbeitsgruppe)

2019-03-05T13:49:27Z

Grammatik (die Arbeitsgruppe)

← Nächstältere Version		Version vom 5. März 2019, 15:49 Uhr
Zeile 13:		Zeile 13:
	}}		}}

	Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 ~~das~~ [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC 7049 spezifiziert.		Die '''Concise Binary Object Representation''' ('''CBOR''') ist ein binäres kompaktes [[Datenformat]] zur [[Serialisierung]]. Es orientiert sich an [[JavaScript Object Notation\|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 [[Internet Engineering Task Force\|IETF]] als [[Internetstandard]] in RFC 7049 spezifiziert.

	== Motivation und Vergleich mit ähnlichen Technologien ==		== Motivation und Vergleich mit ähnlichen Technologien ==

Aka: Tippfehler entfernt

2019-02-17T22:20:12Z

Tippfehler entfernt

← Nächstältere Version		Version vom 18. Februar 2019, 00:20 Uhr
Zeile 3:		Zeile 3:
	\| MIME = application/cbor		\| MIME = application/cbor
	\| Entwickler = Carsten Bormann		\| Entwickler = Carsten Bormann
	Technologie-Zentrum Informatik und Informationstechnik, Universität ~~Bremem~~		Technologie-Zentrum Informatik und Informationstechnik, Universität Bremen
	\| Veröffentlicht = 2013		\| Veröffentlicht = 2013
	\| LetzteVersion =		\| LetzteVersion =
Zeile 20:		Zeile 20:
	# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten plus binäre Zeichenketten)		# eindeutige Kodierung der geläufigsten Internet-Standards (vorrangig alle Möglichkeiten, die JSON anbieten 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.
	# 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.		# 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.