CJON v1.0 (Compact JSON)
Развивая идею цифрового шага назад для решения актуальных
задач по альтернативной передаче цифровых данных, я начал проектировать прототип устройства на Arduino, выполняющего функции модема и приёмника. В процессе погружения в задачу, пришла идея задействовать также SMS-канал для коротких данных, где хватит 160-символьных SMS (GSM 7-bit). Во многих случаях этого объёма хватает, а для передачи более крупных пакетов можно использовать разбиение на блоки с последующей сборкой на стороне приёмника.
Чтобы связать такие фрагменты, каждому сообщению можно добавить метаданные: порядковый номер, общее количество блоков и идентификатор. Это похоже на стандарт UDH (User Data Header), но поскольку для его использования требуется режим PDU, который часто недоступен на Arduino, то можно использовать более простой способ - собственный формат псевдозаголовка.
Для этого каждый фрагмент будет начинаться со специального символа #, за которым следует:
- идентификатор сообщения (2–3 символ),
- номер текущего фрагмента (1 символ, от 0...9, a...Z),
- общее количество фрагментов (1 символ, от 0...9, a...Z).
Пример заголовка: #0010Z, где:
- 00 - ID сообщения (можно генерировать в виде свертки текущего времени, например на устройстве источнике),
- 1 - порядковый номер фрагмента,
- Z - общее количество фрагментов.
Данные могут быть переданы не только через SMS, но и по голосовому каналу, например, с помощью DTMF-сигналов (Dual-Tone Multi-Frequency). В этом случае данные кодируются в последовательность DTMF-тонов, представляющих символы сообщения, и передаются как звук в рамках обычного телефонного звонка. Приёмник распознаёт последовательность тонов, восстанавливает сообщение и передаёт его в целевую систему.
Чтобы обеспечить целостность данных, передаваемых по голосовому каналу целесообразно в конце сообщения добавить контрольную сумму, которая будет рассчитывать как сумма всех передаваемых символов по модулю 256 для контроля целостности переданных данных. Для SMS это не требуется.
Для передачи данных предлагается модернизированный и упрощенный формат данных, основанный на спецификации JSON, но упрощенный с целью экстремальной минимазации объёма данных (экономим каждый символ).
Спецификация формата CJON (Compact JSON-like Object Notation) v1.0
1. Назначение
CJON – это легковесный, компактный и человекочитаемый формат, предназначенный для использования в условиях ограниченных каналов связи, таких как SMS, DTMF, и низкоскоростная радиосвязь. Его основное назначение – передача структурированных телеметрических или управляющих данных в случаях, когда традиционный JSON слишком объёмен, а бинарные форматы непрактичны или плохо читаемы.
2. Области применения
- Дистанционная телеметрия для сельского хозяйства и промышленного оборудования
- Аварийные сообщения и тревоги
- Автоматизация в условиях низкоскоростной или оффлайн-связи
- Мобильные устройства, передающие структурированные данные через SMS или голосовую связь
- Передача данных по DTMF через GSM-сети
3. Обзор синтаксиса
Сообщение CJON состоит из последовательности элементов, разделённых точками с запятой (;).
- Первый элемент - тип сообщения (обязателен, без ключа), например: T1
- Остальные элементы - пары ключ=значение или значения через запятую для массивов.
Пример запроса (вызов такси):
T1;f=56.3365,36.7259;to=56.1843,36.9745;r=2
4. Типы данных и правила
Ключи должны быть буквенно-цифровыми (для компактности целесообразно ключи сокращать, а в целевых системах дополнительно хранить мэппинг для корректного восстановления JSON из CJON). Названия ключей чувствительны к регистру для расширения их множества (62 ключа на одном уровне иерархии для 1 символа).
Значения могут быть:
- строками (без пробелов, точек с запятой, знаков равенства и запятых в значении), либо упакованными base64. В этом случае значению предшествует обязательный префикс ~ (например: M1;id=device-01;msg=~0JrQvtC80L7RgtGAINC80LXQvdGC0L7QstCwIDEy;level=3)
- целыми числами или числами с плавающей точкой,
- списками значений, разделёнными запятыми (интерпретируются как массивы).
- кавычки и скобки не используются для сокращения объёма.
Поддержка вложенности:
CJON поддерживает вложенные объекты через точечную нотацию ключей (например, d.b.v=3.7 - device, batt, voltage).
Пример:
S1;d.id=agro-007;d.b.v=3.7;d.b.s=ok;l.lat=56.3284;l.lon=37.4921;e.temp=23.5;e.hum=61
5. Преобразование в JSON
CJON: T1;f=56.3365,36.7259;to=56.1843,36.9745;r=2
Эквивалентный JSON:
{
"t": "T1",
"f": [56.3365, 36.7259],
"to": [56.1843, 36.9745],
"r": 2
}
6. Сравнение CJON и JSON
- CJON устраняет кавычки, скобки и пробелы, тем самым экономя от 30% до 50% символов.
- Пример JSON (398 символов) -> аналогичный CJON (287 символов): экономия 111 символов (~28%).
7. Ограничения
- Максимальная длина сообщения ограничена 140 символами (например, для SMS).
- Вложенные объекты и JSON-строки не поддерживаются (кроме имитации через точку).
- Зарезервированные символы (=, ;, ,) не могут использоваться в ключах или значениях, в строках должны быть упакованы Base64.
- Первый элемент - всегда тип сообщения (без ключа).
8. Расширяемость
Дополнительные пары ключ=значение могут добавляться к сообщению без нарушения обратной совместимости. Приложения должны игнорировать неизвестные ключи для обеспечения поддержки будущих версий.
9. Сравнение с существующими подходами
Существует ряд форматов и методов, разработанных с целью сократить объём JSON-данных, особенно в условиях ограниченных каналов связи (например, в IoT, мобильных или встраиваемых системах). Ниже приведён краткий обзор таких подходов.
Бинарные форматы
- MessagePack (msgpack.org) - бинарный формат сериализации, который кодирует JSON в компактный бинарный вид. Даёт сокращение на 30-60% по сравнению с обычным JSON. Используется в высокопроизводительных API, но не подходит для текстовых каналов связи (SMS, голос, DTMF).
- CBOR (Concise Binary Object Representation) (cbor.io) - формат от IETF, используемый в CoAP и других IoT-протоколах. Обеспечивает высокую степень сжатия, поддерживает теги и расширенные типы данных. Требует парсера на стороне приёмника.
- UBJSON / BSON / Smile - бинарные альтернативы JSON, ориентированные на специфические платформы (MongoDB, Java и др.). Не применимы в условиях, где требуется текстовая передача или совместимость с низкоуровневыми каналами.
Текстовые форматы
MinJSON / SlimJSON... - неформальные минималистичные текстовые форматы, в которых устраняются пробелы и кавычки, ключи заменяются на короткие, и используется нестандартный синтаксис. Подходы разрозненные, не стандартизированы, вложенность не поддерживается.
10. Заключение
CJON представляет собой структурированный, но компактный формат, являющийся альтернативой громоздким форматам, таким как JSON или XML, в условиях ограниченных ресурсов. Он обеспечивает баланс между читаемостью, простотой обработки и экономией трафика, что делает его идеальным для маломощных, низкоскоростных или устаревших систем. Для сложных JSON-файлов, имеющих большое количество вложенных объектов и текстовых данных, возникает эффект увеличения размера CJON, но при этом остается сохранение совместимости для применения формата в SMS, а за счёт того, что CJON приводит все текстовые данные к BASE64 формату, то незначительное увеличение размера структуры нивелируется тем, что SMS отправляется по-прежнему в формате GSM 7-bit, против UCS-2 (UTF-16).