2. Spécification de l'encodage CBOR

Un élément de données encodé en CBOR est structuré et encodé comme décrit dans cette section. L'encodage est résumé dans le Tableau 5.

L'octet initial de chaque élément de données contient à la fois une information sur le type majeur (les 3 bits de poids fort, décrits à la Section 2.1) et une information additionnelle (les 5 bits de poids faible). Lorsque la valeur de l'information additionnelle est inférieure à 24, elle est directement utilisée comme petit entier non signé. Lorsqu'elle vaut de 24 à 27, les octets additionnels d'un entier de longueur variable suivent immédiatement ; les valeurs 24 à 27 de l'information additionnelle spécifient que sa longueur est un entier non signé de 1, 2, 4 ou 8 octets, respectivement. La valeur 31 de l'information additionnelle est utilisée pour les éléments de longueur indéfinie, décrits à la Section 2.2. Les valeurs 28 à 30 de l'information additionnelle sont réservées à une extension future.

Pour toutes les valeurs de l'information additionnelle, l'entier résultant est interprété en fonction du type majeur. Il peut représenter les données effectives : par exemple, dans les types entiers, l'entier résultant est utilisé pour la valeur elle-même. Il peut à la place fournir une information de longueur : par exemple, dans les chaînes d'octets, il donne la longueur des données de la chaîne d'octets qui suivent.

