Aller au contenu principal

RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format

  • Statut: Proposed Standard
  • Publié: March 2014
  • Stream: IETF
  • Remplace: RFC4627, RFC7158
  • Remplacé par: RFC8259
  • Errata: Pas d'errata

Résumé (Abstract)​

JavaScript Object Notation (JSON) est un format d'échange de données léger, basé sur du texte et indépendant du langage. Il provient du standard du langage de programmation ECMAScript. JSON définit un petit ensemble de règles de formatage pour la représentation portable de données structurées.

Ce document élimine les incohérences avec d'autres spécifications JSON, corrige les erreurs de spécification et fournit des directives d'interopérabilité basées sur l'expérience.

Concepts fondamentaux de JSON​

Types de données​

JSON prend en charge les types de données suivants:

Types primitifs (Primitive Types):

  • string - Chaîne de caractères
  • number - Nombre
  • boolean - Booléen (true/false)
  • null - Valeur nulle

Types structurés (Structured Types):

  • object - Objet (collection non ordonnée de paires clé-valeur)
  • array - Tableau (séquence ordonnée de valeurs)

Exemples de syntaxe​

Objet (Object):

{
  "name": "张三",
  "age": 30,
  "city": "北京"
}

Tableau (Array):

[1, 2, 3, 4, 5]

Structure imbriquée:

{
  "users": [
    {"name": "Alice", "age": 25},
    {"name": "Bob", "age": 30}
  ],
  "total": 2
}

Changements principaux par rapport à RFC 4627​

  1. Définition de texte JSON plus souple: Permet au texte JSON d'être n'importe quelle valeur JSON, pas seulement des objets ou des tableaux
  2. Corrections d'erreurs: Corrige les erreurs signalées dans RFC 4627
  3. Directives d'interopérabilité: Fournit plus de conseils sur l'interopérabilité de l'implémentation
  4. Clarté de l'encodage: Met l'accent sur l'utilisation de l'encodage UTF-8
  • Texte original officiel: RFC 7159 (TXT)
  • Page officielle: RFC 7159 DataTracker
  • Rend obsolète: RFC 4627 (ancienne spécification JSON)
  • Rendu obsolète par: A été remplacé par RFC 8259
  • Type de média: application/json
  • Extension de fichier: .json

Référence rapide​

Type MIME​

Content-Type: application/json; charset=UTF-8

Outils couramment utilisés​

Validation en ligne:

Support des langages de programmation:

JavaScript:

const obj = JSON.parse('{"name":"Alice"}');
const str = JSON.stringify({name: "Bob"});

Python:

import json
obj = json.loads('{"name":"Alice"}')
str = json.dumps({"name": "Bob"})

Java:

// Avec la bibliothèque Jackson ou Gson
ObjectMapper mapper = new ObjectMapper();
MyObject obj = mapper.readValue(jsonString, MyObject.class);

Note importante: RFC 7159 a été remplacé par RFC 8259, mais reste un document important pour comprendre l'historique de l'évolution de JSON. Les applications modernes devraient se référer à RFC 8259 comme norme actuelle.

1. Introduction​

JavaScript Object Notation (JSON) est un format textuel pour la sérialisation de données structurées. Il dérive des littéraux d'objets JavaScript, tels que définis dans la norme du langage de programmation ECMAScript, troisième édition [ECMA-262].

JSON peut représenter quatre types primitifs (chaînes, nombres, booléens et null) ainsi que deux types structurés (objets et tableaux).

Une chaîne est une séquence de zéro ou plusieurs caractères Unicode [UNICODE]. Notez que cette référence pointe vers la dernière version d'Unicode, et non vers une version spécifique. On s'attend à ce que les changements futurs de la spécification Unicode n'affectent pas la syntaxe de JSON.

Un objet est une collection non ordonnée de zéro ou plusieurs paires nom/valeur, où un nom est une chaîne et une valeur peut être une chaîne, un nombre, un booléen, null, un objet ou un tableau.

