Developer

Типы данных, null, даты и числа

↑ 1.4 JSON, XML и другие форматы · ← Предыдущая · → Следующая

Обязательно~5 мин чтенияУровень: junior

Зачем это аналитику и PM

«Пусто», «ноль» и «поля нет» в отчёте расходятся, если в JSON это три разных факта. Дата без пояса и сумма в обычном числе так же тихо портят приёмку.

План темы

  • строка, число, boolean, null
  • пустая строка и отсутствие поля
  • даты и часовые пояса (ISO 8601, UTC)
  • деньги и точность

Объяснение

В JSON мало типов. Строка в двойных кавычках, число без кавычек, логические true и false, пустое null, а ещё объект и массив. Отдельного типа «дата» или «деньги» нет. Их изображают строкой или числом, и это надо договорить.

Как графы анкеты. «Не заполнено» — графа есть, в ней пусто. «Графу вычеркнули» — поля нет в тексте. «Написали ноль» — значение есть, и оно число 0. Для склада это три разных остатка: неизвестно, пустая подпись и нулевая полка.

Пустота

null значит «значения нет», поле при этом присутствует. Пустая строка "" значит «строка есть, в ней ноль символов». Отсутствующий ключ значит «поле не прислали». Ноль 0 и false — обычные значения, не пустота. В требованиях для каждого поля выбирают один смысл пустого. Нельзя писать «если пусто», не сказав, какой из трёх случаев имеется в виду. Приёмка тогда спорит о баге, которого нет.

Даты

Дату почти всегда кладут строкой. Удобная запись — ISO 8601: календарная дата, при необходимости время. 2026-10-04 — день без времени. 2026-10-04T10:15:00Z — момент в UTC: буква Z значит «всемирное время», без сдвига. 2026-10-04T13:15:00+03:00 — тот же вид момента со сдвигом. Без Z и без сдвига неясно, чьи это часы: сервера, пользователя или базы. Для срока оплаты и «сегодняшней» выборки пояс фиксируют в контракте.

Деньги

Сумма с копейками в виде JSON-числа опасна, если её читают как двоичную дробь: не каждая копейка имеет точную двоичную запись. Для денег выбирают одно из явных правил и пишут его в контракте. Целое в минимальных единицах, например копейки. Либо строка с десятичной записью "10.10". Валюта — отдельное поле, не символ внутри суммы. Округление «до копеек» тоже правило, его не оставляют на экран.

ЗаписьЧто этоЧего не говорить
"10"СтрокаЧто это уже число для суммы
10ЧислоЧто дробь сохранит копейки сама
nullПоле есть, значения нетЧто это ноль
""Пустая строкаЧто поля не было
нет ключаПоле не прислалиЧто пришёл null

Примеры

Схема одного заказа. Все значения вымышлены, текст является корректным JSON.

{
  "id": "1042",
  "qty": 2,
  "comment": null,
  "note": "",
  "paidAt": "2026-10-04T10:15:00Z",
  "amountMinor": 1010,
  "currency": "RUB"
}

comment прислали и он пуст по смыслу null. note — пустая строка, это другой факт. amountMinor — 1010 минимальных единиц, то есть 10 рублей 10 копеек, если единица — копейка. Это условие надо произнести, из имени поля оно только подразумевается.

Тот же день без поясного суффикса — уже хуже как контракт:

{"paidAt": "2026-10-04T10:15:00"}

Такой текст законный JSON, но момент не однозначен.

Нюансы и подводные камни

  • true без кавычек — логическое. "true" — строка из четырёх букв. Фильтр их не обязан считать равными.
  • Ведущие нули в JSON-числе не пишут. Код товара с нулями — строка, иначе разбор сломается или нули исчезнут.
  • Большой целочисленный идентификатор, который не влезает в обычное целое языка, тоже часто оставляют строкой. Это вопрос к команде, не догадка по длине на глаз.

Практика

Для полей «комментарий», «сумма», «время оплаты» напишите тип, как выглядит пусто и в какой единице сумма.

Ожидаемый результат: у комментария выбран один вариант из null, пустой строки и отсутствия ключа. У суммы названы минимальные единицы или строка и код валюты. У времени есть пример ISO 8601 с Z или со сдвигом. Второй формат не добавлен «для удобства экрана» без пометки, что это уже другое поле.

Вопросы с ответами

Связано с блоком Developer

Связанные темы

Вид графа

Обратные ссылки