RFC(F) 7159

From RFC.Wiki
Jump to: navigation, search
        [Errata]

Obsolète: 8259 NORME PROPOSÉE
                                                            Errata existe

Groupe de travail sur l'ingénierie Internet (IETF) T. Bray, Ed.
Demande de commentaires: 7159 Google, Inc.
Obsolètes: 4627, 7158 mars 2014
Catégorie: Standards Track
ISSN: 2070-1721

     Format d'échange de données JSON (JavaScript Object Notation)

Abstrait

   La notation d'objet JavaScript (JSON) est un outil léger, basé sur du texte,
   format d'échange de données indépendant de la langue. Il est dérivé de
   la norme du langage de programmation ECMAScript. JSON définit un petit
   ensemble de règles de formatage pour la représentation portable de structures
   Les données.

   Ce document supprime les incohérences avec d'autres spécifications de
   JSON, répare les erreurs de spécification et propose une expérience
   guide d'interopérabilité.

Statut de ce mémo

   Il s'agit d'un document Internet Standards Track.

   Ce document est un produit de l'Internet Engineering Task Force
   (IETF). Il représente le consensus de la communauté IETF. Il a
   a reçu un examen public et a été approuvé pour publication par le
   Groupe directeur de l'ingénierie Internet (IESG). Plus d'informations sur
   Les normes Internet sont disponibles dans la section 2 de la RFC 5741.

   Informations sur l'état actuel de ce document, tout errata,
   et comment fournir des commentaires à ce sujet
   http://www.rfc-editor.org/info/rfc7159.

Copyright

   Copyright (c) 2014 IETF Trust et les personnes identifiées comme
   auteurs de documents. Tous les droits sont réservés.

   Ce document est soumis au BCP 78 et aux mentions légales de l'IETF Trust.
   Dispositions relatives aux documents de l'IETF
   (http://trustee.ietf.org/license-info) en vigueur à la date de
   publication de ce document. Veuillez consulter ces documents
   soigneusement, car ils décrivent vos droits et restrictions en ce qui concerne
   à ce document. Les composants de code extraits de ce document doivent
   inclure le texte de la licence BSD simplifiée comme décrit dans la section 4.e de
   les dispositions légales de Trust et sont fournis sans garantie
   décrit dans la licence BSD simplifiée.

   Ce document peut contenir des éléments des documents de l'IETF ou de l'IETF
   Contributions publiées ou rendues publiques avant novembre
   10, 2008. La ou les personnes contrôlant le droit d'auteur sur certains de ces
   matériel peut ne pas avoir accordé à l'IETF Trust le droit d'autoriser
   modifications de ce matériel en dehors du processus de normalisation de l'IETF.
   Sans obtenir une licence adéquate de la ou des personnes contrôlant
   le droit d'auteur sur ces documents, ce document ne peut pas être modifié
   en dehors du processus de normalisation de l'IETF, et les travaux dérivés de celui-ci peuvent
   ne pas être créé en dehors du processus de normalisation de l'IETF, sauf pour formater
   pour publication sous forme de RFC ou pour le traduire dans d'autres langues
   que l'anglais.

Table des matières

   1. Introduction ............................................... ..... 3
      1.1. Conventions utilisées dans ce document ................... 4
      1.2. Spécifications de JSON ..................................... 4
      1.3. Introduction à cette révision ........................... 4
   2. Grammaire JSON .............................................. ...... 4
   3. Valeurs ............................................... ........... 5
   4. Objets ............................................... .......... 6
   5. Tableaux ............................................... ........... 6
   6. Numéros ............................................... .......... 6
   7. Cordes ............................................... .......... 8
   8. Problèmes de chaîne et de caractère ..................................... 9
      8.1. Encodage des caractères ....................................... 9
      8.2. Caractères Unicode ......................................... 9
      8.3. Comparaison de chaînes ....................................... 9
   9. Analyseurs ............................................... .........dix
   10. Générateurs ............................................... .....dix
   11. Considérations IANA ........................................... 10
   12. Considérations de sécurité ....................................... 11
   13. Exemples ............................................... ....... 12
   14. Contributeurs ............................................... ... 13
   15. Références ............................................... ..... 13
      15.1. Références normatives ..................................... 13
      15.2. Références informatives ................................... 13
   Annexe A. Modifications de la RFC 4627 ................................. 15

1. Introduction

   La notation d'objet JavaScript (JSON) est un format de texte pour le
   sérialisation des données structurées. Il est dérivé de l'objet
   littéraux de JavaScript, tels que définis dans la programmation ECMAScript
   Language Standard, Third Edition [ECMA-262].

   JSON peut représenter quatre types primitifs (chaînes, nombres, booléens,
   et null) et 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 citation fait référence à la dernière version d'Unicode
   plutôt qu'une version spécifique. On ne s'attend pas à ce que l'avenir
   les changements dans la spécification UNICODE auront un impact sur la syntaxe de JSON.

   Un objet est une collection non ordonnée de zéro ou plusieurs nom / valeur
   paires, où un nom est une chaîne et une valeur est une chaîne, un nombre,
   booléen, null, objet ou 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 qu'il soit minimal, portable, textuel et
   un sous-ensemble de JavaScript.

1.1. Conventions utilisées dans ce document

   Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS",
   "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "MAI" et "FACULTATIF" dans ce
   document doivent être interprétés comme décrit dans [RFC2119].

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

1.2. Spécifications de JSON

   Ce document met à jour [RFC4627], qui décrit le JSON et les registres
   le type de support "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 c'est aussi
   décrit dans [ECMA-404].

   Toutes les spécifications de la syntaxe JSON s'accordent sur la syntaxe
   éléments de la langue.

1.3. Introduction à cette révision

   Dans les années qui ont suivi la publication de la RFC 4627, JSON a trouvé très
   large utilisation. Cette expérience a révélé certains schémas qui,
   bien qu'autorisé par ses spécifications, ont provoqué l'interopérabilité
   problèmes.

   En outre, un petit nombre d'errata ont été signalés (voir ID d'errata RFC
   607 [Err607] et 3607 [Err3607]).

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

