Jak opravit chyby parsování JSON: postupné ověřování Unexpected token

Stručně: při chybě parsování si přečtěte hlášený řádek a sloupec, najděte první neplatný znak a poté rozhodněte, zda chybí uvozovka, chybí čárka, jde o koncovou čárku, BOM nebo zkrácení – neprocházejte znovu celý dokument od začátku.

Chybová zpráva vám nikdy neřekne „co je špatně“; řekne pouze „kde parser nemohl pokračovat“. Tyto dvě pozice často nejsou na stejném místě.

1. Nejprve převeďte chybu na souřadnice

Stejný rozbitý JSON produkuje v různých jazycích zcela odlišné chyby, ale všechny je lze převést na „který řádek, který znak“:

Jakmile máte pozici, vložte JSON do online parseru JSON; nástroj umístí kurzor na místo chyby a zvýrazní číslo řádku a sloupce – tento krok ušetří 90 % ručního prohlížení znaků.

2. Šest častých chyb

1. Koncová čárka

复制{
  "name": "json",
  "version": 1,
}

Před } je čárka navíc. Specifikace JSON koncové čárky nepovoluje, zatímco objektové literály v JavaScriptu ano, takže konfigurace zkopírovaná z kódu ji nejspíš ponese. Oprava: smažte poslední čárku; pokud tato data pocházejí ze souboru JS, přejděte raději na převod JSON5, než abyste je nutili do JSON.

2. Jednoduché uvozovky a klíče bez uvozovek

复制{ 'name': 'json' }
{ name: "json" }

Řetězce v JSON smějí používat pouze dvojité uvozovky a klíče musí být také řetězce v dvojitých uvozovkách. Tyto dva příklady jsou uvolněná syntaxe JSON5 / JavaScriptu, nikoli JSON. Dvojitá uvozovka uvnitř řetězce se musí zapsat jako \" a zpětné lomítko jako \\.

3. Komentáře

复制{
  // Časový limit v milisekundách
  "timeout": 3000
}

Gramatika RFC 8259 pro komentáře nemá místo. Buď komentáře smažte, nebo soubor uložte jako .jsonc / .json5 a použijte parser, který komentáře podporuje. Kompromisům mezi různými „schématy pro komentáře“ se věnuje Jak psát komentáře v JSON.

4. Neescapované zalomení řádku a řídicí znaky uvnitř řetězců

