Мой дэйли дайджест

одно техническое понятие в день

JSON

25 мая 2026 · ~12 мин чтения

формат-данных веб история json

JSON

JSON (JavaScript Object Notation) — текстовый формат записи структурированных данных в виде объектов (пар «ключ–значение») и массивов. Это де-факто универсальный язык обмена данными между сервером и клиентом в современном вебе, а также самый ходовой формат для конфигов и логов.

История

Самое важное про JSON

Это не «формат данных». Это общий язык, на котором программы, написанные на разных языках, могут договориться о структуре сообщения без предварительного согласования схемы. Сила JSON — не в синтаксисе, а в том, что его поддерживает буквально каждый язык программирования из коробки.

Что это такое

JSON — это текстовый формат, в котором данные записаны как комбинация шести базовых типов:

  1. Объект: {"name": "Pavel", "age": 38} — набор пар «ключ-значение». Ключ всегда строка в двойных кавычках.
  2. Массив: [1, 2, 3, "foo"] — упорядоченный список значений (могут быть разнотипными).
  3. Строка: "привет" — обязательно в двойных кавычках, поддерживает Unicode и экранирование.
  4. Число: 42, -3.14, 1.5e10 — без обозначения типа (int/float не различаются на уровне формата).
  5. Булево: true или false.
  6. null — пустое значение.

Всё. Никаких дат, никаких функций, никаких ссылок, никакой типизации сложнее этого. В этой минимальности — главная сила JSON: его легко распарсить, легко прочитать глазами, легко передать через любой текстовый канал (HTTP, файл, поле в базе, лог).

Сравнение с соседями:

Аналогии из жизни

Аналогия 1: бланк заказа в кафе.
Официант приносит лист с пунктами: «Имя клиента», «Стол», «Заказ» (список блюд). Кухня читает его и готовит. Это и есть JSON: структурированный, заранее согласованный шаблон, который понимают оба — и тот, кто заполняет, и тот, кто читает.
Где ломается. В кафе можно дописать что-то на полях («без соли, пожалуйста») — и кухня поймёт. В JSON никаких «полей» нет: либо поле описано в схеме и в нём есть значение, либо его нет. Свободные приписки игнорируются или ломают парсер.

Аналогия 2: посылка с описью.
Курьер берёт коробку с описью внутри: «6 книг, 1 ноутбук, 2 кабеля». Получатель сверяет содержимое с описью. Так работают JSON-API: сервер кладёт «опись» в тело ответа, клиент её читает и достраивает интерфейс.
Где ломается. В реальной посылке книгу можно подержать в руках, нюхнуть, проверить состояние. В JSON «описание» и есть сами данные: если в описи написано «6 книг», то это 6 строк, и больше про них ничего узнать нельзя без отдельного запроса. Реальные книги — на сервере, JSON — только их карточки.

Аналогия 3: партитура.
Композитор пишет партитуру, оркестр её играет. Партитура — текст с жёсткими правилами (ключ, размер, ноты). Все, кто умеет читать, играют одинаково. JSON — это партитура для программ: одна запись, любая платформа, одинаковый результат.
Где ломается. В партитуре есть динамика, штрихи, ремарки на естественном языке — «нежно», «con fuoco». JSON эту нюансировку не передаст: чтобы выразить «эту строку показывать жирным», нужно либо договориться о специальном поле ("bold": true), либо завернуть в HTML/Markdown. JSON не знает про оформление.

Как это работает

Жизненный цикл JSON в типичном веб-сценарии — пять шагов.

Шаг 1: сериализация.
В программе есть структура в памяти — объект, словарь, dataclass. Чтобы её передать наружу, библиотека рекурсивно обходит дерево и превращает в строку по правилам формата:

import json
data = {"user": "pavel", "tags": ["dev", "writer"], "active": True}
text = json.dumps(data)
# '{"user": "pavel", "tags": ["dev", "writer"], "active": true}'

Обрати внимание: True в Python превратился в true в JSON — это конвертация между типами языка и формата.

Шаг 2: передача.
Полученная строка отправляется по каналу. Обычно это HTTP — в теле POST-запроса или в теле ответа. В HTTP-заголовке ставится Content-Type: application/json; charset=utf-8. Получатель видит этот заголовок и понимает: «дальше будет JSON в UTF-8».

Шаг 3: парсинг.
На другой стороне библиотека читает строку и строит структуру в памяти:

const text = '{"user": "pavel", "tags": ["dev", "writer"], "active": true}';
const obj = JSON.parse(text);
// obj.user === "pavel"; obj.tags[0] === "dev";

Парсинг — это маленький конечный автомат, который читает символы и опознаёт токены: {, }, [, ], :, ,, строка, число, ключевое слово. Если встречается лишний символ или невалидное число — парсер бросает исключение. JSON строгий: висячая запятая [1, 2, 3,] уже невалидна.

Шаг 4: валидация.
Программа может проверить, что распарсенный объект соответствует ожидаемой форме (JSON Schema, Pydantic, Zod, ajv). Это уже не часть формата — это надстройка, страховка от мусора.

Шаг 5: использование.
Дальше с объектом работают как с обычной структурой языка.

ASCII-схема, как выглядит запрос-ответ:

КЛИЕНТ                              СЕРВЕР
  |                                   |
  |  POST /api/users HTTP/1.1         |
  |  Content-Type: application/json   |
  |                                   |
  |  {"name":"Pavel","age":38}        |
  |---------------------------------->|
  |                                   |
  |                                   | парсит JSON,
  |                                   | сохраняет в БД,
  |                                   | формирует ответ
  |                                   |
  |  HTTP/1.1 201 Created             |
  |  Content-Type: application/json   |
  |                                   |
  |  {"id":42,"created":"2026-05-25"} |
  |<----------------------------------|
  |                                   |
парсит ответ,                          |
обновляет UI                           |

Заметь: дата "2026-05-25" — это просто строка. В формате нет типа «дата», договорённость о ISO-8601 — соглашение между сторонами, не часть JSON.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Альтернативы и конкуренты

Деньги в JSON — это грабли

JSON не различает целые и дробные, не знает про точность. 19.99 парсится как float и теряет копейки на округлении. Для денег храните строкой ("19.99") или в копейках (1999) — никогда как число с плавающей точкой.

Когда НЕ стоит использовать

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера в работе с Claude Code я гонял генерацию меню для бота-тренера: запрашивал у модели валидный JSON с заранее описанной схемой («только эти ID, только эта структура») и парсил ответ в Python. Параллельно в проекте трекера лежали конфиги (config.json), состояния по дням (state/YYYY-MM-DD.json) и логи фактов. То есть JSON работал одновременно в трёх ролях: контракт модель↔код, формат конфига и формат лога. Это и есть его типичная роль — общий «алфавит», на котором программы и сервисы между собой переписываются.

Краткое резюме