Oficina Central de Correos

Este artículo se basa excesivamente en referencias a fuentes primarias . Por favor, mejore este artículo añadiendo fuentes secundarias o terciarias . Buscar fuentes:  «CBOR» – noticias  · periódicos  · libros  · académico  · JSTOR ( abril de 2020 ) ( Aprenda cómo y cuándo eliminar este mensaje )

La representación binaria concisa de objetos ( CBOR ) es un formato de serialización de datos binarios basado libremente en JSON creado por Carsten Bormann y Paul Hoffman. ^[a] Al igual que JSON, permite la transmisión de objetos de datos que contienen pares nombre-valor , pero de una manera más concisa. Esto aumenta las velocidades de procesamiento y transferencia a costa de la legibilidad humana . Está definido en IETF RFC  8949. ^[2]

Entre otros usos, es la capa de serialización de datos recomendada para el conjunto de protocolos CoAP de Internet de las cosas ^{[3] [ verificación fallida ]} y el formato de datos en el que se basan los mensajes COSE. También se utiliza en el Protocolo de cliente a autenticador (CTAP) en el ámbito del proyecto FIDO2. ^[4]

CBOR se inspiró en MessagePack , que fue desarrollado y promovido por Sadayuki Furuhashi. CBOR extendió MessagePack, particularmente al permitir distinguir cadenas de texto de cadenas de bytes, lo que se implementó en 2013 en MessagePack. ^{[5] [6]}

Los datos codificados con CBOR se consideran una secuencia de elementos de datos. Cada elemento de datos consta de un byte de encabezado que contiene un tipo de 3 bits y un recuento corto de 5 bits. A esto le sigue un recuento extendido opcional (si el recuento corto está en el rango 24-27) y una carga útil opcional.

Para los tipos 0, 1 y 7, no hay carga útil; el recuento es el valor. Para los tipos 2 (cadena de bytes) y 3 (cadena de texto), el recuento es la longitud de la carga útil. Para los tipos 4 (matriz) y 5 (mapa), el recuento es la cantidad de elementos (pares) en la carga útil. Para el tipo 6 (etiqueta), la carga útil es un solo elemento y el recuento es un número de etiqueta numérica que describe el elemento incluido.

El comportamiento de cada elemento de datos se define mediante el tipo principal y el recuento. El tipo principal se utiliza para seleccionar el comportamiento o tipo principal de cada elemento de datos.

El campo de conteo corto de 5 bits codifica los conteos 0 a 23 directamente. Los conteos cortos de 24 a 27 indican que el valor del conteo se encuentra en un campo de conteo extendido de 8, 16, 32 o 64 bits siguiente. Los valores 28 a 30 no se asignan y no se deben utilizar.

Los tipos se dividen en tipos "atómicos" 0-1 y 6-7, para los cuales el campo de conteo codifica el valor directamente, y tipos no atómicos 2-5, para los cuales el campo de conteo codifica el tamaño del siguiente campo de carga útil.

Se utiliza un conteo corto de 31 con los tipos no atómicos 2 a 5 para indicar una longitud indefinida; la carga útil son los siguientes elementos hasta un byte marcador de "ruptura" de 255 (tipo = 7, conteo corto = 31). No se permite un conteo corto de 31 con los otros tipos atómicos 0, 1 o 6.

El tipo 6 (etiqueta) es inusual porque su campo de conteo codifica un valor directamente, pero también tiene un campo de carga útil (que siempre consta de un solo elemento).

Los recuentos extendidos y todos los valores multibyte se codifican en orden de bytes de red (big-endian) .

En el caso de los números enteros, el campo de recuento es el valor; no hay ninguna carga útil. El tipo 0 codifica números enteros positivos o sin signo, con valores de hasta 2 ⁶⁴ −1. El tipo 1 codifica números enteros negativos, con un valor de −1−count, para valores de −2 ⁶⁴ a −1.

Los tipos 2 y 3 tienen un campo de conteo que codifica la longitud en bytes de la carga útil. El tipo 2 es una cadena de bytes no estructurada. El tipo 3 es una cadena de texto UTF-8 .

Un recuento corto de 31 indica una cadena de longitud indefinida. A esto le siguen cero o más cadenas de longitud definida del mismo tipo, terminadas por un byte marcador de "ruptura". El valor del elemento es la concatenación de los valores de los elementos incluidos. No se permiten elementos de un tipo diferente ni cadenas de longitud indefinida anidadas. Las cadenas de texto deben estar bien formadas individualmente; los caracteres UTF-8 no pueden dividirse entre elementos.