2. Grammaire JSON

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

   Un texte JSON est une valeur sérialisée. Notez que certains précédents
   spécifications de JSON contraint un texte JSON à être un objet ou un

   tableau. Les implémentations qui génèrent uniquement des objets ou des tableaux où un
   Le texte JSON demandé sera interopérable dans le sens où tous
   les implémentations les accepteront comme des textes JSON conformes.

      JSON-text = valeur ws ws

   Ce sont les six caractères structurels:

      begin-array = ws% x5B ws; [crochet carré gauche

      begin-object = ws% x7B ws; {accolade gauche

      tableau final = ws% x5D ws; ] crochet carré droit

      objet final = ws% x7D ws; } accolade droite

      nom-séparateur = ws% x3A ws; : deux points

      séparateur de valeurs = ws% x2C ws; , virgule

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

      ws = * (
              % x20 /; Espace
              % x09 /; Onglet horizontal
              % x0A /; Saut de ligne ou Nouvelle ligne
              % x0D); Retour chariot

3. Valeurs

   Une valeur JSON DOIT être un objet, un tableau, un nombre ou une chaîne, ou l'un des
   les trois noms littéraux suivants:

      faux nul vrai

   Les noms littéraux DOIVENT être en minuscules. Aucun autre nom littéral n'est
   permis.

      valeur = faux / null / vrai / objet / tableau / nombre / chaîne

      faux =% x66.61.6c.73.65; faux

      null =% x6e.75.6c.6c; nul

      vrai =% x74.72.75.65; vrai

