Данные
Формат JSON: спецификация и направления
Направления в обе стороны: из JSON и в JSON, с параметрами каждого преобразования.
Спецификация JSON
| Полное имя | JavaScript Object Notation |
|---|---|
| Разработчик спецификации | Дуглас Крокфорд |
| Год публикации | 2001 |
| Расширение | .json |
| MIME-типы | application/json, text/json, application/x-json |
| Тип содержимого | Текстовое |
| Многостраничность | Не предусмотрена |
| Типы данных | Строка, число, логическое, null, массив, объект |
| Стандарт | RFC 8259 / ECMA-404 |
| Кодировка | UTF-8 |
| Комментарии | Не поддерживаются |
| Схема | Опционально, через JSON Schema |
| Читающие программы | VS Code, Notepad++, Sublime Text, JetBrains IDE, Google Chrome, jq |
| Документ спецификации | Открыть спецификацию |
JSON → другие форматы
| Направление | Что получится | Точность |
|---|---|---|
| .json.csv | Конвертация JSON в CSV | близкая |
| .json.xml | Конвертация JSON в XML | близкая |
| .json.xlsx | Конвертация JSON в XLSX | близкая |
| .json.yaml | Конвертация JSON в YAML | точная |
Другие форматы → JSON
| Направление | Что получится | Точность |
|---|---|---|
| .csv.json | Конвертация CSV в JSON | точная |
| .xml.json | Конвертация XML в JSON | близкая |
| .xlsx.json | Конвертация XLSX в JSON | близкая |
| .yaml.json | Конвертация YAML в JSON | близкая |
Спецификация JSON
JSON описан в RFC 8259 и состоит из шести типов: объект, массив, строка, число, логическое значение и null. Кодировка — UTF-8. В спецификации нет комментариев, висящих запятых, одинарных кавычек, незакавыченных ключей, шестнадцатеричных литералов и типа «дата». Всё перечисленное встречается в файлах и делает их невалидными.
Числа в JSON не имеют объявленной точности, но подавляющее большинство разборщиков представляет их как IEEE 754 двойной точности. Целые числа сохраняются точно до 2^53 − 1, то есть до 9 007 199 254 740 991. Ключи баз данных и мессенджеров длиной в восемнадцать-девятнадцать цифр выходят за эту границу и теряют младшие разряды, поэтому их принято передавать строками. Ведущие нули и знак «плюс» перед числом спецификация запрещает.
Формат рассчитан на данные, у которых есть глубина: позиции и статусы внутри заказа, ветвящийся справочник, конфигурация с вложенными секциями. Для потоковой записи применяется построчный вариант JSON Lines — один объект на строку, файл разбирается по одной записи и не требует загрузки целиком в память. Обычный JSON такого не позволяет: документ валиден только целиком.
Преобразование в таблицу — операция с неизбежным упрощением. Массив верхнего уровня даёт строки таблицы, набор ключей — заголовки столбцов, а вложенный объект раскрывается составным именем вида customer.city. Проблему создают массивы переменной длины: заказ с тремя позициями и заказ с тридцатью не ложатся в одну строку таблицы. Такие данные выгружают отдельным файлом, где строкой становится позиция, а не заказ. Даты остаются строками ISO 8601 или числовыми метками времени — типом ячейки они не станут без явного назначения.
Форматы того же класса
Остальные записи класса «Данные». Для каждой заведена своя страница с полным перечнем направлений: и от JSON, и к нему.
Вопросы по формату JSON
Разборщик сообщает об ошибке в первом символе, хотя файл выглядит корректным.
Почти всегда это метка порядка байтов (BOM) — три байта EF BB BF в начале UTF-8 файла. Визуально она не отображается, но по RFC 8259 в начале документа JSON её быть не должно, и строгий разборщик останавливается сразу. Второй по частоте случай — файл в кодировке UTF-16 или Windows-1251 с расширением .json.
Чем YAML удобнее JSON и что теряется при переводе?
YAML допускает комментарии, многострочные значения без экранирования и якоря для повторного использования блоков, поэтому его выбирают для файлов, которые правит человек. При переводе YAML → JSON комментарии и якоря исчезают: якоря разворачиваются в копии значений, комментарии в модели данных JSON отсутствуют. Обратное преобразование даёт валидный YAML, но без структурных удобств, которых не было в источнике.
Как в XML переносятся массивы?
В XML нет типа «массив», поэтому каждый элемент оборачивается повторяющимся тегом внутри контейнера с именем поля. Обратное преобразование однозначным не является: одиночный элемент неотличим от массива длиной один, а типы теряются — числа и логические значения становятся текстом. Атрибуты XML отображаются в отдельные ключи, чтобы не смешиваться с дочерними элементами.