Здравствуйте, Pzz, Вы писали:

Pzz>>>ASN.1 — это для любителей садо-мазо.

M>>Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.

Pzz>Я знаю. Телефонисты немного этого ASN-а в интернет принесли. Это TLS (SSL),

TLS сам по себе как раз не ASN.1, там собственный формат сериализации.

Pzz> X.509, SNMP, LDAP...

У этих хоть BER, структура читается без схемы.

А вот в H.323 и 3GPP стандартах PER. Вот это совсем ад и сектор газы.

Здравствуйте, netch80, Вы писали:

N>А вот в H.323 и 3GPP стандартах PER. Вот это совсем ад и сектор газы.

Вопчем, враги, маньяки и диверсанты.

Здравствуйте, vsb, Вы писали:

vsb>Что значит "человеко-читаемый" я не очень понимаю. По-мне всё, что ASCII — одинаково человеко-читаемо.

Почитайте это

Автор: Слава
Дата: 19.11.15

, например

Или как устроены описания структур данных в Cobol и RPG.

Сразу мифы будут развеяны.

vsb> По этому критерию и XML и JSON и YAML человеко-читаемы.

Да, это поколение уже читаемо.

Здравствуйте, Pzz, Вы писали:

vsb>>Отсутствие вменяемой общепринятой спецификации. К примеру простые вопросы. Какие числа можно передавать? Что происходит при дублировании ключей? Это отдаётся на откуп конкретной реализации, что вызывает проблемы при взаимодействии, к примеру в JS целые числа ограничечны 2^52.
Pzz>Сам спросил, сам ответил. 2^52 же. Числа в JSON — это 64-битный float в формате IEEE 754, и это от JS так пошло.

Но в стандарте JSON этого ограничения нет. Есть пожелание типа "поскольку большинство диверсантов реализует числа через IEEE754 double, выход за его пределы чреват боком". Но это не требование.

А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.

Поэтому JSON таки диверсия.

vsb>>Не специфицирована кодировка текста, т.е. нет однозначного отображения объекта в байты, только в строку.
Pzz>UTF-8 же.

Ну 8259 на этом настаивает, да, а вот предыдущий 7159 — нет.

Pzz>Раздражает, что нет синтаксиса для передачи бинарных данных (массива байт).

Да, нужен base64, base32, hex, или любой из них. Увы.

Интересно, что в CBOR сделали наоборот. Он бинарный, но к типу bytestring можно прилепить тег "в текстовом виде это должно быть base64".

Здравствуйте, netch80, Вы писали:

N>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.

Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.

Здравствуйте, Pzz, Вы писали:

N>>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.

Pzz>Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.

Ну как бинарный формат к JSON — IETF активно продвигает CBOR. А в нём такой проблемы нет. Числа в диапазоне -24..23 минимально (и рекомендованно) представляются одним байтом, -256..255 — двумя. Вообще по сравнению со многими альтернативами он суперкомпактен.

Здравствуйте, netch80, Вы писали:

N>Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти

Расшифруй.

N>пользы от текстового представления — вагоны.

Ноль. В норме, тебе не нужно читать данные в сыром виде.

Здравствуйте, Codealot, Вы писали:

N>>Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти
C>Расшифруй.

Что непонятного в оценке затрат процессора на какие-то виды работы? Что именно расшифровать?

N>>пользы от текстового представления — вагоны.
C>Ноль. В норме, тебе не нужно читать данные в сыром виде.

Эта "норма" никогда не выполняется даже в обычном продуктине, а тем более в пусконаладочных работах, в отладке и разработке.