1) GSM64=BASE64 только с немного измененным алфавитом, я заменил символы +/= на *-_ чтобы избежать ESC и передавать одним септетом.
2) Сперва добавил, потом убрал. CBOR без сортировки ключей.
3) Примеры от балды сделаны, просто похожие на что-то структуры собрал и все. Типы и словари для них буду позднее собирать, когда уже для решения конкретных задач буду использовать. На этапе прототипа это излишне.
4) Про системы и оборудование позднее опишу, если вам интересно, отдельно скину, если все получится как задумано. Пока под NDA не могу разглашать.
Спасибо вам за помощь, много полезного от вас увидел и прочитал. Ну и формат прилично так доработан.
https://stukalin.com/cbor.html - если интересно, посмотрите, доработал конвертер, изменил правила формирования полей. CBOR формирую и упаковываю. Показываю и сравниваю размеры. Опционально добавил формирование словаря ключей. CBOR в среднем на 3-5% компактнее, по после кодирования GSM64 становится больше и проигрывает CJON. На тестах постоянно возникает неоднозначность и приходится латать парсер. Сейчас более или менее стабильно работает. Думаю зафиксироваться и продолжить эксперименты с передачей живых данных.
Я решаю сейчас задачу таким образом. Ввел операторы. Теперь у меня оператор определяет тип. "=" - ничего не меняем, считаем на парсинге, что там ничего запрещенного нет и транслируем как есть; ~ - GSM64 (я выбрал безопасный алфавит); # - целое base36; @ - unixtime base36 +/- смещение в четверти часа тоже base36; ^ - ISO дата в виде эпохи со смещение в base36; ! - boolean с одним из 4 значений (T/F/N/U). Если массив содержит значения без ключей и одного типа, то применим один оператор для всего массива, если хоть одно значение другого типа, то = и для каждого элемента, кроме соответсвующего = ставим его тип в виде оператора. От HEX в цифрах я отказался, для текстового формата плохо. Допилю пример - пришлю.
Прошу прощения, вношу правки и отлаживаю. Есть много изменений я вам пришлю, если интересно и опишу правила новые. Пока получается на практике короче упакованного CBOR за исключением массивов с большими числами, вот эту задачу сейчас решаю.
На странице я сразу показываю упакованный для передачи CBOR.
Да, вероятно вы правы относительно бинарных форматов и последующей сериализации с использованием алфавита GSM Bit-7. Для конкретной задачи это будет действительно важнее читаемости и простоты реализации.
CJON отложим в копилку недодуманных идей, авось где-то пригодится еще. MiniJSON же пригодился, а CJON эффективнее.
Думал про даты, для моей задачи даты действительно будут использоваться сплошь и рядом, поэтому спасибо за идею. Отбрасывая вашу неприязнь к изобретенным велосипедам, что скажете, если для дат добавить префикс, например так:
Ничего себе короткое размышление за три дня. Спасибо большое. Вы прямо очень фундаментально подошли к проблеме и очень профессионально. Вспомнились времена бауманки 1-2 курса, когда мы горячие программисты днями и неделями решали подобные задачи просто потому что это было интересно. Очень круто. Только текст в блок кода зря поместили, задолбался горизонтально скроллить.
Почти убедили меня использовать base85, но: В GSM 7‑бит многие символы из ASCII 33-126 либо отсутствуют, либо требуют ESC‑последовательности (и как следствие двойную длину): { } [ ] \ ^ ~ | и др. В SMS это критично: набор base85 должен опираться на пересечение разрешённых символов GSM‑7 без ESC, иначе мы теряем выигрыш или снова уходим в UCS‑2.
Ваше предложение отличное, но хочу заметить, что одним из главных критериев моего формата была - простота понимания. CJON читается «на глаз» и парсится простым сплитом, что сильно упрощает отладку в поле. TF7 - черный ящик. Такие ленивые профаны типа меня не захотят даже разбираться =) Я сторонник быстрых и простых достижений.
Про словарь идея отличная и именно для этого я внес типизирование блоков CJON, конечно же я буду для каждой предметной области, инфомационной системы и т.п. делать свой словарь сокращений и внедрять его. Как сделать безопасную синхронизацию на клиенте и сервере - это еще предстоит решить.
Выигрыш "Москва = 9 символов". Это статистический эффект; в худших кейсах кириллица всё равно потребует несколько знаков на букву и выигрыш может испариться.
Еще раз спасибо за размышления. Очень приятно. Предлагайте еще.
Как дополнительную опцию можно сделать возможность передачи значений без ключей. Я подумаю над предложением. Что-то типа 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. Я стараюсь экономить каждый символ, поэтому это бывает важно.
1) GSM64=BASE64 только с немного измененным алфавитом, я заменил символы +/= на *-_ чтобы избежать ESC и передавать одним септетом.
2) Сперва добавил, потом убрал. CBOR без сортировки ключей.
3) Примеры от балды сделаны, просто похожие на что-то структуры собрал и все. Типы и словари для них буду позднее собирать, когда уже для решения конкретных задач буду использовать. На этапе прототипа это излишне.
4) Про системы и оборудование позднее опишу, если вам интересно, отдельно скину, если все получится как задумано. Пока под NDA не могу разглашать.
Спасибо вам за помощь, много полезного от вас увидел и прочитал. Ну и формат прилично так доработан.
https://stukalin.com/cbor.html - если интересно, посмотрите, доработал конвертер, изменил правила формирования полей. CBOR формирую и упаковываю. Показываю и сравниваю размеры. Опционально добавил формирование словаря ключей. CBOR в среднем на 3-5% компактнее, по после кодирования GSM64 становится больше и проигрывает CJON. На тестах постоянно возникает неоднозначность и приходится латать парсер. Сейчас более или менее стабильно работает. Думаю зафиксироваться и продолжить эксперименты с передачей живых данных.
Я решаю сейчас задачу таким образом. Ввел операторы. Теперь у меня оператор определяет тип. "=" - ничего не меняем, считаем на парсинге, что там ничего запрещенного нет и транслируем как есть; ~ - GSM64 (я выбрал безопасный алфавит); # - целое base36; @ - unixtime base36 +/- смещение в четверти часа тоже base36; ^ - ISO дата в виде эпохи со смещение в base36; ! - boolean с одним из 4 значений (T/F/N/U). Если массив содержит значения без ключей и одного типа, то применим один оператор для всего массива, если хоть одно значение другого типа, то = и для каждого элемента, кроме соответсвующего = ставим его тип в виде оператора. От HEX в цифрах я отказался, для текстового формата плохо. Допилю пример - пришлю.
Прошу прощения, вношу правки и отлаживаю. Есть много изменений я вам пришлю, если интересно и опишу правила новые. Пока получается на практике короче упакованного CBOR за исключением массивов с большими числами, вот эту задачу сейчас решаю.
На странице я сразу показываю упакованный для передачи CBOR.
https://stukalin.com/cbor.html - посмотрите, если не лениво пример со сравнением. Внизу в комбобоксе можно выбрать формат.
Да, вероятно вы правы относительно бинарных форматов и последующей сериализации с использованием алфавита GSM Bit-7. Для конкретной задачи это будет действительно важнее читаемости и простоты реализации.
CJON отложим в копилку недодуманных идей, авось где-то пригодится еще. MiniJSON же пригодился, а CJON эффективнее.
Спасибо.
Думал про даты, для моей задачи даты действительно будут использоваться сплошь и рядом, поэтому спасибо за идею. Отбрасывая вашу неприязнь к изобретенным велосипедам, что скажете, если для дат добавить префикс, например так:
json:
{
"cjon": "L1",
"ts": "2024-09-06T12:32:00Z",
"start": "2024-09-06",
"birth": "06.09.24"
}
cjon:
L1;ts@1725609120;start^2024-09-06;birth_06.09.24
Ничего себе короткое размышление за три дня. Спасибо большое. Вы прямо очень фундаментально подошли к проблеме и очень профессионально. Вспомнились времена бауманки 1-2 курса, когда мы горячие программисты днями и неделями решали подобные задачи просто потому что это было интересно. Очень круто. Только текст в блок кода зря поместили, задолбался горизонтально скроллить.
Почти убедили меня использовать base85, но:
В GSM 7‑бит многие символы из ASCII 33-126 либо отсутствуют, либо требуют ESC‑последовательности (и как следствие двойную длину): { } [ ] \ ^ ~ | и др. В SMS это критично: набор base85 должен опираться на пересечение разрешённых символов GSM‑7 без ESC, иначе мы теряем выигрыш или снова уходим в UCS‑2.
Ваше предложение отличное, но хочу заметить, что одним из главных критериев моего формата была - простота понимания. CJON читается «на глаз» и парсится простым сплитом, что сильно упрощает отладку в поле. TF7 - черный ящик. Такие ленивые профаны типа меня не захотят даже разбираться =) Я сторонник быстрых и простых достижений.
Про словарь идея отличная и именно для этого я внес типизирование блоков CJON, конечно же я буду для каждой предметной области, инфомационной системы и т.п. делать свой словарь сокращений и внедрять его. Как сделать безопасную синхронизацию на клиенте и сервере - это еще предстоит решить.
Выигрыш "Москва = 9 символов". Это статистический эффект; в худших кейсах кириллица всё равно потребует несколько знаков на букву и выигрыш может испариться.
Еще раз спасибо за размышления. Очень приятно. Предлагайте еще.
Как дополнительную опцию можно сделать возможность передачи значений без ключей. Я подумаю над предложением. Что-то типа 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. Я стараюсь экономить каждый символ, поэтому это бывает важно.