4. Objets

   Une structure d'objet est représentée par une paire de crochets
   entourant zéro ou plusieurs paires nom / valeur (ou membres). Un nom est un
   chaîne. Un seul deux-points vient après chaque nom, séparant le nom
   de la valeur. Une seule virgule sépare une valeur d'un suivant
   Nom. Les noms dans un objet DEVRAIENT être uniques.

      object = begin-object [membre * (membre séparateur de valeurs)]
               objet final

      membre = chaîne nom-séparateur valeur

   Un objet dont les noms sont tous uniques est interopérable dans le sens
   que toutes les implémentations logicielles recevant cet objet seront d'accord sur
   les mappages nom-valeur. Lorsque les noms d'un objet ne sont pas
   unique, le comportement du logiciel qui reçoit un tel objet est
   imprévisible. De nombreuses implémentations signalent la paire nom / valeur
   seulement. D'autres implémentations signalent une erreur ou ne parviennent pas à analyser le
   objet, et certaines implémentations signalent toutes les paires nom / valeur,
   y compris les doublons.

   On a observé que les bibliothèques d'analyse JSON diffèrent selon que
   ils ne rendent pas l'ordre des membres de l'objet visible à l'appel
   Logiciel. Implémentations dont le comportement ne dépend pas du membre
   la commande sera interopérable dans le sens où ils ne seront pas
   affectés par ces différences.

5. Tableaux

   Une structure matricielle est représentée par des crochets entourant zéro
   ou plusieurs valeurs (ou éléments). Les éléments sont séparés par des virgules.

   array = begin-array [value * (value-separator value)] end-array

   Il n'est pas nécessaire que les valeurs d'un tableau soient identiques
   type.

6. Numéros

   La représentation des nombres est similaire à celle utilisée dans la plupart des
   langages de programmation. Un nombre est représenté en base 10 en utilisant
   chiffres décimaux. Il contient un composant entier qui peut être
   précédé d'un signe moins facultatif, qui peut être suivi d'un
   une partie fraction et / ou une partie exposant. Les zéros non significatifs ne sont pas
   permis.

   Une partie fraction est un point décimal suivi d'un ou plusieurs chiffres.

   Une partie exposant commence par la lettre E en majuscule ou en minuscule,
   qui peut être suivi d'un signe plus ou moins. Le E et en option
   sont suivis d'un ou plusieurs chiffres.

   Valeurs numériques qui ne peuvent pas être représentées dans la grammaire ci-dessous (comme
   comme Infinity et NaN) ne sont pas autorisés.

      nombre = [moins] int [frac] [exp]

      point décimal =% x2E; .

      digit1-9 =% x31-39; 1-9

      e =% x65 /% x45; e E

      exp = e [moins / plus] 1 * CHIFFRE

      frac = virgule décimale 1 * CHIFFRE

      int = zéro / (digit1-9 * DIGIT)

      moins =% x2D; -

      plus =% x2B; +

      zéro =% x30; 0

   Cette spécification permet aux implémentations de fixer des limites sur la plage
   et précision des nombres acceptés. Depuis un logiciel qui implémente
   IEEE 754-2008 nombres binaires64 (double précision) [IEEE754] est
   généralement disponibles et largement utilisés, une bonne interopérabilité peut être
   atteint par des implémentations qui n'attendent plus de précision ou de portée
   que ceux-ci fournissent, dans le sens où les mises en œuvre
   nombres JSON approximatifs dans la précision attendue. UN JSON
   un nombre tel que 1E400 ou 3,141592653589793238462643383279 peut indiquer
   problèmes potentiels d’interopérabilité, car cela suggère que le
   logiciel qui l'a créé s'attend à recevoir un logiciel pour avoir une plus grande
   capacités d’amplitude numérique et de précision largement
   disponible.

   Notez que lorsque de tels logiciels sont utilisés, les nombres entiers et
   sont dans la plage [- (2 ** 53) +1, (2 ** 53) -1] sont interopérables dans le
   sens que les implémentations seront d'accord exactement sur leur numérique
   valeurs.

