JSON Toolkit

Un BOM casse-t-il le parsing JSON

L’essentiel : Un BOM UTF-8 est trois octets invisibles, donc JSON.parse échoue au premier caractère et rapporte ligne 1 colonne 1, ce qui fait paraître le fichier vide ou tronqué.

Débutant~4 min de lecturePublié le 2026-10-30Mis à jour le 2026-10-30
Comment un BOM casse le parsing JSON et comment le supprimer

L'essentiel : vérifiez les trois premiers octets pour EF BB BF et réenregistrez en UTF-8 sans BOM ; côté serveur, retirez un U+FEFF initial avant de parser tout fichier téléversé ou tiers au lieu de déboguer l'échec plus tard.

Oui — et cela produit la plus déroutante de toutes les erreurs de parsing, parce que le fichier semble parfaitement correct.

Ce que vous voyez

SyntaxError: Unexpected token  in JSON at position 0
Unexpected character '\uFEFF'

Ce caractère dans le message est invisible. La position 0 signifie le tout premier octet.

cat ne montre rien d'inhabituel. hexdump -C file.json | head -1 oui :

00000000  ef bb bf 7b 0a 20 20 22  61 22 3a 20 31 0a 7d 0a  |...{  "a": 1.}.|

7b est {. Les trois octets avant lui sont le BOM.

D'où viennent les BOM

Le byte order mark existait pour UTF-16, où l'ordre des octets variait réellement. UTF-8 a un seul ordre d'octets, donc le BOM est une pure surcharge — et pourtant le Bloc-notes Windows, certains exports Excel et quelques IDE plus anciens l'écrivent encore par défaut.

La RFC 8259 est sans ambiguïté : le JSON échangé entre systèmes doit être en UTF-8, et les implémentations ne doivent pas ajouter de BOM. Les parseurs peuvent ignorer un BOM initial mais n'y sont pas obligés. Les navigateurs et Node choisissent de ne pas le faire.

Trois façons de s'en débarrasser

Enregistrez sans BOM. Dans VS Code, cliquez sur l'encodage dans la barre d'état et choisissez « Save with Encoding → UTF-8 », pas « UTF-8 with BOM ».

Retirez-le depuis le shell.

sed -i '1s/^\xEF\xBB\xBF//' data.json

Retirez-le à la lecture. C'est la correction durable pour tout ce qui accepte des fichiers téléversés ou tiers :

const text = require('node:fs').readFileSync('data.json', 'utf8').replace(/^\uFEFF/, '');
JSON.parse(text);

En Python, open(path, encoding='utf-8-sig') le gère automatiquement.

Deux problèmes qui ressemblent

  • Espace de largeur nulle (U+200B) — récupéré en copiant du JSON depuis une page web ; symptôme identique, point de code différent.
  • Guillemets pleine largeur — un IME chinois transforme "key" en “key”, qui semble presque identique mais échoue comme Unexpected token “.

Les trois sont des bugs de caractères invisibles. Le diagnostic est toujours le même : videz les premiers octets en hexadécimal plutôt que de fixer le texte.

FAQ

Comment savoir si un fichier commence par un BOM ?

cat ne montre rien, donc lancez hexdump -C file.json | head -1. Si la sortie commence par ef bb bf, le fichier a un BOM ; 7b (le {) devrait venir en premier dans un fichier UTF-8 propre.

Pourquoi l'erreur pointe-t-elle toujours ligne 1, colonne 1 ?

Le BOM se trouve avant tout le reste, donc le premier caractère que lit le parseur est U+FEFF. L'échec atterrit donc au début du fichier, ce qui fait paraître le fichier vide.

Faut-il retirer le BOM avant le parsing ?

Oui. Quand un serveur lit de la configuration ou parse des fichiers téléversés, retirez d'abord un U+FEFF initial — replace(/^\uFEFF/, '') dans Node, encoding='utf-8-sig' en Python — ce qui est bien moins coûteux que de le diagnostiquer plus tard.

Lectures complémentaires