С каждым витком развития информационных технологий мы все больше зависим от них. Неблагоприятные события и масштабные инциденты в области связи, кибербезопасности и т.п. обнажают нашу зависимость от технологий и беспомощность при её исчезновении. В современной России мы часто сталкиваемся с условиями ограниченной доступности телекоммуникационных технологий в том числе блокировка мобильного Интернета. При этом iot-устройства, датчики и мобильные приложения требуют для их работы возможности передачи данных. Например, отсутствие Интернета делает невозможным заказ Яндекс-такси, передачи данных с метеостанции в поле, снятие показаний устройств умного дома загородом.
Для решения описанной проблемы предлагается использование резервного канала в виде SMS-сообщений, передачи данных посредство DTMF (Dual-Tone Multi-Frequency - технология тонального набора номера, используемая в телефонах и других устройствах для передачи цифровой информации по телефонным линиям). Предлагается использовать голосовые и SMS-каналы сотовой сети (включая 2G) как резервный транспорт для передачи данных на сервер, который имеет стабильное Интернет-соединение. Для упаковки данных в приемлемый компактный вид предлагается следующее решение.
1. Назначение
CJON - это легковесный, компактный и человекочитаемый формат, предназначенный для использования в условиях ограниченных каналов связи, таких как SMS, DTMF, и низкоскоростные и устаревшие каналы связи (например, 2G, голос, радиоканал). Его основное назначение - передача структурированных телеметрических или управляющих данных в случаях, когда традиционный JSON слишком объёмен, а бинарные форматы непрактичны или плохо читаемы.
2. Области применения
Дистанционная телеметрия для сельского хозяйства и промышленного оборудования;
Аварийные сообщения и тревоги;
Автоматизация в условиях низкоскоростной или оффлайн-связи;
Мобильные устройства, передающие структурированные данные через SMS или голосовую связь;
Передача данных по DTMF через GSM-сети.
3. Обзор синтаксиса
Сообщение CJON состоит из последовательности элементов, разделённых точками с запятой (;).
Первый элемент - тип сообщения (обязателен, без ключа), например: T1;
Остальные элементы - пары ключ=значение или значения через запятую для массивов.
Пример запроса для такси (f - from массив координат точки, to - массив координат точки назначения, r- тариф):
T1;f=56.3365,36.7259;to=56.1843,36.9745;r=2
4. Типы данных и правила
Ключи должны быть буквенно-цифровыми (для компактности целесообразно ключи сокращать, а в целевых системах дополнительно хранить мэппинг для корректного восстановления JSON из CJON). Названия ключей чувствительны к регистру для расширения их множества (62 ключа на одном уровне иерархии для 1 символа).
Значения могут быть:
строками (без пробелов, точек с запятой, знаков равенства и запятых в значении), либо упакованными base64. В этом случае значению предшествует обязательный префикс ~ (например: 01;msg=~0KHRgtGD0LrQsNC70LjQvSDQkNC70LXQutGB0LXQuQ==;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. Сравнение CJON и JSON
CJON устраняет кавычки, скобки и пробелы, тем самым экономя от 30% до 50% символов;
Пример JSON (398 символов) -> аналогичный CJON (287 символов): экономия 111 символов (~28%).
6. Сравнение с существующими подходами
Существует ряд форматов и методов, разработанных с целью сократить объём 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... - неформальные минималистичные текстовые форматы, в которых устраняются пробелы и кавычки, ключи заменяются на короткие, и используется нестандартный синтаксис. Подходы разрозненные, не стандартизированы, вложенность не поддерживается.
7. Расширенная вложенность (оптимизация через блоки)
Для дополнительного сокращения объема сообщения в случае передачи вложенных словарей (объектов), CJON допускает альтернативный способ представления вложенности с помощью фигурных скобок {};
Вместо того чтобы сериализовать каждый элемент вложенного объекта через точечную нотацию, например:
batt.voltage=3.7;batt.status=ok
можно использовать вложенный блок, если он оказывается более компактным:
batt{voltage=3.7;status=ok}
Правила применения:
Блоки могут быть вложены на любую глубину;
Допустимо чередование точечной и блочной нотации;
Внутри фигурных скобок допускается та же структура ключ=значение; с разделителями ";";
Символы { и } становятся зарезервированными и требуют экранирования (или кодирования base64) внутри значений, если используются как часть строки;
Парсеры CJON должны быть способны различать как a.b=1, так и a{b=1} и обрабатывать их как эквивалентные формы.
Пример:
S1;device{id=agro-007;batt{voltage=3.7;status=ok}};env{temp=22.5;hum=60}
Эквивалент в точечной нотации:
S1;device.id=agro-007;device.batt.voltage=3.7;device.batt.status=ok;env.temp=22.5;env.hum=60
Для сериализации вложенных объектов CJON-парсер может автоматически выбирать между блочной и точечной нотацией в зависимости от итоговой длины строки: используется тот формат, который экономит больше символов.
Заключение
CJON представляет собой структурированный, но компактный формат, являющийся альтернативой громоздким форматам, таким как JSON или XML, в условиях ограниченных ресурсов. Он обеспечивает баланс между читаемостью, простотой обработки и экономией трафика, что делает его идеальным для маломощных, низкоскоростных или устаревших систем. При кодировании JSON-файлов, имеющих большое количество вложенных объектов и текстовых данных, CJON может быть сопоставим или даже превышать кодируемый JSON по объёму из-за использования base64 или вложенных объектов, но при этом сохраняет преимущества в каналах связи и сохраняет совместимость для применения формата в SMS. Незначительное увеличение размера структуры нивелируется тем, что закодированные структуры отправляются в формате GSM 7-bit, против UCS-2 (UTF-16).
Использование "=" вместо привычного для JSON ":" обусловлено сферой применения и:
Привычный синтаксис: используется в .env, URL-параметрах, INI-файлах key=value.
Проще парсить: split('=') быстрее и надёжнее, чем обработка : без кавычек.
Меньше конфликтов: : часто встречается в значениях (время, пути, IP:порт), = реже.
Лучше читаемость: визуально чётко разделяет ключ и значение в линейной записи.
-
Унификация: помогает отделять объекты (=) от массивов (val1,val2).
Для представления работы формата был разработан пример конвертора CJON <-> JSON.
Комментарии (43)
Akina
03.08.2025 17:342. Области применения
Эммм... не подскажете, в какой из перечисленных под этим заголовком областей рассматриваемый формат хотя бы теоретически выигрывает у бинарного? Потому как читабельность в указанных областях никому нафиг не нужна (принимающей стороной ни в одной из указанных областей не будет человек), а по части компактности бинар выигрывает по определению..
Значения могут быть: ... упакованными base64
CJON устраняет кавычки, скобки и пробелы, тем самым экономя от 30% до 50% символов;
С учётом первой цитаты, вторая воспринимается как осознанное лукавство.
almirus
03.08.2025 17:34При блокировке моб инета отправка данных (текстовых) возможно только через sms.
VanKrock
03.08.2025 17:34Автор пишет что, кодирует сообщение в Base12 для DTMF, почему тогда не использовать бинарный формат protobuf или messagepack и кодировать сообщение в base64 или base85 для передачи через SMS? если данные это числа с плавающей точкой, например координаты или другие показания датчиков, то выигрыш должен быть довольно большим
bormee Автор
03.08.2025 17:34Ниже уже отвечал. думал об этом, но для поставленной задачи придется 1) хранить схемы данных на сервере; 2) увеличивает объём на треть при упаковке в base64; 3) делает сообщение полностью нечитаемым без инструментов; 4) при потере или искажении символа затрудняет восстановление части данных. CJON читается даже если половина данных повредилась.
Большая часть данных в CJON не упаковывается base64, т.к. соответствует кодировке GSM Bit-7 и передается компактно. А для большей оптимизации я уже реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t, latitude - l... так что упаковка будет лучше, чем в proto, а главное проще для реализации.
По сути это чуть более компактный YAML Flow. Без лишних кавычек и скобочек.
nuclight
03.08.2025 17:34реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t
Хардкод вместо расширяемых словарей? Весело...
чуть более компактный YAML
В YAML из хорошего только модель данных (например, тип как строка, в CBOR вместо этого числовые теги, что неудобно), остальное лучше делать иначе...
nuclight
03.08.2025 17:34А кто этот формат из полученной SMS декодировать будет? Всё-таки машина? Ну а смысл тогда...
eagleivg
03.08.2025 17:34А ещё вопрос про сравнение - как насчет ANS.1 ?
bormee Автор
03.08.2025 17:34Это чудесный распространённый машиночитаемый формат, но не для данной задачи. Еще раз уточню - задача передавать упакованные небольшие информационные пакеты (управляющие сигналы, статус устройств, команды) короткими сообщениями или посредством голосовых каналов (в том числе радио) с использованием модуляции DTMF на сервер. Когда отсутствует интернет канал
nuclight
03.08.2025 17:34Только ASN.1, и этот ужас давно пора закопать. Там вариации парсеров уже на OID начинаются, не говоря уже обо всём остальном, что ведёт к бесконечной череде дыр в реализациях до сих пор...
BugM
03.08.2025 17:34Говорят gzip давно изобрели. И даже zstd сделали.
Смысл сравнивать непожатый размер? Все жмется перед передачей.
bormee Автор
03.08.2025 17:34По sms вы бинарный формат не передадите. У меня задача передавать данные по GSM и работать в пределах кодировки GSM 7-bit.
BugM
03.08.2025 17:34Кажется что передача данных по смс это настолько редкий и узкий кейс что стоит сделать свой формат для каждого конкретного случая.
Там все это не нужно. Передаем координаты: ну так и передайте lat:xxx lon:yyy и тому подобное
VMarkelov
03.08.2025 17:34Возможно пропустил, но повторное просматривание текста не помогло. Как в CJON кодируются массивы объектов? В примере видел только вариант "массив однотипных элементов примитивов". Скажем, из примера выше про такси куда/откуда/тариф считается, что тариф один. Но например, цена за километр может отличаться от того, что точка два идёт, к примеру, через платный участок дороги и там к тарифу будет ещё доплата. Как это всё кодировать в CJON? В том же JSON просто можно список объектов прикрутить с опциональными полями: "{ways: [ { from: 1, to: 2}, {from: 1, to: 3, extra_pay: 200}], tarif: 2 }". Или такое предлагается всегда вбивать массив extra, даже если оно надо только одному элементу, а отправитель и получатель должны корректно интерпретировать полученный набор? Правда, в этом случае уже не факт, что CJON всегда будет короче JSON
Edit: про вложенные массивы тоже интересно, как их описывать. Если таковые вообще используются. Хотя, вложенные массивы можно реализовать через одномерные при условии, что клиент и сервер знают об этом. Это опять же сводится тогда к указанию типа сообщения и некторому усложнению кода сервера и клиента.
bormee Автор
03.08.2025 17:34Все верно, только нотация JSON всегда требует наличия кавычек как минимум. Вложенность реализуется 2 способами: для небольшого количества объектов посредством сериализации ключей (taxi.tarif...) или как в JSON. Я стараюсь экономить каждый символ, поэтому это бывает важно.
artptr86
03.08.2025 17:34Проще парсить: split('=') быстрее и надёжнее, чем обработка : без кавычек.
msg=~0KHRgtGD0LrQsNC70LjQvSDQkNC70LXQutGB0LXQuQ==Всё же странно, что вы выбрали не двоеточие, а знак равенства, который используется в base64.
bormee Автор
03.08.2025 17:34Долго думал над этим, но чтобы не запутать пользователей, что якобы это JSON, решил все-таки выбрать =. "==" в конце парсингу не мешает никак.
Sipaha
03.08.2025 17:34
человекочитаемый формат.... bormee Автор
03.08.2025 17:34Все верно, почти. Задача, которую я решал в первую очередь - передавать относительно небольшие структуры с оптимизацией передачи в аналоговых сетях. Сложные и большие структуры передавать в таком виде, конечно же не нужно. По сути CJON - это немного очищенный и капельку оптимизированный JSON, позволяющий закодировать структуры данных в смски.
nuclight
03.08.2025 17:34А теперь с CBOR сравните, и тоже со сжатием...
Sipaha
03.08.2025 17:34Сравнивал в рамках своего проекта. CBOR в сыром виде конечно на порядок компактнее json'а, но очень слабо поддается сжатию (видимо хорошо продуман и минимизирован). На выходе сжатый json получался +/- того же размера что и сжатый cbor (разница примерно +/-5%)
medvedmike
03.08.2025 17:34CJON устраняет кавычки, скобки и пробелы, тем самым экономя от 30% до 50% символов;
YAML делает тоже самое, при этом оставаясь читаемым для человека.
Не уверен, что CJON способен сравниться по читаемости с JSON или YAML даже близко. Давайте попробуем рассмотреть реальные prod-like примеры, а не "на кошках".
Ну а если готовы жертвовать читаемостью в угоду размера и скорости серилизации, то не вижу причин не использовать бинарные форматы вроде protobuf или avro
bormee Автор
03.08.2025 17:34Очень правильное замечание - в точку. Признаться честно, я сперва хотел использовать yaml и просто упростил с учетом своей задачи:
yaml:
{L1,device:{id:station-17},log:{msg:"~0KHQuNGB0YLQtdC80LAg0L/QtdGA0LXQt9Cw0LPRgNGD0LbQtdC90LA=",level:warning,code:WX123},ts:"2025-07-29T11:12:00Z"}cjon:
L1;device{id=station-17};log{msg=~0KHQuNGB0YLQtdC80LAg0L/QtdGA0LXQt9Cw0LPRgNGD0LbQtdC90LA=;level=warning;code=WX123};ts=2025-07-29T11:12:00Z
CJON по сравнению c YAML: не требует кавычек, скобок и отступов, работает в одной строке, оптимизирован под текстовую передачу в условиях ограниченного канала.
yaml:{T1,u:bob,p:"~cGFzc3cwcmQ=",loc:[56.3,36.7],dev:{id:d42,st:ok},ev:[{t:start,c:1},{t:stop,c:2}]}
cjon:
T1;u=bob;p=~cGFzc3cwcmQ=;loc=56.3,36.7;dev{id=d42;st=ok};ev{{t=start;c=1};{t=stop;c=2}}
vlw
03.08.2025 17:34Зачем изобретать велосипед? В чем проблема использовать protobuf? Лучший бинарный формат. Если надо передавать в смс - завернуть его в base64. Читаемость у данного творения все равно сомнительная.
bormee Автор
03.08.2025 17:34Думал об этом, но для поставленной задачи придется 1) хранить схемы данных на сервере; 2) увеличивает объём на треть при упаковке в base64; 3) делает сообщение полностью нечитаемым без инструментов; 4) при потере или искажении символа затрудняет восстановление части данных. CJON читается даже если половина данных повредилась.
Большая часть данных в CJON не упаковывается base64 и передается компактно. А для большей оптимизации я уже реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t, latitude - l... так что упаковка будет лучше, чем в proto, а главное проще для реализации.
akovalenko
03.08.2025 17:34А в контексте вашей задачи точно нельзя передавать бинарные данные в SMS? Ставите в TP-DCS 8-bit data и вперёд, 140 полновесных байт.
Ну и если вдруг нельзя, то логичнее base128 организовать на базе 7-bit GSM alphabet, всё ж поэкономнее.
А в бинарном пейлоуде тогда можно будет и protobuf, и cbor, и компрессию...
bormee Автор
03.08.2025 17:34Очень крутое предложение, да, это решение, но помимо SMS я хочу иметь альтернативную передачу данных по голосовому каналу в модулированном виде. Про тип смс честно не знал, буду экспериментировать. Спасибо большое. Про base128 я не очень понял вашу мысль? Я base64 кодирую только текст, который не влезает в 7-bit. Остальное не упаковываю никак - зачем, все уже соответствует кодировке. Поясните мысль, пожалуйста.
akovalenko
03.08.2025 17:34Про base128: у вас, как я понял, семибитный gsm alphabet сейчас используется, можно взять бинарный payload и распилить его по семибитным границам. Получится те же 140 байт, которые получились бы с TP-DCS 8-bit. Это лишние телодвижения, которые могут быть оправданы, когда например модем с какой-то стороны не умеет SMS PDU MODE.
Как я понял, при передаче по DTMF вы уже полученное семибитное пакуете в base12. Но ведь точно так же вы могли бы и 8bit бинарное паковать!
Так что правильный ответ на «почему не protobuf» всё же скорее «мне весело было придумать CJON» (и ничего в этом плохого не вижу), чем «protobuf не влезает в 8bit, а protobuf+base64 неэкономно)
nuclight
03.08.2025 17:34Что значит зачем, для сжатия же. Например, если делать Variable-Length Integer на 7-битном алфавите, пусть старший (6-й) будет как бит продолжения. Тогда в двух символах можно закодировать число до 2047, тогда как в десятичном это аж 4 символа.
nuclight
03.08.2025 17:34Это крайне забавно. Я участвую в CBOR WG в IETF, причем как раз по вопросам дальнейшего сжатия (и так более компактного нежели JSON формата) - имелся как свой у них draft-cbor-packed с фокусом на распаковке constrained IoT-нодой без промежуточного буфера (там всё плохо с памятью как на данные, так и на код); так и я со своим CBAR, делавшимся из других вводных - он делался для транспортного (L4/L5, как TCP или QUIC) протокола muSCTP, предназначенного выживать на пакетах минимум 24 байта (в общем-то пересекается с озвученными в статье областями применения); базовая идея у обоих в общем-то одна - сжать повторяющиеся ключи. Сначала я пробовал на нибблах и секстетах свой формат слепить, потом решил, что на типичном куске 9 vs 10 байт (или 10 vs 11, уж не помню) выгода от экономии не перевешивает сложности имплементации, тестов и т.д. нового формата: куда лучше сделать специфический компрессор для common формата (т.е. приложения смогут пользоваться расширенной моделью данных JSON), а пару лет назад мне еще подсказали компактную либу (Compress::LZF), в смысле добавить два уровня (две фазы) паковки. Идут баталии в мэйллисте насчет недостатков cbor-packed, появляются новые идеи по хитростям увеличения компрессии на базе примера DNS-CBOR (да, в процессе драфт и такого RFC)...
И тут появляется какой-то
пижонСиджон, начисто игнорирует годы рисёрча людей, и заявляет - а давайте делать это ТЕКСТОМ, более того, в base64! BASE64, Карл!!! Я аж подавился и пролистал в начало статьи - это точно не первое апреля?!.. При этом в постановке задачи кроме очерчивания области нет толком вообще ничего, альтернативные форматы упомянуты - но самого сравнения-то нет! (а CBOR, между прочим, четко сформулировал иерархию целей и на каждый сравниваемый формат, в т.ч. MessagePack, который был ближе всего, потратил несколько абзацев, почему это не подходит).Более того, в постановке задачи даже АЛФАВИТА нет! Из упоминания DTMF (что? он же явно не первичен как определяющий, а будет ниже слоем рекодинга, смысл-то) и SMS можно догадаться, что предполагается не 8-битный канал. Но валидный набор символов не озвучен (я вспоминаю одну странную штуку с алфавитом на 45, из QR-кодов штоль). Можно предположить, однако, что прекрасно подойдёт как минимум base85, а возможно что и наработки времён Fido по произвольным чарсетам (не помню как звали, creeper что ли). Наконец, снова смотреть на возможности канала - мне что-то попадалось насчет кодировки типа baseN, рассчитанной на UTF-8 строку (аналогично можно для неполного UCS-2 придумать).
Далее, человекочитаемым ему быть совершенно незачем, это тоже вредит сжатию. Ему нужно быть лишь человекоотлаживаемым (например, подбором удобных значения для hexdump'ов), а это другое. Нет, способность к восстановлению при повреждениях необязательно требует текстовости формата, её можно вполне обеспечить в бинарном (кстати, в полном 7-битном репертуаре там еще символы 0-31 есть, на минуточку) - это свойство даже у UTF-8 есть (хоть и на уровне отдельных символов, а не более объемлющего структурного формата).В общем, уровня поиграться "смотрите как я пиарюсь очередным велосипедом" - может быть. В качестве серьезного формата - точно нет, не надо этому CJON засорять инфопространство - лучше направлять усилия туда, где люди уже занимаются проблемой.
bormee Автор
03.08.2025 17:34Улыбнуло ваше возмущение. Я прекрасно понимаю и принимаю вашу критику, да я пижон, да я решаю проблему в лоб как умею и как мне проще, да невнятно описал задачу и формат описал недостаточно академично - простите, времени не было, а главное - рано, идею я не хочу чтобы увели.
Но ошибки в предложенном формате нет, как я выше написал, по сути это тот же YAML, только чуть упрощенный.
Но вы, несомненно, понимаете, что пишете и спасибо вам за работу и критику. Если вам что-то из вышесказанного пригодится в работе вашего уважаемого консорциума - вэлкам =) p.s. Название CJON же крутое, да?
ncix
03.08.2025 17:34Если вы все равно передаёте тип, и можно обеспечить строгую типизацию на приемнике и передатчике, то дальше ключи не нужны, только значения
bormee Автор
03.08.2025 17:34Как дополнительную опцию можно сделать возможность передачи значений без ключей. Я подумаю над предложением. Что-то типа T1;A;B;B и парсить это как { "cjon": "T1", "k1": "A", "k2": "B", "k3" : "B" } и на сервере разбирать ключи и заменять их правильными. Пожалуй, это будет полезным в случаях плоских данных аля CSV. Подумаю, спасибо.
usiqwerty
Можно подробнее про вот это
Наверно формат со спецсимволами это в целом не про передачу голосом. Интересно, что вы имеете в виду под передачей по DTMF. Там вроде как 12 разных значений определено, как с его помощью передавать что-то текстоподобное?
bormee Автор
Отличный вопрос. Я кодирую Base12