7. Cordes

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

   Tout caractère peut être échappé. Si le personnage est dans le Basic
   Plan multilingue (U + 0000 à U + FFFF), alors il peut être
   représenté comme une séquence de six caractères: un solidus inversé, suivi
   par la lettre minuscule u, suivie de quatre chiffres hexadécimaux qui
   encoder le point de code du caractère. Les lettres hexadécimales A bien
   F peut être en majuscule ou en minuscule. Ainsi, par exemple, une chaîne contenant
   un seul caractère solidus inversé peut être représenté comme
   "\ u005C".

   Alternativement, il existe une séquence d'échappement à deux caractères
   représentations de certains personnages populaires. Ainsi, par exemple, un
   une chaîne contenant un seul caractère solidus inversé peut être
   représenté de façon plus compacte par "\\".

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

      chaîne = guillemet * char guillemet

      char = non échappé /
          échapper (
              % x22 /; "guillemet U + 0022
              % x5C /; \ solidus inversé U + 005C
              % x2F /; / solidus U + 002F
              % x62 /; b retour arrière U + 0008
              % x66 /; f form feed U + 000C
              % x6E /; n saut de ligne U + 000A
              % x72 /; r retour chariot U + 000D
              % x74 /; t tab U + 0009
              % x75 4HEXDIG); uXXXX U + XXXX

      escape =% x5C; \

      guillemet =% x22; "

      non échappé =% x20-21 /% x23-5B /% x5D-10FFFF

8. Problèmes de chaîne et de caractère

8.1. Encodage de caractère

   Le texte JSON DOIT être codé en UTF-8, UTF-16 ou UTF-32. Le défaut
   le codage est UTF-8, et les textes JSON qui sont codés en UTF-8 sont
   interopérables dans le sens où ils seront lus avec succès par le
   nombre maximum d'implémentations; il existe de nombreuses implémentations
   qui ne peut pas lire avec succès des textes dans d'autres encodages (tels que
   UTF-16 et UTF-32).

   Les mises en œuvre NE DOIVENT PAS ajouter une marque d'ordre d'octets au début d'un
   Texte JSON. Dans l'intérêt de l'interopérabilité, les implémentations
   que l'analyse des textes JSON PEUT ignorer la présence d'une marque d'ordre d'octet
   plutôt que de le traiter comme une erreur.

8.2. Caractères Unicode

   Lorsque toutes les chaînes représentées dans un texte JSON sont entièrement composées
   de caractères Unicode [UNICODE] (mais échappé), puis que JSON
   le texte est interopérable dans le sens où toutes les implémentations logicielles
   cette analyse, il sera d'accord sur le contenu des noms et de la chaîne
   valeurs dans les objets et les tableaux.

   Cependant, l'ABNF dans cette spécification autorise les noms de membres et
   les valeurs de chaîne doivent contenir des séquences de bits qui ne peuvent pas coder Unicode
   personnages; par exemple, "\ uDEAD" (un seul UTF-16 non apparié
   substitut). Des exemples de cela ont été observés, par exemple, lorsque
   une bibliothèque tronque une chaîne UTF-16 sans vérifier si le
   la troncature a divisé une paire de substitution. Le comportement des logiciels
   reçoit des textes JSON contenant de telles valeurs est imprévisible; pour
   par exemple, les implémentations peuvent renvoyer des valeurs différentes pour la longueur
   d'une valeur de chaîne ou même subir des exceptions d'exécution fatales.

8.3. Comparaison de chaînes

   Les implémentations logicielles sont généralement nécessaires pour tester les noms de
   membres d'objet pour l'égalité. Les implémentations qui transforment
   représentation textuelle en séquences d'unités de code Unicode, puis
   effectuer la comparaison numériquement, unité de code par unité de code, sont
   interopérables dans le sens où les implémentations conviendront dans tous
   cas sur l'égalité ou l'inégalité de deux chaînes. Par exemple,
   implémentations qui comparent des chaînes avec des caractères d'échappement
   non converti peut incorrectement trouver que "a \\ b" et "a \ u005Cb" ne sont pas
   égal.

9. Analyseurs

   Un analyseur JSON transforme un texte JSON en une autre représentation. UNE
   L'analyseur JSON DOIT accepter tous les textes conformes à la grammaire JSON.
   Un analyseur JSON PEUT accepter des formulaires ou des extensions non JSON.

   Une mise en œuvre peut fixer des limites sur la taille des textes qu'elle
   accepte. Une mise en œuvre peut fixer des limites sur la profondeur maximale de
   nidification. Une mise en œuvre peut fixer des limites sur la portée et la précision
   de nombres. Une mise en œuvre peut fixer des limites sur la longueur et
   contenu des chaînes de caractères.

