Как дополнительную опцию можно сделать возможность передачи значений без ключей. Я подумаю над предложением. Что-то типа T1;A;B;B и парсить это как { "cjon": "T1", "k1": "A", "k2": "B", "k3" : "B" } и на сервере разбирать ключи и заменять их правильными. Пожалуй, это будет полезным в случаях плоских данных аля CSV. Подумаю, спасибо.
Улыбнуло ваше возмущение. Я прекрасно понимаю и принимаю вашу критику, да я пижон, да я решаю проблему в лоб как умею и как мне проще, да невнятно описал задачу и формат описал недостаточно академично - простите, времени не было, а главное - рано, идею я не хочу чтобы увели.
Но ошибки в предложенном формате нет, как я выше написал, по сути это тот же YAML, только чуть упрощенный.
Но вы, несомненно, понимаете, что пишете и спасибо вам за работу и критику. Если вам что-то из вышесказанного пригодится в работе вашего уважаемого консорциума - вэлкам =) p.s. Название CJON же крутое, да?
Очень крутое предложение, да, это решение, но помимо SMS я хочу иметь альтернативную передачу данных по голосовому каналу в модулированном виде. Про тип смс честно не знал, буду экспериментировать. Спасибо большое. Про base128 я не очень понял вашу мысль? Я base64 кодирую только текст, который не влезает в 7-bit. Остальное не упаковываю никак - зачем, все уже соответствует кодировке. Поясните мысль, пожалуйста.
Ниже уже отвечал. думал об этом, но для поставленной задачи придется 1) хранить схемы данных на сервере; 2) увеличивает объём на треть при упаковке в base64; 3) делает сообщение полностью нечитаемым без инструментов; 4) при потере или искажении символа затрудняет восстановление части данных. CJON читается даже если половина данных повредилась.
Большая часть данных в CJON не упаковывается base64, т.к. соответствует кодировке GSM Bit-7 и передается компактно. А для большей оптимизации я уже реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t, latitude - l... так что упаковка будет лучше, чем в proto, а главное проще для реализации.
По сути это чуть более компактный YAML Flow. Без лишних кавычек и скобочек.
CJON по сравнению c YAML: не требует кавычек, скобок и отступов, работает в одной строке, оптимизирован под текстовую передачу в условиях ограниченного канала.
Думал об этом, но для поставленной задачи придется 1) хранить схемы данных на сервере; 2) увеличивает объём на треть при упаковке в base64; 3) делает сообщение полностью нечитаемым без инструментов; 4) при потере или искажении символа затрудняет восстановление части данных. CJON читается даже если половина данных повредилась.
Большая часть данных в CJON не упаковывается base64 и передается компактно. А для большей оптимизации я уже реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t, latitude - l... так что упаковка будет лучше, чем в proto, а главное проще для реализации.
Это чудесный распространённый машиночитаемый формат, но не для данной задачи. Еще раз уточню - задача передавать упакованные небольшие информационные пакеты (управляющие сигналы, статус устройств, команды) короткими сообщениями или посредством голосовых каналов (в том числе радио) с использованием модуляции DTMF на сервер. Когда отсутствует интернет канал
Все верно, почти. Задача, которую я решал в первую очередь - передавать относительно небольшие структуры с оптимизацией передачи в аналоговых сетях. Сложные и большие структуры передавать в таком виде, конечно же не нужно. По сути CJON - это немного очищенный и капельку оптимизированный JSON, позволяющий закодировать структуры данных в смски.
Все верно, только нотация JSON всегда требует наличия кавычек как минимум. Вложенность реализуется 2 способами: для небольшого количества объектов посредством сериализации ключей (taxi.tarif...) или как в JSON. Я стараюсь экономить каждый символ, поэтому это бывает важно.
Как дополнительную опцию можно сделать возможность передачи значений без ключей. Я подумаю над предложением. Что-то типа T1;A;B;B и парсить это как { "cjon": "T1", "k1": "A", "k2": "B", "k3" : "B" } и на сервере разбирать ключи и заменять их правильными. Пожалуй, это будет полезным в случаях плоских данных аля CSV. Подумаю, спасибо.
Улыбнуло ваше возмущение. Я прекрасно понимаю и принимаю вашу критику, да я пижон, да я решаю проблему в лоб как умею и как мне проще, да невнятно описал задачу и формат описал недостаточно академично - простите, времени не было, а главное - рано, идею я не хочу чтобы увели.
Но ошибки в предложенном формате нет, как я выше написал, по сути это тот же YAML, только чуть упрощенный.
Но вы, несомненно, понимаете, что пишете и спасибо вам за работу и критику. Если вам что-то из вышесказанного пригодится в работе вашего уважаемого консорциума - вэлкам =) p.s. Название CJON же крутое, да?
Очень крутое предложение, да, это решение, но помимо SMS я хочу иметь альтернативную передачу данных по голосовому каналу в модулированном виде. Про тип смс честно не знал, буду экспериментировать. Спасибо большое. Про base128 я не очень понял вашу мысль? Я base64 кодирую только текст, который не влезает в 7-bit. Остальное не упаковываю никак - зачем, все уже соответствует кодировке. Поясните мысль, пожалуйста.
Ниже уже отвечал. думал об этом, но для поставленной задачи придется 1) хранить схемы данных на сервере; 2) увеличивает объём на треть при упаковке в base64; 3) делает сообщение полностью нечитаемым без инструментов; 4) при потере или искажении символа затрудняет восстановление части данных. CJON читается даже если половина данных повредилась.
Большая часть данных в CJON не упаковывается base64, т.к. соответствует кодировке GSM Bit-7 и передается компактно. А для большей оптимизации я уже реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t, latitude - l... так что упаковка будет лучше, чем в proto, а главное проще для реализации.
По сути это чуть более компактный YAML Flow. Без лишних кавычек и скобочек.
Очень правильное замечание - в точку. Признаться честно, я сперва хотел использовать 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}}
Думал об этом, но для поставленной задачи придется 1) хранить схемы данных на сервере; 2) увеличивает объём на треть при упаковке в base64; 3) делает сообщение полностью нечитаемым без инструментов; 4) при потере или искажении символа затрудняет восстановление части данных. CJON читается даже если половина данных повредилась.
Большая часть данных в CJON не упаковывается base64 и передается компактно. А для большей оптимизации я уже реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t, latitude - l... так что упаковка будет лучше, чем в proto, а главное проще для реализации.
По sms вы бинарный формат не передадите. У меня задача передавать данные по GSM и работать в пределах кодировки GSM 7-bit.
В точку. CJON - это Франкенштейн различных форматов для решения конкретной задачи. :)
Это чудесный распространённый машиночитаемый формат, но не для данной задачи. Еще раз уточню - задача передавать упакованные небольшие информационные пакеты (управляющие сигналы, статус устройств, команды) короткими сообщениями или посредством голосовых каналов (в том числе радио) с использованием модуляции DTMF на сервер. Когда отсутствует интернет канал
Долго думал над этим, но чтобы не запутать пользователей, что якобы это JSON, решил все-таки выбрать =. "==" в конце парсингу не мешает никак.
Все верно, почти. Задача, которую я решал в первую очередь - передавать относительно небольшие структуры с оптимизацией передачи в аналоговых сетях. Сложные и большие структуры передавать в таком виде, конечно же не нужно. По сути CJON - это немного очищенный и капельку оптимизированный JSON, позволяющий закодировать структуры данных в смски.
Все верно, только нотация JSON всегда требует наличия кавычек как минимум. Вложенность реализуется 2 способами: для небольшого количества объектов посредством сериализации ключей (taxi.tarif...) или как в JSON. Я стараюсь экономить каждый символ, поэтому это бывает важно.
SMS работает в 2G сетях, а MMS нет.
Отличный вопрос. Я кодирую Base12