Un tableau est une séquence ordonnée de zéro ou plusieurs valeurs.

Les termes "objet" et "tableau" proviennent des conventions de JavaScript.

Les objectifs de conception de JSON étaient d'être minimal, portable, textuel et un sous-ensemble de JavaScript.

1.1. Conventions Used in This Document (Conventions utilisées dans ce document)​

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].

Les règles de grammaire dans ce document doivent être interprétées comme décrit dans [RFC5234].

1.2. Specifications of JSON (Spécifications de JSON)​

Ce document met à jour [RFC4627], qui décrivait JSON et enregistrait le type de média "application/json".

Une description de JSON en termes ECMAScript apparaît dans la version 5.1 de la spécification ECMAScript [ECMA-262], section 15.12. JSON est également décrit dans [ECMA-404].

Toutes les spécifications grammaticales JSON sont d'accord sur les éléments syntaxiques du langage.

1.3. Introduction to This Revision (Introduction à cette révision)​

Au cours des années écoulées depuis la publication de RFC 4627, JSON a connu une utilisation très large. Cette expérience a révélé certains modèles qui, bien qu'autorisés par les spécifications, ont conduit à des problèmes d'interopérabilité.

De plus, un petit nombre d'errata ont été signalés (voir les identifiants d'erratum RFC 607 [Err607] et 3607 [Err3607]).

L'objectif de ce document est d'appliquer ces errata, d'éliminer les incohérences avec d'autres spécifications JSON et de mettre en évidence les pratiques qui peuvent conduire à des problèmes d'interopérabilité.

2. JSON Grammar (Grammaire JSON)​

Un texte JSON est une séquence de jetons. L'ensemble de jetons comprend six caractères structurels, des chaînes, des nombres et trois noms littéraux.

Un texte JSON est une valeur sérialisée. Notez que certaines spécifications JSON antérieures limitaient un texte JSON à un objet ou un tableau. Les implémentations qui ne génèrent que des objets ou des tableaux là où un texte JSON est requis seront interopérables, car toutes les implémentations accepteront ces textes comme des textes JSON conformes.

JSON-text = ws value ws

Voici les six caractères structurels:

begin-array     = ws %x5B ws  ; [ crochet gauche
begin-object    = ws %x7B ws  ; { accolade gauche
end-array       = ws %x5D ws  ; ] crochet droit
end-object      = ws %x7D ws  ; } accolade droite
name-separator  = ws %x3A ws  ; : deux-points
value-separator = ws %x2C ws  ; , virgule

Un espace blanc insignifiant est autorisé avant ou après l'un des six caractères structurels.

ws = *(
        %x20 /              ; Espace (Space)
        %x09 /              ; Tabulation horizontale (Horizontal tab)
        %x0A /              ; Saut de ligne (Line feed or New line)
        %x0D )              ; Retour chariot (Carriage return)

7. Strings (Chaînes)​

La représentation des chaînes est similaire aux conventions utilisées dans la famille de langages de programmation C. Une chaîne commence et se termine par des guillemets. Tous les caractères Unicode peuvent être placés entre guillemets, à l'exception des caractères qui doivent être échappés: guillemets, barre oblique inverse et caractères de contrôle (U+0000 à U+001F).

Tout caractère peut être échappé. Si le caractère se trouve dans le plan multilingue de base (BMP) (U+0000 à U+FFFF), il peut être représenté sous forme de séquence de six caractères: une barre oblique inverse, suivie de la lettre minuscule u, suivie de quatre chiffres hexadécimaux encodant le point de code du caractère. Les lettres hexadécimales A à F peuvent être en majuscules ou en minuscules. Ainsi, par exemple, une chaîne ne contenant qu'un seul caractère barre oblique inverse peut être représentée comme "\u005C".

Alternativement, il existe des représentations d'échappement en séquence de deux caractères pour certains caractères couramment utilisés. Ainsi, par exemple, une chaîne ne contenant qu'un seul caractère barre oblique inverse peut être représentée de manière plus compacte comme "\\"".

