JSON Repair

Le JSON malformé est un texte qui ressemble à du JSON mais qui viole la spécification stricte de la syntaxe JSON — par exemple des clés sans guillemets, des guillemets simples au lieu de doubles, des virgules superflues, des crochets manquants ou des commentaires. Les parseurs stricts comme JSON.parse le rejettent, mais un outil de réparation peut généralement le corriger automatiquement.

Oui. La sortie des LLM est l'une des sources les plus courantes de JSON cassé. L'outil gère les clés sans guillemets, les guillemets simples, les virgules superflues, les crochets manquants, le texte en prose autour du JSON et les réponses tronquées (interrompues).

Non. L'algorithme de réparation s'exécute entièrement dans votre navigateur. Votre JSON ne quitte jamais votre appareil, ce qui rend l'outil sûr pour les logs confidentiels, les payloads API et les données clients.

Un JSON Formatter ne fonctionne que sur du JSON déjà valide — il formate et valide. JSON Repair va un cran plus loin : il corrige d'abord le JSON invalide (guillemets, virgules, crochets, troncature), puis produit un JSON propre et formaté. Utilisez le formateur pour une entrée valide et l'outil de réparation pour une entrée cassée.

Dans la plupart des cas, oui. Le JSON tronqué (par exemple un objet interrompu en pleine valeur par une limite de tokens) est réparé en fermant les chaînes, les tableaux et les objets ouverts. Les données jamais transmises ne peuvent pas être récupérées, mais la structure redevient valide.

Fautes courantes récupérables : virgules finales (trailing commas), guillemets simples au lieu de guillemets doubles, clés sans guillemets, littéraux True/False/None à la manière de Python, sauts de ligne non échappés dans les chaînes et commentaires. Le moteur de réparation les réécrit en JSON strict conforme à la RFC 8259 et indique précisément quelles corrections ont été appliquées.

Chaque réparation préserve la sémantique dans la mesure du possible - les commentaires sont supprimés (JSON n'a pas de syntaxe de commentaires) et le style de guillemets est normalisé, mais les valeurs, la structure et l'ordre sont conservés à l'octet près en termes de sens. La vue diff affiche chaque transformation afin que vous puissiez vérifier qu'aucun changement inattendu ne s'est produit avant d'utiliser la sortie.

Les trois principales sources sont les sorties de LLM (les modèles émettent des guillemets simples, des virgules finales et des clés sans guillemets malgré les instructions), les fichiers de configuration modifiés à la main et les journaux d'API tronqués. Réparer avant de parser permet aux pipelines de continuer au lieu de faire échouer un lot entier à cause d'un seul enregistrement mal formé.