Recherche des messages d'erreur JSON : du texte d'erreur à la correction

L'essentiel : lorsqu'une erreur de JSON.parse apparaît, saisissez d'abord la position et le token ; une position 0 impose de vérifier une réponse HTML, un BOM ou un mauvais type, et un message « Expected » impose de regarder le caractère précédent — ne relisez pas ligne par ligne depuis la position indiquée.

Le texte d'erreur n'est pas du bruit — c'est la réponse. L'analyseur vous dit quel caractère il a rencontré, ce qu'il attendait et ce qu'il a réellement reçu. Chercher par le message d'erreur vaut mieux que réécrire tout le document à la main.

Chaque erreur de JSON.parse() comporte trois parties : la position (un décalage de caractère, ou ligne/colonne), l'attente (Expected...) et la réalité (Unexpected token X, ou xxx is not valid JSON). Les moteurs les formulent différemment — Chrome et Node (V8) disent Expected ',' or '}' after property value in JSON at position 25, Firefox dit JSON.parse: expected ',' or '}' after property value in object at line 3 column 1, Safari dit JSON Parse error: Expected ',' or '}' — mais tous trois pointent la même rupture de syntaxe. Lorsque vous recherchez une erreur, ignorez la formulation et retenez les trois faits : quel caractère, ce qui était attendu, ce qui est arrivé.

1. La table de recherche des 12 erreurs

La colonne de gauche est le fragment le plus identifiable de votre console (formulation V8). Les variantes Firefox/Safari sont entre parenthèses.

Les deux premières méritent un examen plus attentif, car aucune ne signifie « votre JSON est faux » — elles signifient « ce que vous recevez n'est pas ce que vous croyez ».

2. Trois sources courantes d'une erreur en position 0

Une position 0 signifie que le tout premier caractère est illégal. Si rien ne paraît suspect, le caractère est probablement invisible. Trois suspects habituels :

Un : <, donc du HTML. C'est l'erreur d'analyse la plus courante en production. Une URL erronée, une session expirée redirigée par la passerelle, ou un modèle d'erreur serveur — le corps commence par <!DOCTYPE html> et l'analyseur abandonne dès le premier caractère. Le bon réflexe est d'ouvrir le panneau Network et de lire la réponse brute, puis de corriger l'appel d'API, pas le JSON.

Deux : un BOM ou des caractères de largeur nulle. Les fichiers enregistrés par le Bloc-notes de Windows commencent souvent par un BOM UTF-8 (\uFEFF), et un texte copié depuis des pages web ou des messageries peut porter des espaces de largeur nulle (\u200B–\u200D). Invisibles pour vous, évidents pour l'analyseur :

复制// Strip BOM and zero-width characters before parsing
const cleaned = raw.replace(/^\uFEFF/, '').replace(/[\u200B-\u200D]/g, '');
const data = JSON.parse(cleaned);

Trois : le mauvais type. JSON.parse(undefined) signale "undefined" is not valid JSON ; JSON.parse(someObject) signale Unexpected token o (l'objet a été converti en "[object Object]", et o est illégal en position 1). Les deux signifient « la donnée est déjà analysée » ou « il n'y a jamais eu de donnée ». Vérifiez le type, pas la syntaxe :

复制let data = text;
if (typeof data === 'string') {
  data = JSON.parse(data); // Parse only when it really is a string
}

3. La position pointe en aval ; la cause est en amont

Deux erreurs vous induisent en erreur sur l'emplacement, et ce sont les deux entrées les plus mal comprises du tableau :

• Une virgule manquante : {"a": 1 "b": 2} signale Expected ',' or '}' after property value à la ligne de "b". Le signalement est correct, mais la correction se fait à la fin de la ligne précédente.
• Un crochet fermant manquant : une imbrication profonde à laquelle il manque un } ou un ] pousse l'analyseur à avaler tout jusqu'à la fin de l'entrée et à signaler Unexpected end of JSON input. La position est la fin du fichier ; la vraie lacune peut être bien plus haut. Cherchez en arrière le { ou [ non fermé le plus récent — compter les paires vaut mieux que l'œil.