El tipo 4 tiene un campo de conteo que codifica la cantidad de elementos siguientes, seguido de esa misma cantidad de elementos. No es necesario que todos los elementos sean del mismo tipo; algunos lenguajes de programación lo denominan "tupla" en lugar de "matriz".

Como alternativa, se puede utilizar una codificación de longitud indefinida con un recuento corto de 31. Esto continúa hasta un byte marcador de "ruptura" de 255. Debido a que los elementos anidados también pueden utilizar la codificación indefinida, el analizador debe emparejar los marcadores de ruptura con los bytes de encabezado de longitud indefinida correspondientes.

El tipo 5 es similar, pero codifica un mapa (también llamado diccionario o matriz asociativa) de pares clave/valor. En este caso, el conteo codifica la cantidad de pares de elementos. Si se utiliza la codificación de longitud indefinida, debe haber una cantidad par de elementos antes del byte marcador de "ruptura".

Una etiqueta semántica es otro tipo atómico para el cual el recuento es el valor, pero también tiene una carga útil (un único elemento siguiente) y los dos se consideran un elemento en, por ejemplo, una matriz o un mapa.

El número de etiqueta proporciona información de tipo adicional para el siguiente elemento, más allá de lo que puede proporcionar el tipo principal de 3 bits. Por ejemplo, una etiqueta de 1 indica que el siguiente número es un valor de tiempo Unix . Una etiqueta de 2 indica que la siguiente cadena de bytes codifica un bignum sin signo . Una etiqueta de 32 indica que la siguiente cadena de texto es un URI según se define en RFC  3986. RFC  8746 define las etiquetas 64 a 87 para codificar matrices homogéneas de valores enteros o de punto flotante de tamaño fijo como cadenas de bytes.

La etiqueta 55799 se asigna para indicar "los datos CBOR siguen". Esto no es una operación semántica , pero permite que los bytes de la etiqueta correspondiente d9 d9 f7se antepongan a un archivo CBOR sin afectar su significado. Estos bytes se pueden usar como un " número mágico " para distinguir el comienzo de los datos CBOR.

Los valores de etiqueta de todos unos 0xffff, 0xffffffff y 0xffffffffffffffffff están reservados para indicar la ausencia de una etiqueta en una biblioteca de decodificación CBOR; nunca deben aparecer en un flujo de datos.

El pseudoelemento marcador de ruptura no puede ser la carga útil de una etiqueta.

Este tipo principal se utiliza para codificar diversos valores especiales que no encajan en las otras categorías. Sigue las mismas reglas de tamaño de codificación que los otros tipos atómicos (0, 1 y 6), pero el campo de conteo se interpreta de forma diferente.

Los valores 20 a 23 se utilizan para codificar los valores especiales false, true, null y undefined . Los valores 0 a 19 no están definidos actualmente.

Un conteo corto de 24 indica que sigue un conteo extendido de 1 byte que se puede utilizar en el futuro para codificar valores especiales adicionales. Para simplificar la decodificación, los valores 0 a 31 no se pueden codificar de esta forma. Ninguno de los valores 32 a 255 está definido actualmente.

Los conteos cortos de 25, 26 o 27 indican que el siguiente campo de conteo extendido debe interpretarse como un valor de punto flotante IEEE de 16, 32 o 64 bits (big-endian) . Estos son los mismos tamaños que un conteo extendido, pero se interpretan de manera diferente. En particular, para todos los demás tipos principales, un conteo extendido de 2 bytes de 0x1234 y un conteo extendido de 4 bytes de 0x00001234 son exactamente equivalentes. Este no es el caso de los valores de punto flotante.

Los números cortos 28-30 están reservados, como todos los demás tipos principales.

Un conteo corto de 31 codifica el marcador especial de "ruptura" que finaliza una codificación de longitud indefinida. Esto está relacionado con el uso con otros tipos principales, pero es diferente, donde un conteo corto de 31 inicia una codificación de longitud indefinida. Esto no es un elemento y puede no aparecer en una carga útil de longitud definida.

La IANA ha creado el registro de etiquetas CBOR, que se encuentra en https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml. Los registros deben contener la plantilla que se describe a continuación. ^[7]

• Comparación de formatos de serialización de datos binarios

• Herramienta en línea para convertir de binario CBOR a representación textual y viceversa.
• Zona CBOR: Herramienta en línea para convertir un elemento CBOR o una secuencia CBOR en formato HEX, Base64, Base64URL o notación de diagnóstico CBOR a otro formato.