10. Générateurs

   Un générateur JSON produit du texte JSON. Le texte résultant DOIT
   strictement conforme à la grammaire JSON.

11. Considérations IANA

   Le type de média MIME pour le texte JSON est application / json.

   Nom du type: application

   Nom du sous-type: json

   Paramètres requis: n / a

   Paramètres facultatifs: n / a

   Considérations d'encodage: binaire

   Considérations de sécurité: Voir [RFC7159], Section 12.

   Considérations d'interopérabilité: décrites dans [RFC7159]

   Spécification publiée: [RFC7159]

   Applications utilisant ce type de média:
      JSON a été utilisé pour échanger des données entre des applications écrites
      dans tous ces langages de programmation: ActionScript, C, C #,
      Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript,
      Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala et
      Schème.

   Information additionnelle:
      Nombre (s) magique (s): n / a
      Extension (s) de fichier: .json
      Code (s) de type de fichier Macintosh: TEXTE

   Personne et adresse e-mail à contacter pour plus d'informations:
      IESG
      <iesg@ietf.org>

   Utilisation prévue: COMMUN

   Restrictions d'utilisation: aucune

   Auteur:
      Douglas Crockford
      <douglas@crockford.com>

   Changer de contrôleur:
      IESG
      <iesg@ietf.org>

   Remarque: Aucun paramètre "charset" n'est défini pour cet enregistrement.
      L'ajout d'un n'a vraiment aucun effet sur les destinataires conformes.

12. Considérations de sécurité

   Généralement, il existe des problèmes de sécurité avec les langages de script. JSON
   est un sous-ensemble de JavaScript mais exclut l'affectation et l'invocation.

   La syntaxe de JSON étant empruntée à JavaScript, il est possible de
   utilisez la fonction "eval ()" de cette langue pour analyser les textes JSON. Cette
   constitue généralement un risque inacceptable pour la sécurité, le texte
   pourrait contenir du code exécutable ainsi que des déclarations de données. Le même
   considération s’applique à l’utilisation de fonctions similaires à eval ()
   autre langage de programmation dans lequel les textes JSON sont conformes à celui
   syntaxe du langage.

13. Exemples

   Il s'agit d'un objet JSON:

      {
        "Image": {
            "Largeur": 800,
            "Hauteur": 600,
            "Titre": "Vue du 15e étage",
            "La vignette": {
                "Url": "http://www.example.com/image/481989943",
                "Hauteur": 125,
                "Largeur": 100
            },
            "Animé": faux,
            "ID": [116, 943, 234, 38793]
          }
      }

   Son membre Image est un objet dont le membre Thumbnail est un objet et
   dont le membre ID est un tableau de nombres.

   Il s'agit d'un tableau JSON contenant deux objets:

      [
        {
           "précision": "zip",
           "Latitude": 37,7668,
           "Longitude": -122.3959,
           "Adresse": "",
           "Ville": "SAN FRANCISCO",
           "État": "CA",
           "Zip": "94107",
           "Pays": "US"
        },
        {
           "précision": "zip",
           "Latitude": 37.371991,
           "Longitude": -122.026020,
           "Adresse": "",
           "Ville": "SUNNYVALE",
           "État": "CA",
           "Zip": "94085",
           "Pays": "US"
        }
      ]

   Voici trois petits textes JSON contenant uniquement des valeurs:

   "Bonjour le monde!"

42

   vrai

14. Contributeurs

   RFC 4627 a été écrit par Douglas Crockford. Ce document a été
   construit en apportant un nombre relativement faible de changements à celui
   document; ainsi, la grande majorité du texte ici est le sien.

15. Références