La technique générale est la bissection : coupez le texte avant la position signalée et analysez-le seul. S'il s'analyse, le problème est proche de la position signalée ; sinon, bissectez plus en arrière. La frontière du premier tronçon en échec est le véritable emplacement de l'erreur. Pour les gros fichiers, formatez d'abord le document — avec une indentation alignée, le niveau manquant se voit d'un coup d'œil (le formateur JSON en ligne fait très bien l'affaire).

4. Quatre « faux états sains » qui s'analysent bien mais se comportent mal

Pire qu'une erreur : aucune erreur et des données fausses. Dans les quatre cas, le JSON est valide et l'analyseur est content — le problème est la forme des données :

1. Double encodage : tout le document a été passé deux fois à JSON.stringify, si bien que l'analyse produit une chaîne, pas un objet. Si typeof result === 'string', analysez à nouveau — mais trouvez et corrigez la double sérialisation à la source.
2. Les clés dupliquées écrasent sans bruit : {"name": "Tom", "name": "Jerry"} est du JSON valide, la plupart des analyseurs ne se plaignent pas, et la seconde valeur l'emporte. Cela mord au moment de fusionner des données de plusieurs sources ; révélez-le avec un validateur JSON strict avant d'être mordu.
3. NDJSON traité comme un seul document : les API en flux émettent un objet par ligne ; analyser tout le texte échoue avec Unexpected non-whitespace character after JSON. Découpez sur \n et analysez ligne par ligne.
4. Perte silencieuse de précision des nombres : les entiers au-delà de 2^53 - 1 (identifiants snowflake) reviennent avec les derniers chiffres mis à zéro, sans aucune erreur. Transmettez les identifiants sous forme de chaînes.

Le fil conducteur : l'analyseur croit que tout va bien. Donc lorsque les données d'API semblent fausses, affichez d'abord les 80 premiers caractères du texte brut et son typeof — confirmez la forme avant de discuter du contenu.

5. Rendre les erreurs impossibles à l'écriture

La table de recherche est l'outil d'après coup ; la prévention est l'outil d'avant coup. Quatre habitudes interceptent la plupart des erreurs avant qu'elles n'arrivent :

复制// 1. Two checks before parsing any response
const response = await fetch('/api/users');
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: the API returned no data`);
}
const contentType = response.headers.get('content-type') ?? '';
if (!contentType.includes('application/json')) {
  throw new Error(`Expected JSON, got ${contentType}`);
}
const data = await response.json(); // 2. json() already parses — do not parse again

• Sérialiser pour générer, jamais concaténer : JSON.stringify() gère correctement les guillemets, les sauts de ligne et les caractères de contrôle ; les chaînes construites à la main sont la première source de Bad control character et de Unterminated string.
• Toujours attraper : une erreur de JSON.parse lancée est un plantage synchrone à moins que quelque chose ne l'attrape. Pour les entrées non fiables — localStorage, fichiers externes — le bloc catch a besoin d'une valeur par défaut ou d'un signalement d'erreur explicite.
• Déléguer la structure au Schema : une syntaxe valide ne signifie pas une structure valide. Les champs manquants et les mauvais types relèvent de la validation JSON Schema à la frontière ; voir ce que résout JSON Schema.

6. Le chemin de décision rapide

Résumez tout l'article en un seul ordre de décision. Face à une erreur, saisissez d'abord la position et le token :

1. Position 0 → vérifiez les trois sources : < (HTML), BOM, mauvais type ;
2. end of input → vérifiez un corps vide ou tronqué, puis cherchez en arrière les crochets non fermés ;
3. Expected ... → regardez le caractère précédent ; c'est généralement une virgule ou un guillemet manquant ;
4. after JSON data → plusieurs documents ont été concaténés ; découpez par ligne ;
5. S'analyse bien mais les données semblent fausses → lancez les quatre vérifications de « faux état sain ».

Combiné au triage pas à pas de comment corriger les erreurs d'analyse JSON, 90 % des problèmes d'analyse se résolvent en cinq minutes. Gardez le texte d'erreur lui-même en favori — c'est le journal de débogage que l'analyseur a écrit pour vous, sa formulation change tous les trois ans, et une seule recherche rentabilise une année.

Que signifie « Unexpected token in JSON » ?

L'analyseur a rencontré un caractère illégal à cet endroit de la grammaire JSON. Le token est le caractère rejeté : < signifie généralement que l'API a renvoyé du HTML, ' des guillemets simples, / un commentaire, et une simple lettre généralement une clé non citée ou un littéral réservé à JavaScript comme undefined ou NaN. Lisez d'abord le token, puis la position, et la cause se réduit à une seule.

Comment corriger « Unexpected end of JSON input » ?

Deux sources : une entrée vide (corps de réponse vide, ou chaîne vide dans localStorage) ou une entrée tronquée (téléchargement interrompu, copie privée de la dernière ligne, limite de taille). Traitez le cas vide avec if (!text) return ; puis vérifiez la complétude et fermez le {, [ ou " non fermé le plus récent. Notez que l'erreur peut aussi venir d'un crochet profondément manquant — la position tombe simplement à la fin du fichier.

Pourquoi Chrome, Firefox et Safari signalent-ils les erreurs différemment ?

Les trois navigateurs embarquent des moteurs JS différents (V8, SpiderMonkey, JavaScriptCore), et chacun formule ses erreurs à sa manière ; MDN documente toutes les variantes officielles. Mais les trois erreurs portent les trois mêmes éléments — position, attente, réalité — avec une sémantique biunivoque. Traduisez vers la formulation V8 et utilisez cette table telle quelle.

La position d'erreur pointe un endroit qui semble correct — que faire ?

La vraie erreur est plus haut. Cas typiques : une virgule manquante (signalée sur la ligne suivante) et un crochet fermant manquant (signalé en fin de fichier). Remontez depuis la position signalée token par token, ou bissectez : analysez la première moitié seule, et la frontière du premier tronçon en échec est le véritable emplacement de l'erreur.