Échapper / Désechapper JSON, gratuit

Comment ça marche

1. Collez votre chaîne : saisissez le texte à échapper, cela peut être du texte brut contenant des guillemets, des retours à la ligne, des barres obliques inverses ou tout autre caractère spécial.
2. Choisissez échapper ou désechapper : sélectionnez si vous voulez échapper du texte pour l'embarquer dans du JSON, ou désechapper une chaîne JSON vers du texte lisible.
3. Copiez le résultat : la sortie échappée ou désechappée apparaît instantanément. Copiez-la pour l'utiliser dans votre code ou vos données.

Pourquoi utiliser l'échappement JSON ?

Les chaînes JSON ont des règles d'échappement strictes, les guillemets doubles doivent devenir \", les retours à la ligne \n, les barres obliques inverses \\ et les tabulations \t. Ne pas échapper correctement ces caractères provoque des erreurs d'analyse JSON qui cassent les API, les fichiers de configuration et les pipelines de données. Cet outil gère automatiquement tout l'échappement et le désechappement, éliminant le chercher-remplacer manuel et évitant les bugs subtils dus à des séquences d'échappement manquées.

Fonctionnalités

• Couverture d'échappement complète : gère guillemets, barres obliques inverses, retours à la ligne, tabulations, retours chariot et séquences d'échappement Unicode.
• Bidirectionnel : à la fois échapper (texte → chaîne JSON) et désechapper (chaîne JSON → texte) dans un seul outil.
• Résultats instantanés : la sortie se met à jour à mesure que vous tapez, sans délai.
• Copier dans le presse-papiers : copie en un clic du résultat échappé ou désechappé.
• Confidentialité avant tout : tout le traitement se fait localement, les chaînes sensibles ne quittent jamais votre appareil.

Questions fréquentes

Quels caractères l'échappement JSON gère-t-il ?

JSON exige l'échappement de : guillemets doubles ("), barre oblique inverse (\), barre oblique (/), retour à la ligne (\n), retour chariot (\r), tabulation (\t), saut de page (\f), retour arrière (\b) et caractères Unicode au-dessus de U+FFFF. Cet outil les gère tous.

Pourquoi mon erreur d'analyse JSON est-elle due à l'échappement ?

Les causes courantes incluent les guillemets doubles non échappés à l'intérieur d'une valeur de chaîne, les retours à la ligne littéraux dans une chaîne (doivent être \n) et les barres obliques inverses non échappées. Collez votre chaîne cassée ici pour l'échapper correctement.

Cela inclut-il les guillemets entourants ?

Par défaut, l'outil échappe le contenu sans englober de guillemets, afin que vous puissiez coller le résultat dans votre chaîne JSON. Activez l'option « Inclure les guillemets » si vous voulez que la sortie soit entourée de guillemets doubles.

La spec JSON String, en un tableau

RFC 8259 (décembre 2017, par Tim Bray) est le standard JSON actuel, remplaçant RFC 7159 et l'original RFC 4627. La section 7 de la spec liste exactement quels caractères DOIVENT être échappés dans une chaîne littérale :

Des règles équivalentes sont dans ECMA-404 (2e édition, décembre 2017), maintenu en synchronisation avec la spec IETF. JSON n'a pas d'échappements octaux (\012) ou hexadécimaux (\x41), ceux-là sont JavaScript uniquement ; JSON ne supporte que les huit échappements nommés ci-dessus plus \uXXXX.

L'échappement \uXXXX et le piège des paires de substitution

