Aller au contenu principal

4. Conversion de données entre CBOR et JSON

Cette section donne des conseils non normatifs sur la conversion entre CBOR et JSON. Les implémentations de convertisseurs sont libres d'utiliser ceux de ces conseils qu'elles veulent.

Il vaut la peine de noter qu'un texte JSON est une séquence de caractères, et non une séquence d'octets encodée, tandis qu'un élément de données CBOR est constitué d'octets, et non de caractères.

4.1. Conversion de CBOR vers JSON​

La plupart des types de CBOR ont des analogues directs dans JSON. Cependant, certains n'en ont pas, et quiconque implémente un convertisseur CBOR-vers-JSON doit réfléchir à ce qu'il faut faire dans ces cas. Les conseils non normatifs suivants les traitent en les convertissant en une valeur de substitution unique, telle qu'un null JSON.

  • Un entier (type majeur 0 ou 1) devient un nombre JSON.

  • Une chaîne d'octets (type majeur 2) qui n'est pas intégrée dans une étiquette spécifiant un encodage proposé est encodée en base64url sans bourrage et devient une chaîne JSON.

  • Une chaîne UTF-8 (type majeur 3) devient une chaîne JSON. Notons que JSON exige l'échappement de certains caractères (RFC 4627, Section 2.5) : le guillemet (U+0022), la barre oblique inverse (U+005C), et les « caractères de contrôle C0 » (de U+0000 à U+001F). Tous les autres caractères sont copiés inchangés dans la chaîne UTF-8 JSON.

  • Un tableau (type majeur 4) devient un tableau JSON.

  • Une table (type majeur 5) devient un objet JSON. Cela n'est possible directement que si toutes les clés sont des chaînes UTF-8. Un convertisseur peut aussi convertir d'autres clés en chaînes UTF-8 (par exemple en convertissant les entiers en chaînes contenant leur représentation décimale) ; toutefois, cela introduit un risque de collision de clés.

  • False (type majeur 7, information additionnelle 20) devient un false JSON.

  • True (type majeur 7, information additionnelle 21) devient un true JSON.

  • Null (type majeur 7, information additionnelle 22) devient un null JSON.

  • Une valeur à virgule flottante (type majeur 7, information additionnelle 25 à 27) devient un nombre JSON si elle est finie (c'est-à-dire si elle peut être représentée dans un nombre JSON) ; si la valeur est non finie (NaN, ou l'infini positif ou négatif), elle est représentée par la valeur de substitution.

  • Toute autre valeur simple (type majeur 7, toute valeur d'information additionnelle non encore discutée) est représentée par la valeur de substitution.

  • Un bignum (type majeur 6, valeur d'étiquette 2 ou 3) est représenté en encodant sa chaîne d'octets en base64url sans bourrage et devient une chaîne JSON. Pour la valeur d'étiquette 3 (bignum négatif), un « ~ » (tilde ASCII) est inséré avant la valeur encodée en base. (La conversion en un objet binaire plutôt qu'en un nombre vise à prévenir un probable débordement numérique pour le décodeur JSON.)

  • Une chaîne d'octets avec une indication d'encodage (type majeur 6, valeurs d'étiquette 21 à 23) est encodée comme décrit et devient une chaîne JSON.

  • Pour toutes les autres étiquettes (type majeur 6, toute autre valeur d'étiquette), l'élément CBOR intégré est représenté comme une valeur JSON ; la valeur de l'étiquette est ignorée.

  • Les éléments de longueur indéfinie sont rendus définis avant la conversion.

4.2. Conversion de JSON vers CBOR​

Toutes les valeurs JSON, une fois décodées, se mappent directement en une ou plusieurs valeurs CBOR. Comme pour toute génération de CBOR, des décisions doivent être prises quant à la représentation des nombres. Dans une conversion suggérée :

  • Les nombres JSON sans partie fractionnaire (nombres entiers) sont représentés comme des entiers (types majeurs 0 et 1, éventuellement type majeur 6 valeurs d'étiquette 2 et 3), en choisissant la forme la plus courte ; les entiers plus longs qu'un seuil défini par l'implémentation (qui est habituellement de 32 ou 64 bits) peuvent plutôt être représentés comme des valeurs à virgule flottante. (Si le JSON a été généré à partir d'une implémentation JavaScript, sa précision est déjà limitée à 53 bits au maximum.)

  • Les nombres avec des parties fractionnaires sont représentés comme des valeurs à virgule flottante. De préférence, la représentation en virgule flottante exacte la plus courte est utilisée ; par exemple, 1,5 est représenté dans une valeur à virgule flottante de 16 bits (toutes les implémentations ne seront toutefois pas capables de trouver efficacement la forme minimale). Il peut y avoir une limite définie par l'implémentation sur la précision qui affectera la précision des valeurs représentées. La représentation décimale ne devrait être utilisée que si cela est spécifié dans un protocole.

CBOR a été conçu pour fournir généralement un encodage plus compact que JSON. Une stratégie d'implémentation qui pourrait venir à l'esprit consiste à effectuer un encodage JSON-vers-CBOR sur place dans un seul tampon. Cette stratégie devrait examiner attentivement un certain nombre de cas pathologiques, comme le fait que certaines chaînes représentées avec aucun ou très peu d'échappements et plus longues (ou beaucoup plus longues) que 255 octets peuvent s'étendre lorsqu'elles sont encodées comme chaînes UTF-8 dans CBOR. De même, quelques-unes des représentations binaires en virgule flottante pourraient provoquer une expansion à partir de certaines représentations décimales courtes (1.1, 1e9) dans JSON. Cela peut être difficile à réussir, et toute vulnérabilité qui en résulte peut être exploitée par un attaquant.