Une implémentation de décodeur CBOR peut être basée sur une table de sauts avec les 256 valeurs définies pour l'octet initial (Tableau 5). Un décodeur dans une implémentation contrainte peut à la place utiliser la structure de l'octet initial et des octets suivants pour un code plus compact (voir l'Annexe C pour une idée approximative de ce à quoi cela pourrait ressembler).

2.1. Types majeurs

Ce qui suit liste les types majeurs ainsi que l'information additionnelle et les autres octets associés au type.

Type majeur 0 : un entier non signé. L'information additionnelle de 5 bits est soit l'entier lui-même (pour les valeurs d'information additionnelle de 0 à 23), soit la longueur des données additionnelles. L'information additionnelle 24 signifie que la valeur est représentée dans un uint8_t additionnel, 25 signifie un uint16_t, 26 un uint32_t et 27 un uint64_t. Par exemple, l'entier 10 est noté par l'octet unique 0b000_01010 (type majeur 0, information additionnelle 10). L'entier 500 serait 0b000_11001 (type majeur 0, information additionnelle 25) suivi des deux octets 0x01f4, ce qui vaut 500 en décimal.

Type majeur 1 : un entier négatif. L'encodage suit les règles des entiers non signés (type majeur 0), à ceci près que la valeur est ensuite -1 moins l'entier non signé encodé. Par exemple, l'entier -500 serait 0b001_11001 (type majeur 1, information additionnelle 25) suivi des deux octets 0x01f3, ce qui vaut 499 en décimal.

Type majeur 2 : une chaîne d'octets. La longueur de la chaîne en octets est représentée selon les règles des entiers positifs (type majeur 0). Par exemple, une chaîne d'octets dont la longueur est 5 aurait un octet initial de 0b010_00101 (type majeur 2, information additionnelle 5 pour la longueur), suivi de 5 octets de contenu binaire. Une chaîne d'octets dont la longueur est 500 aurait 3 octets initiaux de 0b010_11001 (type majeur 2, information additionnelle 25 pour indiquer une longueur de deux octets) suivis des deux octets 0x01f4 pour une longueur de 500, suivis de 500 octets de contenu binaire.

Type majeur 3 : une chaîne de texte, plus précisément une chaîne de caractères Unicode encodée en UTF-8 [RFC3629]. Le format de ce type est identique à celui des chaînes d'octets (type majeur 2), c'est-à-dire que, comme pour le type majeur 2, la longueur donne le nombre d'octets. Ce type est fourni pour les systèmes qui ont besoin d'interpréter ou d'afficher du texte lisible par un humain, et permet de distinguer les octets non structurés du texte qui possède un répertoire et un encodage spécifiés. Contrairement à des formats tels que JSON, les caractères Unicode dans ce type ne sont jamais échappés. Ainsi, un caractère de saut de ligne (U+000A) est toujours représenté dans une chaîne par l'octet 0x0a, et jamais par les octets 0x5c6e (les caractères "" et "n") ni par 0x5c7530303061 (les caractères "", "u", "0", "0", "0" et "a").

Type majeur 4 : un tableau d'éléments de données. Les tableaux sont aussi appelés listes, séquences ou tuples. La longueur du tableau suit les règles des chaînes d'octets (type majeur 2), à ceci près que la longueur désigne le nombre d'éléments de données, et non la longueur en octets occupée par le tableau. Les éléments d'un tableau n'ont pas besoin d'être tous du même type. Par exemple, un tableau qui contient 10 éléments de n'importe quel type aurait un octet initial de 0b100_01010 (type majeur 4, information additionnelle 10 pour la longueur) suivi des 10 éléments restants.

Type majeur 5 : une map de paires d'éléments de données. Les maps sont aussi appelées tables, dictionnaires, tables de hachage ou objets (en JSON). Une map est composée de paires d'éléments de données, chaque paire consistant en une clé immédiatement suivie d'une valeur. La longueur de la map suit les règles des chaînes d'octets (type majeur 2), à ceci près que la longueur désigne le nombre de paires, et non la longueur en octets occupée par la map. Par exemple, une map qui contient 9 paires aurait un octet initial de 0b101_01001 (type majeur 5, information additionnelle 9 pour le nombre de paires) suivi des 18 éléments restants. Le premier élément est la première clé, le deuxième élément est la première valeur, le troisième élément est la deuxième clé, et ainsi de suite. Une map qui possède des clés en double peut être bien formée, mais elle n'est pas valide, et provoque donc un décodage indéterminé ; voir aussi la Section 3.7.

Type majeur 6 : étiquetage sémantique optionnel des autres types majeurs. Voir la Section 2.4.

Type majeur 7 : nombres en virgule flottante et types de données simples qui n'ont pas besoin de contenu, ainsi que le code d'arrêt "break". Voir la Section 2.3.

Ces huit types majeurs conduisent à une table simple montrant laquelle des 256 valeurs possibles pour l'octet initial d'un élément de données est utilisée (Tableau 5).

Dans les types majeurs 6 et 7, beaucoup des valeurs possibles sont réservées à une spécification future. Voir la Section 7 pour plus d'informations sur ces valeurs.

2.2. Longueurs indéfinies pour certains types majeurs

Quatre éléments CBOR (tableaux, maps, chaînes d'octets et chaînes de texte) peuvent être encodés avec une longueur indéfinie en utilisant la valeur d'information additionnelle 31. Ceci est utile si l'encodage de l'élément doit commencer avant que le nombre d'éléments contenus dans le tableau ou la map, ou la longueur totale de la chaîne, ne soit connu. (L'application de ceci est souvent appelée « streaming » au sein d'un élément de données.)

Les tableaux et maps de longueur indéfinie sont traités différemment des chaînes d'octets et de texte de longueur indéfinie.

2.2.1. Tableaux et maps de longueur indéfinie

Les tableaux et maps de longueur indéfinie sont simplement ouverts sans indiquer le nombre d'éléments de données qui seront inclus dans le tableau ou la map, en utilisant la valeur d'information additionnelle 31. L'octet initial de type majeur et d'information additionnelle est suivi des éléments du tableau ou de la map, tout comme ils le seraient dans d'autres tableaux ou maps. La fin du tableau ou de la map est indiquée en encodant un code d'arrêt "break" à un endroit où l'élément de données suivant aurait normalement été inclus. Le "break" est encodé avec le type majeur 7 et la valeur d'information additionnelle 31 (0b111_11111), mais n'est pas lui-même un élément de données : c'est simplement une fonctionnalité syntaxique pour fermer le tableau ou la map. Autrement dit, le code d'arrêt "break" vient après le dernier élément du tableau ou de la map, et il ne peut apparaître nulle part ailleurs à la place d'un élément de données. De cette façon, les tableaux et maps de longueur indéfinie sont identiques aux autres tableaux et maps, si ce n'est qu'ils commencent par la valeur d'information additionnelle 31 et se terminent par le code d'arrêt "break".

Les tableaux et maps de longueur indéfinie autorisent un nombre quelconque d'éléments (pour les tableaux) et de paires clé/valeur (pour les maps) avant le code d'arrêt "break". Il n'y a aucune restriction à l'imbrication d'éléments de tableau ou de map de longueur indéfinie. Un "break" ne termine qu'un seul élément, donc les éléments de longueur indéfinie imbriqués nécessitent exactement autant de codes d'arrêt "break" qu'il y a d'octets de type ouvrant un élément de longueur indéfinie.

Par exemple, supposons qu'un encodeur veuille représenter le tableau abstrait [1, [2, 3], [4, 5]]. L'encodage de longueur définie serait 0x8301820203820405 :

83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5

L'encodage de longueur indéfinie pourrait être appliqué indépendamment à chacun des trois tableaux encodés dans cet élément de données, selon les besoins, conduisant à des représentations telles que :

0x9f018202039f0405ffff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break" (inner array) FF -- "break" (outer array)

0x9f01820203820405ff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5 FF -- "break" 0x83018202039f0405ff 83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break"

0x83019f0203ff820405 83 -- Array of length 3 01 -- 1 9F -- Start indefinite-length array 02 -- 2 03 -- 3 FF -- "break" 82 -- Array of length 2 04 -- 4 05 -- 5

Un exemple de map de longueur indéfinie (qui se trouve avoir deux paires clé/valeur) pourrait être :

0xbf6346756ef563416d7421ff BF -- Start indefinite-length map 63 -- First key, UTF-8 string length 3 46756e -- "Fun" F5 -- First value, true 63 -- Second key, UTF-8 string length 3 416d74 -- "Amt" 21 -- -2 FF -- "break"

2.2.2. Chaînes d'octets et de texte de longueur indéfinie

Les chaînes d'octets et de texte de longueur indéfinie sont en réalité une concaténation de zéro ou plusieurs chaînes d'octets ou de texte de longueur définie (« fragments ») qui sont traitées ensemble comme une seule chaîne contiguë. Les chaînes de longueur indéfinie sont ouvertes avec le type majeur et la valeur d'information additionnelle 31, mais ce qui suit est une série de chaînes d'octets ou de texte qui ont des longueurs définies (les fragments). La fin de la série de fragments est indiquée en encodant le code d'arrêt "break" (0b111_11111) à l'endroit où le fragment suivant de la série devrait apparaître. Le contenu des fragments est concaténé, et la longueur totale de la chaîne de longueur indéfinie sera la somme des longueurs de tous les fragments. En résumé, une chaîne de longueur indéfinie est encodée de manière similaire à un tableau de longueur indéfinie de ses fragments, à ceci près que le type majeur de la chaîne de longueur indéfinie est celui d'une chaîne (de texte ou d'octets) et correspond aux types majeurs de ses fragments.

Pour les chaînes d'octets de longueur indéfinie, chaque élément de données (fragment) entre l'indicateur de longueur indéfinie et le "break" MUST être un élément de chaîne d'octets de longueur définie ; si l'analyseur voit un type d'élément autre qu'une chaîne d'octets avant de voir le "break", c'est une erreur.

Par exemple, supposons la séquence :

0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111

5F -- Start indefinite-length byte string 44 -- Byte string of length 4 aabbccdd -- Bytes content 43 -- Byte string of length 3 eeff99 -- Bytes content FF -- "break"

Après décodage, ceci donne une seule chaîne d'octets de sept octets : 0xaabbccddeeff99.

Les chaînes de texte de longueur indéfinie se comportent comme les chaînes d'octets de longueur indéfinie, à ceci près que tous leurs fragments MUST être des chaînes de texte de longueur définie. Notez que ceci implique que les octets d'un caractère UTF-8 unique ne peuvent pas être répartis entre les fragments : un nouveau fragment ne peut commencer qu'à une frontière de caractère.

2.3. Nombres en virgule flottante et valeurs sans contenu

Le type majeur 7 concerne deux types de données : les nombres en virgule flottante et les « valeurs simples » qui n'ont pas besoin de contenu. Chaque valeur de l'information additionnelle de 5 bits dans l'octet initial a sa propre signification, comme défini dans le Tableau 1. Comme pour les types majeurs des entiers, les éléments de ce type majeur ne transportent pas de données de contenu ; toutes les informations sont dans les octets initiaux.

Valeur 5 bits	Sémantique
0..23	Valeur simple (valeur 0..23)
24	Valeur simple (valeur 32..255 dans l'octet suivant)
25	Flottant demi-précision IEEE 754 (16 bits suivent)
26	Flottant simple précision IEEE 754 (32 bits suivent)
27	Flottant double précision IEEE 754 (64 bits suivent)
28-30	(Non attribué)
31	Code d'arrêt "break" pour les éléments de longueur indéfinie

Tableau 1 : Valeurs de l'information additionnelle dans le type majeur 7

Comme pour tous les autres types majeurs, la valeur 5 bits 24 signifie une extension d'un octet : elle est suivie d'un octet additionnel pour représenter la valeur simple. (Pour minimiser la confusion, seules les valeurs de 32 à 255 sont utilisées.) Ceci maintient la structure des octets initiaux : comme pour les autres types majeurs, leur longueur dépend toujours de l'information additionnelle dans le premier octet. Le Tableau 2 liste les valeurs attribuées et disponibles pour les types simples.

Valeur	Sémantique
0..19	(Non attribué)
20	False
21	True
22	Null
23	Valeur Undefined
24..31	(Réservé)
32..255	(Non attribué)

Tableau 2 : Valeurs simples

Les valeurs 5 bits 25, 26 et 27 concernent les valeurs en virgule flottante binaire IEEE 754 de 16, 32 et 64 bits. Ces valeurs en virgule flottante sont encodées dans les octets additionnels de la taille appropriée. (Voir l'Annexe D pour des informations sur la virgule flottante 16 bits.)

2.4. Étiquetage optionnel des éléments

Dans CBOR, un élément de données peut optionnellement être précédé d'un tag pour lui donner une sémantique additionnelle tout en conservant sa structure. Le tag est le type majeur 6, et représente un nombre entier comme indiqué par la valeur entière du tag ; l'élément de données (unique) est transporté comme données de contenu. Si un tag requiert des données structurées, cette structure est encodée dans l'élément de données imbriqué. La définition d'un tag restreint généralement les types d'éléments de données imbriqués qu'un tag peut transporter.

Les octets initiaux du tag suivent les règles des entiers positifs (type majeur 0). Le tag est suivi d'un seul élément de données de n'importe quel type. Par exemple, supposons qu'une chaîne d'octets de longueur 12 soit marquée d'un tag pour indiquer qu'il s'agit d'un bignum positif (Section 2.4.2). Ceci serait marqué comme 0b110_00010 (type majeur 6, information additionnelle 2 pour le tag) suivi de 0b010_01100 (type majeur 2, information additionnelle 12 pour la longueur) suivi des 12 octets du bignum.

Les décodeurs n'ont pas besoin de comprendre les tags, et ainsi les tags peuvent être de peu de valeur dans les applications où l'implémentation qui crée un élément de données CBOR particulier et l'implémentation qui décode ce flux connaissent la signification sémantique de chaque élément du flux de données. Leur objectif principal dans cette spécification est de définir des types de données courants tels que les dates. Un objectif secondaire est d'autoriser un étiquetage optionnel lorsque le décodeur est un décodeur CBOR générique qui pourrait bénéficier d'indices sur le contenu des éléments. La compréhension des tags sémantiques est optionnelle pour un décodeur ; il peut simplement sauter les octets initiaux du tag et interpréter l'élément de données étiqueté lui-même.

Un tag s'applique toujours à l'élément qui le suit directement. Ainsi, si le tag A est suivi du tag B, lui-même suivi de l'élément de données C, le tag A s'applique au résultat de l'application du tag B à l'élément de données C. Autrement dit, un élément étiqueté est un élément de données consistant en un tag et une valeur. Le contenu de l'élément étiqueté est l'élément de données (la valeur) qui est étiqueté.

L'IANA maintient un registre des valeurs de tag comme décrit à la Section 7.2. Le Tableau 3 fournit une liste des valeurs initiales, avec les définitions dans le reste de cette section.

Tag	Élément de données	Sémantique
0	Chaîne UTF-8	Chaîne de date/heure standard ; voir Section 2.4.1
1	multiple	Date/heure basée sur l'époque ; voir Section 2.4.1
2	Chaîne d'octets	Bignum positif ; voir Section 2.4.2
3	Chaîne d'octets	Bignum négatif ; voir Section 2.4.2
4	Tableau	Fraction décimale ; voir Section 2.4.3
5	Tableau	Bigfloat ; voir Section 2.4.3
6..20	(Non attribué)	(Non attribué)
21	multiple	Conversion attendue en encodage base64url ; voir Section 2.4.4.2
22	multiple	Conversion attendue en encodage base64 ; voir Section 2.4.4.2
23	multiple	Conversion attendue en encodage base16 ; voir Section 2.4.4.2
24	Chaîne d'octets	Élément de données CBOR encodé ; voir Section 2.4.4.1
25..31	(Non attribué)	(Non attribué)
32	Chaîne UTF-8	URI ; voir Section 2.4.4.3
33	Chaîne UTF-8	base64url ; voir Section 2.4.4.3
34	Chaîne UTF-8	base64 ; voir Section 2.4.4.3
35	Chaîne UTF-8	Expression régulière ; voir Section 2.4.4.3
36	Chaîne UTF-8	Message MIME ; voir Section 2.4.4.3
37..55798	(Non attribué)	(Non attribué)
55799	multiple	CBOR auto-descriptif ; voir Section 2.4.5
55800+	(Non attribué)	(Non attribué)

Tableau 3 : Valeurs des tags

2.4.1. Date et heure

La valeur de tag 0 concerne les chaînes de date/heure qui suivent le format standard décrit dans [RFC3339], tel que précisé par la Section 3.3 de [RFC4287].

La valeur de tag 1 concerne la représentation numérique des secondes relatives à 1970-01-01T00:00Z en temps UTC. (Pour les valeurs non négatives que définit la Portable Operating System Interface (POSIX), le nombre de secondes est compté de la même manière que pour le « seconds since the epoch » de POSIX [TIME_T].) L'élément étiqueté peut être un entier positif ou négatif (types majeurs 0 et 1), ou un nombre en virgule flottante (type majeur 7 avec information additionnelle 25, 26 ou 27). Notez que le nombre peut être négatif (temps antérieur à 1970-01-01T00:00Z) et, s'il s'agit d'un nombre en virgule flottante, indiquer des secondes fractionnaires.

2.4.2. Bignums

Les bignums sont des entiers qui ne tiennent pas dans les représentations entières de base fournies par les types majeurs 0 et 1. Ils sont encodés comme un élément de données de chaîne d'octets, qui est interprété comme un entier non signé n en ordre des octets du réseau. Pour la valeur de tag 2, la valeur du bignum est n. Pour la valeur de tag 3, la valeur du bignum est -1 - n. Les décodeurs qui comprennent ces tags MUST être capables de décoder les bignums qui ont des zéros de tête.

Par exemple, le nombre 18446744073709551616 (2**64) est représenté par 0b110_00010 (type majeur 6, tag 2), suivi de 0b010_01001 (type majeur 2, longueur 9), suivi de 0x010000000000000000 (un octet 0x01 et huit octets 0x00). En hexadécimal :

C2 -- Tag 2 29 -- Byte string of length 9 010000000000000000 -- Bytes content

2.4.3. Fractions décimales et bigfloats

Les fractions décimales combinent une mantisse entière avec un facteur d'échelle en base 10. Elles sont particulièrement utiles si une application a besoin de la représentation exacte d'une fraction décimale telle que 1.1, car il n'existe pas de représentation exacte pour de nombreuses fractions décimales en virgule flottante binaire.

Les bigfloats combinent une mantisse entière avec un facteur d'échelle en base 2. Ce sont des valeurs en virgule flottante binaire qui peuvent dépasser la plage ou la précision des trois formats IEEE 754 pris en charge par CBOR (Section 2.3). Les bigfloats peuvent également être utilisés par des applications contraintes qui ont besoin d'une capacité de virgule flottante binaire de base sans avoir à prendre en charge IEEE 754.

Une fraction décimale ou un bigfloat est représenté comme un tableau étiqueté qui contient exactement deux nombres entiers : un exposant e et une mantisse m. Les fractions décimales (tag 4) utilisent des exposants en base 10 ; la valeur d'un élément de données de fraction décimale est m*(10e). Les bigfloats (tag 5) utilisent des exposants en base 2 ; la valeur d'un élément de données bigfloat est m*(2e). L'exposant e MUST être représenté dans un entier de type majeur 0 ou 1, tandis que la mantisse peut également être un bignum (Section 2.4.2).

Un exemple de fraction décimale : le nombre 273.15 pourrait être représenté par 0b110_00100 (type majeur 6 pour le tag, information additionnelle 4 pour le type de tag), suivi de 0b100_00010 (type majeur 4 pour le tableau, information additionnelle 2 pour la longueur du tableau), suivi de 0b001_00001 (type majeur 1 pour le premier entier, information additionnelle 1 pour la valeur -2), suivi de 0b000_11001 (type majeur 0 pour le deuxième entier, information additionnelle 25 pour une valeur de deux octets), suivi de 0b0110101010110011 (27315 en deux octets). En hexadécimal :

C4 -- Tag 4 82 -- Array of length 2 21 -- -2 19 6ab3 -- 27315

Un exemple de bigfloat : le nombre 1.5 pourrait être représenté par 0b110_00101 (type majeur 6 pour le tag, information additionnelle 5 pour le type de tag), suivi de 0b100_00010 (type majeur 4 pour le tableau, information additionnelle 2 pour la longueur du tableau), suivi de 0b001_00000 (type majeur 1 pour le premier entier, information additionnelle 0 pour la valeur -1), suivi de 0b000_00011 (type majeur 0 pour le deuxième entier, information additionnelle 3 pour la valeur 3). En hexadécimal :

C5 -- Tag 5 82 -- Array of length 2 20 -- -1 03 -- 3

Les fractions décimales et les bigfloats ne fournissent aucune représentation de Infinity, -Infinity ou NaN ; si celles-ci sont nécessaires à la place d'une fraction décimale ou d'un bigfloat, les représentations IEEE 754 demi-précision de la Section 2.3 peuvent être utilisées. Pour les applications contraintes, lorsqu'il existe un choix entre représenter un nombre spécifique comme entier et comme fraction décimale ou bigfloat (par exemple lorsque l'exposant est petit et non négatif), il existe une attente de qualité d'implémentation que la représentation entière soit utilisée directement.

2.4.4. Indices de contenu

Les tags de cette section sont des indices de contenu qui pourraient être utilisés par des processeurs CBOR génériques.

2.4.4.1. Élément de données CBOR encodé

Il est parfois avantageux de transporter un élément de données CBOR imbriqué qui n'est pas destiné à être décodé immédiatement au moment où l'élément de données conteneur est analysé. Le tag 24 (élément de données CBOR) peut être utilisé pour étiqueter la chaîne d'octets imbriquée comme un élément de données encodé au format CBOR.

2.4.4.2. Encodage ultérieur attendu pour les convertisseurs CBOR vers JSON

Les tags 21 à 23 indiquent qu'une chaîne d'octets pourrait nécessiter un encodage spécifique lors de l'interopérabilité avec une représentation textuelle. Ces tags sont utiles lorsqu'un encodeur sait que les données de chaîne d'octets qu'il écrit seront probablement converties ultérieurement en un usage particulier basé sur JSON. Cet usage spécifie que certaines chaînes sont encodées en base64, base64url, etc. L'encodeur utilise des chaînes d'octets au lieu d'effectuer lui-même l'encodage afin de réduire la taille du message, de réduire la taille du code de l'encodeur, ou les deux. L'encodeur ne sait pas si le convertisseur sera générique, et souhaite donc indiquer ce qu'il considère comme la manière correcte de convertir les chaînes binaires en JSON.

L'élément de données étiqueté peut être une chaîne d'octets ou n'importe quel autre élément de données. Dans ce dernier cas, le tag s'applique à tous les éléments de données de chaîne d'octets contenus dans l'élément de données, à l'exception de ceux contenus dans un élément de données imbriqué étiqueté avec une conversion attendue.

Ces trois types de tags suggèrent des conversions vers trois des encodages de données de base définis dans [RFC4648]. Pour l'encodage base64url, le bourrage n'est pas utilisé (voir la Section 3.2 du RFC 4648) ; autrement dit, tous les signes égal ("=") de fin sont supprimés de la chaîne encodée en base64url. Des tags ultérieurs pourraient être définis pour d'autres encodages de données du RFC 4648 ou pour d'autres façons d'encoder des données binaires dans des chaînes.

2.4.4.3. Texte encodé

Certaines chaînes de texte contiennent des données dont les formats sont largement utilisés sur Internet, et parfois ces formats peuvent être validés et présentés à l'application sous une forme appropriée par le décodeur. Il existe des tags pour certains de ces formats.

• Le tag 32 concerne les URI, telles que définies dans [RFC3986] ;

• Les tags 33 et 34 concernent les chaînes de texte encodées en base64url et base64, telles que définies dans [RFC4648] ;

• Le tag 35 concerne les expressions régulières en syntaxe Perl Compatible Regular Expressions (PCRE) / JavaScript [ECMA262].

• Le tag 36 concerne les messages MIME (y compris tous les en-têtes), tels que définis dans [RFC2045] ;

Notez que les tags 33 et 34 diffèrent de 21 et 22 en ce que les données sont transportées sous forme encodée en base pour les premiers et sous forme de chaîne d'octets brute pour les seconds.

2.4.5. CBOR auto-descriptif

Dans de nombreuses applications, il sera clair d'après le contexte que CBOR est employé pour encoder un élément de données. Par exemple, un protocole spécifique peut imposer l'usage de CBOR, ou un type de média indiquant son usage peut être spécifié. Cependant, il peut exister des applications où de telles informations de contexte ne sont pas disponibles, par exemple lorsque des données CBOR sont stockées dans un fichier et qu'aucune métadonnée de désambiguïsation n'est utilisée. Dans ce cas, il peut être utile de disposer de caractéristiques distinctives pour les données elles-mêmes.

Le tag 55799 est défini à cette fin. Il ne confère aucune sémantique particulière à l'élément de données qui le suit ; autrement dit, la sémantique d'un élément de données étiqueté avec le tag 55799 est exactement identique à la sémantique de l'élément de données lui-même.

La sérialisation de ce tag est 0xd9d9f7, qui ne semble pas être utilisée comme marque distinctive pour les types de fichiers fréquemment utilisés. En particulier, ce n'est pas un début valide de texte Unicode dans quelque encodage Unicode que ce soit, lorsqu'il est suivi d'un élément de données CBOR valide.

Par exemple, un décodeur pourrait être capable d'analyser à la fois CBOR et JSON. Un tel décodeur devrait distinguer mécaniquement les deux formats. Une manière simple pour un encodeur d'aider le décodeur serait d'étiqueter l'élément CBOR entier avec le tag 55799, dont la sérialisation ne se trouvera jamais au début d'un texte JSON.