Comment convertir JSON en littéraux d'objets JavaScript et vice versa

Chaque document JSON est déjà une expression JavaScript valide. Vous pouvez coller du JSON dans une assignation const config = et ça s'exécute. Le travail intéressant est l'inverse : les vrais littéraux d'objets JavaScript sont pleins de choses que JSON interdit, et un convertisseur qui devine ce qu'ils voulaient perd des données tout en signalant du succès.

Utilisation du convertisseur JSON vers JavaScript

Choisissez une direction et appuyez sur Convertir. En écrivant du JavaScript, une clé d'objet qui est un identifiant valide est écrite sans guillemets, donc "name" devient name, tandis qu'une clé comme "display name" reste avec guillemets car l'écrire sans guillemets changerait son orthographe. Un objet ou tableau vide reste sur une seule ligne. Les nombres traversent le flux de tokens plutôt que JSON.parse, donc un entier de vingt chiffres revient avec les vingt chiffres exacts.

Ce que le lecteur accepte

En relisant du JavaScript en JSON, l'outil comprend les littéraux d'objets que vous colleriez réellement depuis un fichier de configuration : clés non quotées, chaînes entre apostrophes, commentaires // et /* */, virgules de fin, et un nom const, let ou var optionnel en début avec un point-virgule à la fin. Un littéral de template sans interpolation est également accepté, car il contient du texte brut.

Un orthographe de nombre que JSON rejette est normalisée à sa forme JSON exacte :

const numbers = { a: .5, b: 5., c: 5.e3 }

{
  "a": 0.5,
  "b": 5,
  "c": 5e3
}

Ce qui est refusé, et pourquoi

Tout ce que JSON ne peut pas contenir est refusé par nom plutôt que deviné. undefined, NaN et Infinity n'ont pas de nombre ou de valeur JSON, donc ils sont refusés. Il en va de même pour les nombres hexadécimaux, octaux et binaires, les séparateurs de chiffres par tiret bas comme 1_000, et un zéro initial, tous ceux qui changeraient de signification si JSON les lisait. Une expression régulière, une fonction, un mot nu, et l'interpolation de template ${...} sont également refusés, car ce sont du code, pas des données.

Deux refus méritent un regard plus attentif. Une clé qui apparaît deux fois dans un objet est refusée, car JSON n'a aucun moyen de contenir les deux valeurs sous un seul nom. Et une clé __proto__ dont la valeur est un objet ou null est refusée, car dans un littéral d'objet JavaScript cette orthographe ne crée pas une propriété. Elle définit le prototype du nouvel objet, donc la convertir en JSON avec une clé __proto__ ordinaire inventerait une propriété que le code original n'a jamais eue.

Pourquoi undefined n'est pas transformé en null par défaut

JSON n'a pas de undefined, donc un convertisseur doit faire quelque chose. Écrire null change silencieusement ce que les données signifiaient : un undefined dans un objet de configuration signifie généralement qu'un champ n'est pas encore configuré, ce qui n'est pas la même chose qu'un null que le code vérifie plus tard. L'outil refuse par défaut, et l'option Convertir undefined to null existe pour quand vous voulez vraiment cette signification.

Voyage aller-retour

Convertir un document dans l'autre format est le vrai test de si les règles de guillemets et de refus sont correctes. Un littéral d'objets avec des clés non quotées, des apostrophes et une virgule de fin revient en JSON avec chaque clé guillemetée et chaque chiffre intact, et convertir ce JSON de nouveau retourne le même objet. Une mauvaise règle ne se montre généralement que quand vous reconvertissez et comparez.