Les séquences \uXXXX de JSON encodent des unités de code UTF-16, pas des points de code Unicode. C'est important pour les emoji et les caractères du plan supplémentaire. Un seul emoji comme 😀 (U+1F600) ne s'échappe pas en \u1F600 (ce n'est même pas une forme légale à quatre chiffres hexadécimaux), mais en une paire de substitution : \uD83D\uDE00, deux échappements consécutifs encodant les substitutions haute et basse. La plage de substitution haute est U+D800–U+DBFF ; la basse est U+DC00–U+DFFF ; ensemble elles couvrent U+10000 à U+10FFFF (les plans supplémentaires).

C'est la source la plus courante de bugs d'échappement d'emoji. La section 7 de la RFC 8259 dit explicitement : « 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 la paire de substitution UTF-16. » Un emoji famille de quatre comme 👨‍👩‍👧‍👦, qui est techniquement quatre emoji de base plus trois joints de largeur zéro, s'échappe en 30+ caractères dans une chaîne JSON. Le compte d'octets gonfle en conséquence : 25 octets UTF-8 brut, ~58 octets après échappement JSON.

JSON à l'intérieur de HTML, URL, SQL et CSV

L'échappement JSON seul ne suffit pas quand le JSON est intégré dans un autre format. Chaque contexte ajoute sa propre couche.

JSON à l'intérieur de HTML. Le piège classique est <script>const data = {{ payload | json }};</script> quand le payload contient la sous-chaîne littérale </script>. Le parseur HTML ferme la balise script en plein milieu de la chaîne et le reste du JSON s'affiche en texte visible sur la page. La solution est l'échappement optionnel \/ : <\/script> est JSON-valide et HTML-safe. La fiche de cross-site scripting d'OWASP recommande de toujours échapper <, >, & et ' dans le JSON destiné à l'embedding HTML.

JSON à l'intérieur d'une chaîne de requête URL. Deux couches : d'abord l'échappement JSON, puis le percent-encoding. {"name":"Bob"} devient %7B%22name%22%3A%22Bob%22%7D. Oublier le percent-encoding est la cause n°1 des bugs JSON-dans-URL malformés.

JSON à l'intérieur de SQL. Stocké dans une colonne PostgreSQL jsonb, la valeur est parsée nativement, pas d'échappement supplémentaire nécessaire. Mais le JSON intégré dans un littéral SQL (INSERT INTO t (data) VALUES ('{"key":"value"}')) nécessite l'échappement de chaîne SQL par-dessus JSON : les apostrophes doublées (''), ou mieux, utilisez des requêtes paramétrées.

JSON à l'intérieur des cellules CSV. Les guillemets CSV diffèrent de JSON (CSV utilise les guillemets doublés "", pas les séquences avec antislash). Intégrer JSON dans une cellule CSV nécessite les deux couches : échapper la chaîne JSON, puis échapper-CSV le résultat (envelopper dans "...", doubler tout " interne).

API d'exécution dans plusieurs langages

D'où vient JSON, et ce que Crockford a laissé de côté

JSON a d'abord été formalisé par Douglas Crockford en 2001 chez State Software, à l'origine pour sérialiser des objets JavaScript pour l'échange asynchrone de données. La première mention publique était sur le site JSON.org en 2003. Crockford l'a spécifié formellement comme RFC 4627 en juillet 2006, en partie pour contrer une tentative de brevet concurrente à peu près à la même époque. Le standard est passé au statut STD 90 avec RFC 8259 en décembre 2017.

La plus grande décision de design de JSON était d'en faire un sous-ensemble de JavaScript, afin que tout document JSON puisse être eval'd dans un interpréteur JS et donner la bonne valeur. Cela a rendu l'adoption dans le navigateur sans friction mais a verrouillé certaines particularités JS de façon permanente : pas de type entier (tous les nombres sont des doubles IEEE 754), pas de type date, pas de NaN ni d'infini. Les grands entiers au-dessus de 2⁵³−1 nécessitent une sérialisation en chaîne ("id": "9007199254740993") pour éviter une perte silencieuse de précision.

Crockford a délibérément laissé de côté des choses qui peuvent vous manquer : commentaires (« J'ai retiré les commentaires de JSON parce que je voyais les gens les utiliser pour contenir des directives de parsing, une pratique qui aurait détruit l'interopérabilité », mai 2012), virgules de fin, et langage de schéma (ajouté plus tard sous le nom de JSON Schema, maintenu séparément, brouillon actuel 2020-12). La variante communautaire JSON5 restaure les commentaires et les virgules de fin mais n'est pas RFC-conforme ; elle est utilisée principalement dans les fichiers de config (.babelrc, .swcrc) que les humains éditent.

Cas d'usage courants

• Intégrer des données dans des attributs HTML, coller une chaîne avec ", <, >, obtenir une forme sûre pour les attributs data-* ou les balises script inline.
• Composer manuellement des corps de requête API, quand on curle un endpoint et que le payload contient des guillemets ou des sauts de ligne.
• Construire des payloads de lignes de log où le message doit survivre au quotage shell plus le parsing JSON de l'autre côté.
• Migrer des données legacy de CSV / XML / TSV vers JSON, passe manuelle d'échappement des guillemets.
• Déboguer les réponses serveur où la valeur contient des séquences \u, dé-échapper pour voir ce que c'est vraiment.
• Écrire des tests, coller la sortie JSON attendue et l'échapper pour l'inclure dans une assertion de test.
• Moteurs de templating (Jinja2, Nunjucks, Liquid, ERB) qui intègrent JSON dans JavaScript ou HTML.

Erreurs courantes

1. Utiliser des échappements JavaScript qui ne sont pas JSON-valides. \x41 pour « A » et \012 pour saut de ligne sont valides dans les littéraux de chaîne JS mais invalides en JSON. JSON n'autorise que les huit échappements nommés plus \uXXXX.
2. Utiliser des apostrophes pour les chaînes JSON. 'hello' fonctionne en JavaScript mais est JSON invalide. Les chaînes JSON DOIVENT utiliser des guillemets doubles.
3. Clés d'objet sans guillemets. {name: "Bob"} fonctionne en JavaScript mais est JSON invalide. Les clés DOIVENT être des littéraux de chaîne entre guillemets doubles.
4. Virgules de fin. [1,2,3,] fonctionne en JS mais est JSON invalide. RFC 8259 les interdit explicitement.
5. Commentaires en ligne. // foo et /* foo */ sont invalides en JSON standard. Utilisez JSON5 si vous avez besoin de commentaires ; attendez-vous à ce que tous les parseurs ne l'acceptent pas.
6. Échapper manuellement un emoji comme un seul \uXXXX. Les emoji au-dessus de U+FFFF nécessitent une paire de substitution UTF-16, deux \uXXXX consécutifs.

Autres questions fréquemment posées

Dois-je toujours échapper la barre oblique / ?

Non, la barre oblique / est autorisée non échappée en JSON ; l'échappement \/ est optionnel. L'exception est quand JSON est intégré dans une balise HTML <script> : échapper / en \/ empêche la sous-chaîne littérale </script> de fermer la balise prématurément. Certains encodeurs (JSON_HEX_TAG en PHP, remplacements JS personnalisés) le font ; la plupart non.

Pourquoi JSON.stringify échappe-t-il mes caractères non-ASCII ?

Il ne le fait pas, par défaut. JSON.stringify("café") en JavaScript produit "café" avec le littéral é. Ce que vous voyez peut-être est une bibliothèque différente : json.dumps de Python a par défaut ensure_ascii=True et échappe tout en dehors de ASCII en \uXXXX ; json_encode de PHP se comporte de la même façon à moins que vous ne passiez JSON_UNESCAPED_UNICODE. Les deux comportements sont JSON valide, mais la taille du fichier et la lisibilité diffèrent.

JSON peut-il stocker des données binaires ?

Pas directement. Les chaînes JSON sont des séquences de caractères Unicode, pas des octets. La solution de contournement standard est d'encoder Base64 le binaire d'abord, puis de stocker la chaîne ASCII résultante comme une valeur JSON normale. Les données encodées sont ~33% plus grandes que les octets bruts. Pour les très gros binaires, utilisez un format binaire comme BSON, MessagePack ou CBOR, ou stockez les octets séparément et référencez-les par URL.

Pourquoi certains outils affichent-ils \u00e9 au lieu de é ?

Les deux sont JSON valides pour le même caractère. "caf\u00e9" et "café" décodent en chaînes identiques. Certains encodeurs échappent le non-ASCII pour une sécurité cross-encodage maximale (la sortie est ASCII pur donc l'encodage du consommateur n'a pas d'importance), d'autres préservent l'UTF-8 original pour la lisibilité. Choisissez en fonction de ce qui consomme votre JSON.

Mon texte est-il téléversé quelque part ?

Non. L'outil utilise les API natives JSON.stringify et JSON.parse du navigateur entièrement côté client. Il n'y a aucun appel réseau, aucune analytique, aucune journalisation. Sûr pour échapper des jetons API, des données internes, ou tout ce que vous ne colleriez pas dans un outil d'échappement côté serveur.