Srovnání knihoven pro parsování a zpracování JSON

Stručně: nejprve zařaďte potřebu, poté srovnávejte implementace – pro hodnoty jen ke čtení použijte nativní JSON.parse, jsonc-parser použijte, když potřebujete offsety nebo musíte zachovat původní formátování, a knihovny pro dotazy či patche přidávejte jen tam, kde jsou nutné; velké knihovny načítejte líně po stránkách a neudržované vyřaďte.

Každá knihovna tvrdí, že je „rychlá, malá a kompletní“. Co je skutečně odlišuje, je kolik informací vám dají, když se něco pokazí.

1. Čtyři kategorie podle účelu

Nejprve určete, ve které kategorii jste, a poté srovnávejte konkrétní implementace – jinak snadno použijete dotazovací knihovnu k práci parseru.

2. Srovnání vedle sebe

Chybové zprávy JSON.parse se mezi enginy výrazně liší. V8 produkuje něco jako Unexpected token } in JSON at position 42, ale zda je pozice přesná, závisí na verzi enginu; jsonc-parser naproti tomu vrací stabilní strukturovaný { error, offset, length }, který se hodí pro značky v editoru.

3. Čtyři klíčové rozhodovací body

3.1 Potřebujete offsety

Pokud stavíte editor a chcete „kliknout na chybu a skočit na odpovídající řádek“, musíte mít offset. Test je jednoduchý: pokud vaše chybová zpráva umí vypsat jen „invalid JSON“, uživatelé si ho budou muset najít sami.

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

3.2 Potřebujete zachovat původní text

Jen čtení hodnot → postačí jakýkoli parser. „Změnit jedno pole a všechno ostatní ponechat přesně tak, jak to bylo“ → musíte použít API editačního stylu, nikoli „parse → změnit objekt → serializovat“.

To poslední ztrácí: komentáře, pořadí klíčů (v některých implementacích), styl odsazení, zápis číselného literálu (1e3 se stane 1000) a formy escape sekvencí (\u4e2d se stane skutečným znakem).

3.3 Jsou okrajové chování explicitní

Před volbou knihovny zkontrolujte v dokumentaci tři věci:

1. Jak se zpracovávají duplicitní klíče (ponechat poslední / vyhodit chybu);
2. Zda velká celá čísla ztrácejí přesnost (většina JS knihoven ano, protože všechny procházejí přes Number);
3. Podporovaný rozsah pro BOM, komentáře a koncové čárky.

Pokud dokumentace chybí, napište malý vzorek a otestujte to sami. Je to spolehlivější než čtení README.

3.4 Stav údržby

Riziko JSON knihovny není v chybějících funkcích, ale v dlouhodobém zanedbání: nikdo už nebude vydávat bezpečnostní záplaty (prototype pollution, ReDoS).

4. Srovnání s jinými jazyky

Při výměně dat napříč jazyky jsou nejnáchylnější věci stále přesnost čísel a formáty času; volba knihovny je může zmírnit, ne odstranit.

5. Typické kombinace

Varianta 1: Nástrojový web (strana prohlížeče)

复制Parsování a lokalizace chyb: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Dotazy: jsonpath-plus
Patche: fast-json-patch
Sdílené odkazy: lz-string

Určujícím rysem této kombinace je, že vše běží lokálně a žádná data se nenahrávají, což odpovídá očekáváním soukromí u nástrojového webu.

Varianta 2: Serverová API brána

复制Validace: Ajv (zkompilujte schéma jednou, znovu používejte)
Parsování: nativní JSON.parse (spolu s limitem velikosti těla)
Odložené parsování velkých polí: ponechte surový řetězec, parsujte jen když je potřeba

Nezavádějte do vrstvy brány knihovny pro dotazy či patche, abyste implementovali obchodní logiku – to je úkol obchodní vrstvy.

Varianta 3: CLI a skripty

复制Výběr polí: jq
Převod formátů: yq / dasel
Interaktivní prohlížení: jless
Dávková validace: ajv-cli

6. Skutečný dopad velikosti balíčku a výkonu

• jsonc-parser je velmi malý a vhodný do hlavního balíčku;
• json5 je o něco větší než jsonc-parser, protože podporuje více syntaxe;
• jsonpath-plus obsahuje vyhodnocování výrazů a je znatelně větší, takže se má načítat líně po stránkách;
• fast-json-patch je středně velký a potřebujete ho jen tehdy, když máte funkci srovnávání.

Optimalizace je přímočará: importujte dynamicky po stránkách a nedávejte je do bloku prvního vykreslení.

复制const { JSONPath } = await import('jsonpath-plus');

7. Kontrolní seznam

• [ ] Knihovny vybírejte podle účelu; nepoužívejte dotazovací knihovnu pro parsování;
• [ ] jsonc-parser použijte, když potřebujete přesné lokalizace chyb;
• [ ] Api editačního stylu použijte, když se musí zachovat komentáře a formátování;
• [ ] V praxi otestujte tři okrajová chování: duplicitní klíče, velká celá čísla a BOM;
• [ ] Sledujte stav údržby knihovny a bezpečnostní doporučení;
• [ ] Velké knihovny importujte dynamicky podle potřeby.

Časté dotazy

Jak vybrat JSON knihovnu podle velikosti projektu?

Malé nástroje, které jen čtou data API, mohou zůstat u nativního JSON.parse. Projekty, které potřebují chyby na úrovni editoru nebo musí zachovat původní formátování, by měly použít jsonc-parser. Serverová brána potřebuje jen validaci a parsování, takže knihovny pro dotazy a patche nechte obchodní vrstvě, zatímco CLI skripty mohou použít rovnou jq, yq a ajv-cli.

Proč je stav údržby důležitější než počet funkcí?

Skutečné riziko JSON knihovny je dlouhodobé zanedbání, nikoli chybějící funkce: nikdo nebude vydávat bezpečnostní záplaty na prototype pollution nebo ReDoS. Ať je seznam funkcí sebeprostší, zastavená knihovna vás nechá záplatovat ji sami. Stav údržby a bezpečnostní doporučení berte jako tvrdá kritéria, místo abyste srovnávali tabulky funkcí.

Mám použít JSON.parse ke změně jednoho pole a zachovat komentáře a odsazení?

Ne. Parsování, změna objektu a následná serializace ztrácí komentáře, pořadí klíčů, styl odsazení, zápis číselného literálu (1e3 se stane 1000) i formy escape sekvencí (\u4e2d se stane skutečným znakem). Změna jednoho pole při zachování všeho ostatního vyžaduje API editačního stylu, například modify a applyEdits v jsonc-parser.