复制{"sql": "SELECT *
FROM t"}

Řetězce JSON nesmějí obsahovat neescapované posuny řádku, tabulátory ani řídicí znaky U+0000–U+001F; musí se zapsat jako \n, \t, \u0009. Když do JSON vkládáte víceřádkový text, nejprve ho v editoru escapeujte, nebo jej jednotně zpracujte pomocí minifikace a escapování JSON.

5. Hlavička BOM

UTF-8 uložený Poznámkovým blokem ve Windows nese tři bajty EF BB BF. JSON.parse při setkání s BOM ohlásí Unexpected token a oko ho vůbec nevidí. Jak to zjistit: prohlédněte hlavičku souboru v hexadecimálním zobrazení, nebo obsah zkopírujte do online nástroje a podívejte se, zda se první znak zobrazuje jako . Oprava: uložte jako „UTF-8 bez BOM“.

6. Zkrácený obsah

Log, který vypsal jen prvních 4096 znaků, odpověď API uříznutá bránou, přerušené stahování – poznávacím znamením této třídy je „chyba je na konci“ a nesouhlasící počty závorek. Nejprve spočítejte závorky: pokud se počty uzavření { a [ neshodují, jde o zkrácení, nikoli syntaktickou chybu. V tom případě nic neopravujte – jděte a získejte úplná data.

3. Dva plané poplachy s čínským textem a escapováním

Čínský text se změní na \u4e2d\u6587: jde o platné escapování JSON, nikoli o rozsypaný text. Po parsování se hodnota obnoví do čínštiny; forma \u se zobrazuje jen tehdy, když se díváte přímo na surový řetězec. Když ji potřebujete ukázat lidem, vypište ji pomocí nástroje pro formátování; strategii escapování řešte jen tehdy, když čínský text musí přežít v URL nebo v logu.

Čínský text se změní na rozsypaný text jako 涓枃: jde o problém kódování, nikoli JSON. Vzniká, když se bajty UTF-8 dekódují jako GBK, což vytváří tento pravidelný vzor „tři znaky zastupují jeden čínský“. Zkontrolujte hlavičku odpovědi Content-Type: application/json; charset=utf-8 a také to, zda je při čtení souboru explicitně uvedeno encoding='utf-8'.

4. Pětiminutový pracovní postup opravy

1. Vložte to do nástroje: nejprve pomocí online parseru najděte první chybu a opravujte vždy jen jednu;
2. Po každé opravě validujte: znovu parsujte po každé změně, aby oprava několika míst najednou nenechala nové chyby zakrýt tu původní;
3. Jednou minifikujte: odstraňte prázdné znaky pomocí Minifikace a znovu parsujte; tím oddělíte „strukturální chyby“ od „problémů s prázdnými znaky nebo zalomením řádku“;
4. Porovnejte strukturu: pokud se chyba objeví náhle po změně, použijte diff JSON proti předchozí verzi; rozdílem je obvykle jedna čárka;
5. Validace na úrovni polí: pokud syntaxe projde, ale obchodní vrstva ji odmítne (chybějící pole, špatný typ), spadá to pod validaci JSON Schema, nikoli mezi syntaktické problémy.

5. Proč jeden ze dvou „stejně vypadajících“ úryvků JSON projde a druhý ne

Nejčastější příčinou jsou neviditelné znaky: celošířková čárka ，, celošířkové uvozovky “”, nezlomitelná mezera U+00A0, mezera s nulovou šířkou U+200B. Na obrazovce je téměř nerozeznáte od jejich polovičních protějšků, ale žádný z nich není součástí gramatiky JSON.

Existuje jen jeden způsob, jak to zjistit: zkopírujte obsah kolem problematického znaku a prozkoumejte kódové body bajt po bajtu. Spuštěním následujícího kódu v konzoli prohlížeče vypíšete všechny znaky, které nejsou ASCII a nejsou v čínských rozsazích:

复制[...text].filter((ch) => {
  const code = ch.codePointAt(0);
  return code > 127 && !(code >= 0x4e00 && code <= 0x9fff);
});

Pokud se ve výstupu objeví 0x201c (levá dvojitá uvozovka), 0xff0c (celošířková čárka) nebo 0x00a0, jsou to oni.

6. Prevence je levnější než oprava

• Spouštějte kontrolu parsování konfiguračních souborů před commitem; v CI stačí jeden řádek: node -e "JSON.parse(require('fs').readFileSync('config.json','utf8'))";
• Odpovědi API generujte serializační knihovnou; nikdy neskládejte řetězce ručně – ručně sestavené řetězce jsou jediným zdrojem koncových čárek a chybějících uvozovek;
• Při logování JSON nejprve zavolejte JSON.stringify, místo abyste jej vkládali do šablony, aby polovičně hotový payload nebyl považován za kompletní zprávu.

Časté dotazy

Jak rychle najít pozici syntaktické chyby JSON?

Vezměte pozici nebo řádek a sloupec, které parser hlásí; position je offset znaku od nuly, nikoli číslo řádku, zatímco Java Jackson a Python udávají řádek a sloupec přímo. Vložte JSON do online parseru JSON a nástroj umístí kurzor na místo chyby a zvýrazní řádek a sloupec. Pokud chyba sedí na začátku, zkontrolujte v hlavičce souboru BOM a hledejte neviditelné znaky.

Proč konfigurace zkopírovaná z kódu tak často obsahuje koncovou čárku?

Specifikace JSON koncové čárky zakazuje, zatímco objektové literály v JavaScriptu je povolují, takže konfigurace zkopírovaná z kódu JS ji snadno přinese. Oprava je prostá – smažte poslední čárku; pokud data patří do souboru JS, je převod JSON5 vhodnější než jejich nucení do JSON.

Lze konfigurační soubor s komentáři parsovat jako běžný JSON?

Ne – gramatika RFC 8259 pro komentáře nemá místo, takže přímé parsování vyvolá chybu. Buď komentáře smažte, nebo soubor uložte jako .jsonc / .json5 a použijte parser, který komentáře podporuje. Kompromisům mezi schématy pro komentáře se věnuje Jak psát komentáře v JSON.