JSON 入门与实用技巧

What JSON Is

JSON (JavaScript Object Notation) is a lightweight data-exchange format defined by RFC 8259. Its core advantage: nearly every modern language has native support — JavaScript, Python, Java, Go, Rust, Swift all parse and serialize it in one line.

Typical structure:

{
  "name": "CATAITO",
  "tools": 16,
  "free": true,
  "tags": ["web", "privacy"],
  "nested": { "localOnly": true }
}

JSON is not JSONP, not JavaScript, not any programming language. It's a format — a grammar of data exchange, parallel to HTML and XML — with no logic of its own. As long as both sides follow the rules, data interoperates.

Supported Data Types

JSON knows only seven types, far fewer than JavaScript:

The absence of Date is a common first stumble: new Date() is a native object in JS, but JSON.stringify(new Date()) outputs an ISO string (because Date.prototype.toJSON is overridden). Conversely, JSON.parse given an ISO string does not restore a Date; your application must convert it.

Common Syntax Errors

When JSON parsing fails, 90% of the time it's one of the following. Use the JSON Formatter to see error positions and reasons.

1. Trailing commas: [1, 2, 3,] or {"a": 1,} are invalid. Python/JS allow them, JSON does not.
2. Single-quoted strings: {"name": 'Alice'} is invalid. JSON only accepts double quotes.
3. Unquoted keys: {name: "Alice"} is invalid. JS object literals allow it, JSON does not.
4. Comments: {"a": 1 /* comment */} is invalid. JSON has no comment syntax.
5. undefined / NaN: {"a": undefined} or {"a": NaN} are invalid. Use null for "no value".
6. Unescaped nested quotes: "say "hi"" will fail. Escape the inner quotes: "say \"hi\"".

JSON vs JavaScript Objects

"JSON is just a JS object" is a common misconception. They differ strictly in syntax:

So to generate JSON from a JS object, always use JSON.stringify(obj) — never drop the object literal into an HTTP response as a string. Conversely, to restore a JS object from JSON, use JSON.parse(str), never eval() — the latter executes arbitrary code and is a security hole.

JSON vs YAML / TOML / CSV

Four common data formats with distinct purposes:

Rule of thumb: interfaces, logs, storage use JSON; config files use YAML or TOML (YAML has a larger ecosystem, TOML has stricter syntax); pure tabular data uses CSV. Mixing is a common mistake — e.g., treating CSV as config breaks as soon as a field contains commas, newlines, or quotes.

Practical Tips & Gotchas

Escaping and encoding

In JSON strings, ", \, and control characters (\n, \t, \r) must be escaped. Non-ASCII characters can be written directly as UTF-8, or via \uXXXX. Chinese generally works as UTF-8 unless the target environment doesn't support it.

Large files and streaming

A single JSON.parse on a 50MB file freezes the main thread. For large data, use streaming parsers: JSON Lines (one JSON object per line, parse line-by-line) is a common pattern — used by Kafka, Elasticsearch, etc.

The undefined trap in serialization

JSON.stringify({a: undefined, b: null, c: 1}) outputs {"b":null,"c":1} — the undefined field is silently dropped, null is preserved. If you depend on the distinction between "field missing" and "field is null", be careful.

Number precision

JSON numbers have no integer/float distinction. JS numbers are 64-bit IEEE 754; values above 2^53 lose precision. For snowflake IDs and arbitrary-precision numbers, serialize as strings:

{"id": "12345678901234567890"}  // String, safe
{"id": 12345678901234567890}   // Number, may become 12345678901234567000

Schema validation

The JSON spec handles only syntax, not structure. To validate that a JSON conforms to a shape, use JSON Schema or a runtime library (e.g., Python's pydantic, JS's zod). This is a required defense layer in production.

FAQ