15.1. Références normatives

   [IEEE754] IEEE, "Norme IEEE pour l'arithmétique à virgule flottante", IEEE
              Standard 754, août 2008,
              <http://grouper.ieee.org/groups/754/>.

   [RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer
              Niveaux d'exigence ", BCP 14, RFC 2119, mars 1997.

   [RFC5234] Crocker, D. et P. Overell, "BNF augmenté pour la syntaxe
              Spécifications: ABNF ", STD 68, RFC 5234, janvier 2008.

   [UNICODE] The Unicode Consortium, "The Unicode Standard",
              <http://www.unicode.org/versions/latest/>.

15.2. Références informatives

   [ECMA-262] Ecma International, "Spécification du langage ECMAScript"
              Edition 5.1 ", Standard ECMA-262, juin 2011,
              <http://www.ecma-international.org/publications/standards/
              Ecma-262.htm>.

   [ECMA-404] Ecma International, "Le format d'échange de données JSON",
              Standard ECMA-404, octobre 2013,
              <http://www.ecma-international.org/publications/standards/
              Ecma-404.htm>.

   [Err3607] Errata RFC, ID errata 3607, RFC 3607,
              <http://www.rfc-editor.org>.

   [Err607] Errata RFC, ID errata 607, RFC 607,
              <http://www.rfc-editor.org>.

   [RFC4627] Crockford, D., "Le type de média application / json pour
              JavaScript Object Notation (JSON) ", RFC 4627, juillet 2006.

Annexe A. Modifications de la RFC 4627

   Cette section répertorie les modifications entre ce document et le texte dans RFC
   4627.

   o Modification du titre et de l'abrégé du document.

   o Modification de la référence à [UNICODE] pour ne pas être spécifique à la version.

   o Ajout d'une section "Spécifications de JSON".

   o Ajout d'une section "Introduction à cette révision".

   o Modification de la définition de "texte JSON" afin qu'il puisse s'agir de n'importe quel JSON
      , supprimant la contrainte qu'il s'agisse d'un objet ou d'un tableau.

   o Ajout d'un langage sur les noms de membres d'objet en double, membre
      commande et interopérabilité.

   o Clarifié l'absence d'une exigence que les valeurs dans un tableau soient
      du même type JSON.

   o Erratum appliqué # 607 de RFC 4627 pour aligner correctement l'illustration
      pour la définition de "objet".

   o Remplacé "sous forme de séquences de chiffres" par "dans la grammaire ci-dessous"
      Section "Numbers" et explicite la base-10-ness.

   o Ajout d'un langage sur l'interopérabilité des numéros en fonction de
      IEEE754 et a ajouté une référence IEEE754.

   o Ajout d'un langage sur l'interopérabilité et les caractères Unicode et
      sur les comparaisons de chaînes. Pour ce faire, tourné l'ancien "Encodage"
      dans une section "Problèmes de chaînes et de caractères", avec trois
      sous-sections: "Encodage de caractères", "Caractères Unicode" et
      "Comparaison de chaînes".

   o Modification des directives dans la section "Analyseurs" pour souligner que
      mises en œuvre peuvent fixer des limites sur la plage "et la précision" de
      Nombres.

   o Mise à jour et mise à jour de la section "Considérations IANA".

   o Création d'une véritable section «Considérations de sécurité» et levée du texte
      de la section précédente "Considérations IANA".

   o Erratum appliqué # 3607 de RFC 4627 en supprimant la sécurité
      considération qui commence "Un texte JSON peut être passé en toute sécurité" et
      le code JavaScript qui allait avec cette considération.

   o Ajout d'une note à la section «Considérations sur la sécurité» soulignant
      les risques d’utiliser la fonction "eval ()" en JavaScript ou tout autre
      autre langue dans laquelle les textes JSON sont conformes à cette langue
      syntaxe.

   o Ajout d'une note aux "Considérations IANA" clarifiant l'absence
      d'un paramètre "charset" pour le type de média application / json.

   o Changé "100" à 100 et ajouté un champ booléen, tous les deux dans le premier
      exemple.

   o Ajout d'exemples de textes JSON avec des valeurs simples, ni objets
      ni tableaux.

   o Ajout d'une section «Contributeurs» faisant référence à Douglas Crockford.

   o Ajout d'une référence à RFC 4627.

   o 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.

Adresse de l'auteur

   Tim Bray (éditeur)
   Google Inc.

   Courriel: tbray@textuality.com