Pour échapper un caractère étendu qui n'est pas dans le plan multilingue de base, le caractère est représenté comme une séquence de 12 caractères, encodant une paire de substitution UTF-16. Ainsi, par exemple, une chaîne ne contenant que le caractère clé de sol (U+1D11E) peut être représentée comme "\uD834\uDD1E".

string = quotation-mark *char quotation-mark

char = unescaped /
    escape (
        %x22 /          ; "    Guillemets         U+0022
        %x5C /          ; \    Barre oblique inv. U+005C
        %x2F /          ; /    Barre oblique      U+002F
        %x62 /          ; b    Retour arrière     U+0008
        %x66 /          ; f    Saut de page       U+000C
        %x6E /          ; n    Saut de ligne      U+000A
        %x72 /          ; r    Retour chariot     U+000D
        %x74 /          ; t    Tabulation         U+0009
        %x75 4HEXDIG )  ; uXXXX                   U+XXXX

escape = %x5C              ; \

quotation-mark = %x22      ; "

unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

8. String and Character Issues (Problèmes de chaînes et de caractères)​

8.1. Character Encoding (Encodage des caractères)​

Le texte JSON DOIT être encodé en UTF-8, UTF-16 ou UTF-32. L'encodage par défaut est UTF-8, et le texte JSON encodé en UTF-8 est interopérable car il sera lu avec succès par le plus grand nombre d'implémentations; il existe de nombreuses implémentations qui ne peuvent pas lire avec succès les textes dans d'autres encodages (tels que UTF-16 et UTF-32).

Les implémentations NE DOIVENT PAS ajouter une marque d'ordre d'octets (BOM) au début d'un texte JSON. Pour l'interopérabilité, les implémentations qui analysent du texte JSON PEUVENT ignorer la présence d'une marque d'ordre d'octets plutôt que de la traiter comme une erreur.

8.2. Unicode Characters (Caractères Unicode)​

Lorsque toutes les chaînes représentées dans le texte JSON sont entièrement composées de caractères Unicode [UNICODE] (quelle que soit la manière dont ils sont échappés), ce texte JSON est interopérable car toutes les implémentations logicielles qui l'analysent s'accorderont sur le contenu des noms et des valeurs de chaînes dans les objets et les tableaux.

Cependant, l'ABNF dans cette spécification permet aux noms de membres et aux valeurs de chaînes de contenir des séquences de bits qui ne peuvent pas encoder de caractères Unicode; par exemple, "\uDEAD" (un seul substitut UTF-16 non apparié). Des instances de cette situation ont été observées, par exemple, lorsque des bibliothèques tronquent des chaînes UTF-16 sans vérifier si la troncature divise une paire de substituts. Le comportement du logiciel qui reçoit du texte JSON contenant de telles valeurs est imprévisible; par exemple, les implémentations peuvent renvoyer des valeurs différentes pour la longueur des valeurs de chaînes, voire subir des exceptions d'exécution fatales.

8.3. String Comparison (Comparaison de chaînes)​

Les implémentations logicielles doivent souvent tester l'égalité des noms de membres d'objets. Les implémentations qui convertissent la représentation textuelle en une séquence d'unités de code Unicode, puis effectuent une comparaison numérique unité de code par unité de code, sont interopérables car les implémentations s'accorderont dans tous les cas sur l'égalité ou l'inégalité de deux chaînes. Par exemple, les implémentations qui comparent inconditionnellement des chaînes échappées pourraient découvrir à tort que "a\\b" et "a\u005Cb" ne sont pas égales.

9. Parsers (Analyseurs)​

Un analyseur JSON convertit un texte JSON en une autre représentation. Un analyseur JSON DOIT accepter tous les textes conformes à la grammaire JSON. Un analyseur JSON PEUT accepter des formes non-JSON ou des extensions.

