Dlaczego przecinek końcowy psuje JSON
Podsumowanie: Przecinki końcowe są legalne w literałach obiektowych JavaScript i zabójcze w JSON-ie. Oto dokładny błąd, gramatyka RFC 8259, która go powoduje, i trzy poprawki, które naprawdę działają.
Najważniejsze: JSON zabrania przecinków końcowych wszędzie — gdy parser zawodzi, usuń ostatni przecinek formaterem; JSON5 lub JSONC używaj tylko do lokalnego łagodnego parsowania, a do innych systemów zawsze emituj standardowy JSON.
Bo gramatyka tak mówi.
{
"name": "demo",
"size": 12,
}
JSON.parse rzuca Unexpected token } in JSON at position 34. Node formułuje to inaczej, ale każdy silnik wskazuje to samo miejsce: przecinek przed }.
Na co naprawdę narzeka parser
Produkcja obiektu w RFC 8259 to:
object = begin-object [ member *( value-separator member ) ] end-object
Nawiasy kwadratowe znaczą opcjonalność, gwiazdka znaczy zero lub więcej. Mówiąc prościej: przecinki rozdzielają składowe, a po ostatniej składowej następuje bezpośrednio }.
Więc po przecinku parser jest gotowy na kolejną nazwę składowej. Czyta } i zawodzi. Tablice zachowują się identycznie — [1, 2, 3,] zawodzi na ].
Skąd bierze się nawyk
Literały obiektowe JavaScript pozwalają na przecinki końcowe od ES5, podobnie listy Pythona i literały złożone Go. Edytory dodają je automatycznie. Potem ktoś kopiuje literał obiektowy z pliku .js do pliku .json i plik przestaje się parsować.
Innym częstym źródłem jest ręcznie budowany JSON: pętla działająca i <= length zostawia przecinek po ostatnim elemencie.
Trzy poprawki
Usuń przecinek. W porządku przy ręcznych edycjach. Wklej do formatera JSON, a błąd zostanie zgłoszony z wierszem i kolumną, więc zobaczysz dokładnie, który usunąć.
Parsuj jako JSON5. Nadzbiory akceptują przecinki końcowe, co jest w porządku dla lokalnej konfiguracji. Nie jest w porządku dla czegokolwiek wysyłanego do innego systemu — odbiorca i tak to odrzuci.
Przestań sklejać łańcuchy. Użyj JSON.stringify, json.dumps, Jackson. Serializator poprawnie obsługuje separatory i jednocześnie rozwiązuje ucieczkę.
Szybka lista audytu
| Gdzie | Typowa przyczyna |
|---|---|
| Konkatenacja w pętli | i <= length zostawia jeden zbędny przecinek |
| Kopiuj-wklej | Literał obiektowy podniesiony z pliku JS |
| Szablony | Twardy przecinek plus pętla, która dodaje kolejny |
| Ręczna edycja | Usunięto ostatnie pole, a jego przecinek został |
FAQ
Dlaczego przecinki końcowe są legalne w JavaScript, a nie w JSON-ie?
Literały obiektowe JavaScript pozwalają na nie od ES5, podobnie listy Pythona i literały złożone Go, dlatego nawyk podąża za ludźmi do JSON-a. RFC 8259 pozwala na przecinki tylko między składowymi: po ostatniej następuje bezpośrednio } lub ]. Kopiowanie literału obiektowego z pliku .js do .json jest zwykłym źródłem.
Czy parsować jako JSON5, aby akceptować przecinki końcowe?
Tylko dla lokalnej konfiguracji. Nadzbiory akceptują przecinki końcowe, ale cokolwiek wysyłasz do innego systemu, jest parsowane jako ścisły JSON i nadal zawiedzie. Emituj standardowy JSON na granicy wyjścia, zamiast liczyć na łagodność odbiorcy.
Czego szukać najpierw po błędzie przecinka końcowego?
Zacznij od position w komunikacie błędu: zwykle wskazuje przecinek przed } lub ]. Potem sprawdź trzy typowe źródła: pętlę zapisaną jako i <= length, literał obiektowy wklejony z pliku JS i szablon, który twardo koduje przecinek obok pętli. Wklejenie do formatera podaje dokładny wiersz i kolumnę.