Здравствуйте, Pzz, Вы писали:
Pzz>>>ASN.1 — это для любителей садо-мазо.
M>>Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.
Pzz>Я знаю. Телефонисты немного этого ASN-а в интернет принесли. Это TLS (SSL),
TLS сам по себе как раз не ASN.1, там собственный формат сериализации.
Pzz> X.509, SNMP, LDAP...
У этих хоть BER, структура читается без схемы.
А вот в H.323 и 3GPP стандартах PER. Вот это совсем ад и сектор газы.
The God is real, unless declared integer.
Re[7]: Самый удобный человеко-читаемый язык данных
Здравствуйте, 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".
The God is real, unless declared integer.
Re[4]: Самый удобный человеко-читаемый язык данных
Здравствуйте, netch80, Вы писали:
N>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.
Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.
Re[5]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Pzz, Вы писали:
N>>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.
Pzz>Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.
Ну как бинарный формат к JSON — IETF активно продвигает CBOR. А в нём такой проблемы нет. Числа в диапазоне -24..23 минимально (и рекомендованно) представляются одним байтом, -256..255 — двумя. Вообще по сравнению со многими альтернативами он суперкомпактен.
The God is real, unless declared integer.
Re[5]: Самый удобный человеко-читаемый язык данных
Здравствуйте, netch80, Вы писали:
N>Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти
Расшифруй.
N>пользы от текстового представления — вагоны.
Ноль. В норме, тебе не нужно читать данные в сыром виде.
Ад пуст, все бесы здесь.
Re[6]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Codealot, Вы писали:
N>>Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти C>Расшифруй.
Что непонятного в оценке затрат процессора на какие-то виды работы? Что именно расшифровать?
N>>пользы от текстового представления — вагоны. C>Ноль. В норме, тебе не нужно читать данные в сыром виде.
Эта "норма" никогда не выполняется даже в обычном продуктине, а тем более в пусконаладочных работах, в отладке и разработке.
The God is real, unless declared integer.
Re[7]: Самый удобный человеко-читаемый язык данных
Здравствуйте, netch80, Вы писали:
N>Что непонятного в оценке затрат процессора на какие-то виды работы? Что именно расшифровать?
Непонятно, чем твои оценки обоснованы. Какие конкретно сценарии ты сравнивал? Бенчмарки писал?
N>Эта "норма" никогда не выполняется даже в обычном продуктине, а тем более в пусконаладочных работах, в отладке и разработке.
Прямо-таки никогда? Ты сам проверял все проекты в мире, чтобы в этом удостовериться?
Здравствуйте, netch80, Вы писали:
vsb>>Что значит "человеко-читаемый" я не очень понимаю. По-мне всё, что ASCII — одинаково человеко-читаемо.
N>Почитайте это
Я как-то в 90-е (или в нулевые?) зашел в маленькую фирмочку по продаже авиабилетов. Это было еще до тех времен, когда эту нишу заняли интернет-агрегаторы.
И там сидел мужичок и с помощью терминала лихо изъяснялся с системой по продаже билетов на каком-то вот примерно таком языке. Руками вводил запросы и свободно понимал ответы.
Видимо, к системе его подключили, а програмки с человеческим интерфейсом не дали. Но это мужика совершенно не смущало.
Здравствуйте, Shmj, Вы писали:
S>Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали XML.
S>Потом все более и более JSON.
S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Здравствуйте, korvin_, Вы писали:
k> vsb>YAML это альтернативный синтаксис для JSON.
k> Лол. Вам не кажется, что для "альтернативного синтаксиса для JSON", у YAML слишком большая спецификация по сравнению с JSON?
Здравствуйте, korvin_, Вы писали:
vsb>>YAML это альтернативный синтаксис для JSON.
_>Лол. Вам не кажется, что для "альтернативного синтаксиса для JSON", у YAML слишком большая спецификация по сравнению с JSON?
Это не имеет значения. Во-первых JSON это подмножество YAML, т.е. любой JSON документ автоматически является YAML-документом. Во-вторых любой YAML-документ однозначно преобразуется в JSON-документ. Единственное исключение это YAML Fragments, это когда в одном файле можно задавать несколько объектов, т.е. несколько JSON-документов, по сути тривиальное расширение.
Re[2]: Самый удобный человеко-читаемый язык данных
A>Еще один хороший вариант — это JavaScript/TypeScript в качестве языка конфигурации. Преимущество в том, что если нужно обьявить, например, переменную, а затем её использовать несколько раз в разных местах конфигурации, то это делается штатными средствами языка:
Кстати на php конфиги тоже неплохие.
(для всяких там веб-приложений, написанных на php)
Re[2]: Самый удобный человеко-читаемый язык данных
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, bobby23, Вы писали:
B>>может иероглифы, там плотность информации выше
N>Если пересчитать на биты реального содержания — нет, не выше.
B>>и такой протокол B>>
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, bobby23, Вы писали:
B>>может иероглифы, там плотность информации выше
N>Если пересчитать на биты реального содержания — нет, не выше.
китайская кракозябра короче английской
B>>и такой протокол B>>
Здравствуйте, vsb, Вы писали:
vsb>Это не имеет значения. Во-первых JSON это подмножество YAML, т.е. любой JSON документ автоматически является YAML-документом.
Да.
vsb> Во-вторых любой YAML-документ однозначно преобразуется в JSON-документ.
Нет, это прямая неправда. Настолько прямая и тупая, что непонятно, зачем вы это рассказываете — проверить можно в пять минут.
В стандарте (смотрю по последнему, 1.2.2 — это важно) есть:
1. Теги. Теги — это то, что интерпретируется парсером по своему вкусу (обычно, вызывая соответствующий конструктор типа), кроме стандартных. В JSON нет тегов.
2. Двоичные данные, тегом !!binary. В JSON аналога нет. Вложить в него можно только если ввести какое-то дополнительное условие, как именно двоичные данные будут представлены — как правило, строка в base64 или в hex, однозначности тут нет.
3. Ordered mapping, тегом !!omap. Аналога в JSON нет. Даже если основные реализации в основных языках (JS, Python) автоматически используют именно ordered mapping (LinkedHashSet), реального такого требования нет.
Во-вторых: об однозначности преобразования можно говорить только после того, как показана однозначность парсинга, а тут уже наблюдаются несовместимые различия между версиями стандарта YAML.
As it turns out, numbers from 0 to 59 separated by colons are sexagesimal (base 60) number literals. This arcane feature was present in yaml 1.1, but silently removed from yaml 1.2, so the list element will parse as 1342 or "22:22" depending on which version your parser uses. Although yaml 1.2 is more than 10 years old by now, you would be mistaken to think that it is widely supported: the latest version libyaml at the time of writing (which is used among others by PyYAML) implements yaml 1.1 and parses 22:22 as 1342.
Только не надо рассказывать про то, что все обязаны были сразу перейти на последнюю версию — это так не работает. Там же дальше:
The change from yaml 1.2.1 to 1.2.2 on the other hand, was a multi-year effort by a team of experts
И это, да, прямое следствие "слишком большой" спецификации, когда люди не в состоянии оценить все последствия того, что они туда напихали. Стандарты YAML чудовищно переусложнены непонятно зачем и это даёт реальные проблемы.
Вероятно, вы используете одну версию парсера и совместимый с ней генератор, или же намеренно ограничиваете возможности только человекобезопасными синтаксисами. Тогда вы могли проскочить и не заметить ни одной из этих проблем. Но не надо рассказывать, что их нет.
The God is real, unless declared integer.
Re[4]: Самый удобный человеко-читаемый язык данных
Здравствуйте, bobby23, Вы писали:
B>китайская кракозябра короче английской
Если вы станете записывать английские слова блоками по 4-6-9 букв в одном "символе", как эквивалент того, что творят в китайской письменности — английский текст будет ещё короче. Ну да, вам потребуется нагенерировать, как в китайском, пару десятков тысяч таких символов на основные допустимые сочетания.
A qui br fo jum ov t la do
ck own x ps er he zy g
N>>А смысл?
B>думаю плотнее, любая китайская кракозябра короче английской
Вопрос был про тот пример, где "0.1.0.node=valuexxx", а не про китайщину. Итак?