Une implémentation peut définir des limites sur la taille des textes acceptés. Une implémentation peut définir des limites sur la profondeur maximale d'imbrication. Une implémentation peut définir des limites sur la plage et la précision des nombres. Une implémentation peut définir des limites sur la longueur et le contenu des caractères des chaînes.

10. Generators (Générateurs)​

Un générateur JSON produit du texte JSON. Le texte produit DOIT strictement se conformer à la grammaire JSON.

12. Security Considerations (Considérations de sécurité)​

En général, il existe des problèmes de sécurité avec les langages de script. JSON est un sous-ensemble de JavaScript, mais exclut les affectations et les appels.

Étant donné que la syntaxe JSON est empruntée à JavaScript, il est possible d'utiliser la fonction "eval()" de ce langage pour analyser du texte JSON. Cela constitue généralement un risque de sécurité inacceptable, car le texte peut contenir du code exécutable ainsi que des déclarations de données. Les mêmes considérations s'appliquent à l'utilisation de fonctions de type eval() dans tout autre langage de programmation dans lequel le texte JSON est conforme à la syntaxe de ce langage.

14. Contributors (Contributeurs)​

RFC 4627 a été écrit par Douglas Crockford. Ce document a été construit en apportant relativement peu de modifications à ce document; par conséquent, la grande majorité du texte ici est le sien.

Appendix A. Changes from RFC 4627 (Changements par rapport à RFC 4627)​

Cette section énumère les changements entre ce document et le texte de RFC 4627.

  • Modifié le titre et le résumé du document

  • Changé la référence à [UNICODE] pour qu'elle ne soit pas spécifique à une version

  • Ajouté la section "Spécifications JSON"

  • Ajouté la section "Introduction à cette révision"

  • Changé la définition de "texte JSON" pour qu'il puisse être n'importe quelle valeur JSON, supprimant la contrainte qu'il devait être un objet ou un tableau

  • Ajouté un langage sur les noms de membres d'objet en double, l'ordre des membres et l'interopérabilité

  • Clarifié que les valeurs d'un tableau ne doivent pas être du même type JSON

  • Appliqué l'erratum #607 de RFC 4627 pour corriger l'alignement du diagramme de la définition "object"

  • Changé "as sequences of digits" en "in the grammar below" dans la section "Nombres" et clarifié la base décimale

  • Ajouté un langage sur l'interopérabilité des nombres en tant que fonction IEEE754 et ajouté une référence IEEE754

  • Ajouté un langage sur l'interopérabilité et les caractères Unicode ainsi que sur la comparaison de chaînes. Pour cela, transformé l'ancienne section "Encodage" en section "Problèmes de chaînes et de caractères" avec trois sous-sections: "Encodage des caractères", "Caractères Unicode" et "Comparaison de chaînes"

  • Changé les directives de la section "Analyseurs" pour indiquer que les implémentations peuvent définir des limites sur la plage "et la précision" des nombres

  • Mis à jour et nettoyé la section "Considérations IANA"

  • Créé une véritable section "Considérations de sécurité" et extrait du texte de la section précédente "Considérations IANA"

  • Appliqué l'erratum #3607 de RFC 4627 en supprimant la considération de sécurité commençant par "A JSON text can be safely passed" ainsi que le code JavaScript associé à cette considération

  • Ajouté une note dans la section "Considérations de sécurité" soulignant le risque d'utiliser la fonction "eval()" en JavaScript ou dans tout autre langage où le texte JSON est conforme à la syntaxe de ce langage

  • Ajouté une note dans "Considérations IANA" clarifiant que le type de média application/json ne dispose pas d'un paramètre "charset"

  • Changé "100" en 100 dans le premier exemple et ajouté un champ booléen

  • Ajouté des exemples de textes JSON avec des valeurs simples (ni objet ni tableau)

  • Ajouté une section "Contributeurs" pour remercier Douglas Crockford

  • Ajouté une référence à RFC 4627

  • Déplacé la référence ECMAScript de normative à informative et mis à jour pour référencer ECMAScript 5.1, et ajouté une référence à ECMA 404