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

Pzz>или придется использовать хитрый формат переменного размера.

Тоже мне, сложность. Хотя для смузихлебов может быть.

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

νsb>>Размер надо сравнивать после gzip-а. Скорость — скорей всего недоработка реализации. В целом не вижу места никаким форматам общего назначения кроме JSON.

Pzz>А совсем недавно сегодняшние любители JSON-а в целом не видели места никаким форматам общего назначения, кроме XML...

XML плохой формат для структур данных, т.к. он не соответствует этим самым структурам данных. JSON в этом плане лучше. Для разметки текста XML может и годится.

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

S> Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
S>По сути, возврат к тому же CSV, но в одном файле можно описать несколько структур разного формата.
Это извращение какое-то not invented here. Осталось написать к этому чуду парсеры-форматтеры на всех ЯП, интегрировать синтаксис во все IDE и всякие тулзы — вот тогда норм.

S>По скорости когда- то мерял, сериализация / десериализация по скорости в районе 400 Mb/c.
S>Но без всяких reflection.
S>От идеи бинарного формата давно отказался, по причинам , которые уже объяснили.
Переставь кавычки и получится простейший json.

S>    "CanWrite": [1,1,1,1,1,1,1],
S>    "Rows": [
S>        [0,"analog_0",0,0,10,90,18],
S>        [1,"analog_1",0,1,10,90,97],
S>}

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

BFE>Следующие строки в Json эквивалентны: "12345" и "\u00312345". Вы уверены, что клиентский код должен об этом знать?

А я говорил, что должен?
Клиентский код должен знать что ему нужно в итоге получить: int, float, string,...

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

Pzz>>или придется использовать хитрый формат переменного размера.

C>Тоже мне, сложность. Хотя для смузихлебов может быть.

А для нас, настоящих мужчин, только ASN.1, только хардкор?

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

vsb>XML плохой формат для структур данных, т.к. он не соответствует этим самым структурам данных. JSON в этом плане лучше. Для разметки текста XML может и годится.

Однако используют его в основном для структур данных...

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

vsb>>XML плохой формат для структур данных, т.к. он не соответствует этим самым структурам данных. JSON в этом плане лучше. Для разметки текста XML может и годится.

Pzz>Однако используют его в основном для структур данных...

Я не знаю, зачем, если есть выбор. Я с XML работал больше, чем мне хотелось бы, и по своей воле я его редко где выберу.

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

BFE>>Следующие строки в Json эквивалентны: "12345" и "\u00312345". Вы уверены, что клиентский код должен об этом знать?
K>А я говорил, что должен?
K>Клиентский код должен знать что ему нужно в итоге получить: int, float, string,...
json это способ сериализации структур в байтики. Притом не самый лучший. А то, о чём ты говоришь — это определение структур данных. Нужно брать какой-нибудь avro/protobuf/sbe/etc.

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

Pzz>А для нас, настоящих мужчин, только ASN.1, только хардкор?

Совсем хардкор не надо, но переменный размер — это элементарщина.

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

·>json это способ сериализации структур в байтики. Притом не самый лучший. А то, о чём ты говоришь — это определение структур данных. Нужно брать какой-нибудь avro/protobuf/sbe/etc.

То, о чём я говорю, реализовано в той же JSON.NET. Файл успешно читается, если является валидным json, а потом падает, если клиентский код хочет int, а в json записана строка (ну, можно дополнительных конвертеров навесить, чтобы получить нужный результат). В процессе чтения библиотека не пытается определять что там записано: целое число, вещественное или строка.

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

Pzz>>А для нас, настоящих мужчин, только ASN.1, только хардкор?

C>Совсем хардкор не надо, но переменный размер — это элементарщина.

Он чего-то стоит, в плане CPU

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

Pzz>Он чего-то стоит, в плане CPU

С лихвой компенсируется экономией на дисковых операциях. Тебе это было не очевидно?

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

Pzz>>Он чего-то стоит, в плане CPU

C>С лихвой компенсируется экономией на дисковых операциях. Тебе это было не очевидно?

Это если я упираюсь в дисковые операции

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

vsb>XML плохой формат для структур данных, т.к. он не соответствует этим самым структурам данных.
Шта?

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

BFE>Не совсем понятно, что именно должен делать в таком случае парсер, что выдавать в качестве результата. Строку с пометкой "это Json число"?
Никаких пометок. Просто тупо строки as is. Клиент пусть сам разбирается что ему надо было.

BFE>закодировали в BASE64, в полученной строке заменили '=' на '\u003D'
Терминаторы в общем то опциональны.

BFE> результат положили в виде строкового значения в Json файл.
Ну и чо? Пусть на принимающей стороне сами с этим долбятся. Задача именно что парсера — поделить это всё на "токены" и скормить коду импорта. Не стоит в парсер добавлять лишние сущности, от этого только лишние проблемы.

BFE> Ага, Json ведь для того и придуман, чтобы передавать данные в человекочитаемом виде.
А по факту передают там что угодно. Ибо молоток и гвоздь.

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

Pzz>А совсем недавно сегодняшние любители JSON-а в целом не видели места никаким форматам общего назначения, кроме XML...

Ты отстал от жизни. Любители JSON уже переключились на YAML, JSON нынче легаси.

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

K>·>json это способ сериализации структур в байтики. Притом не самый лучший. А то, о чём ты говоришь — это определение структур данных. Нужно брать какой-нибудь avro/protobuf/sbe/etc.
K>То, о чём я говорю, реализовано в той же JSON.NET. Файл успешно читается, если является валидным json, а потом падает, если клиентский код хочет int, а в json записана строка (ну, можно дополнительных конвертеров навесить, чтобы получить нужный результат). В процессе чтения библиотека не пытается определять что там записано: целое число, вещественное или строка.
Т.е. по факту в json все скаляры — строки, а потом уже в коде "удобная" обёртка над parseInt/parseDouble/etc. В самом json информация о типах не предусмотрена.

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

·>Т.е. по факту в json все скаляры — строки, а потом уже в коде "удобная" обёртка над parseInt/parseDouble/etc. В самом json информация о типах не предусмотрена.

json — строковый формат и там изначально всё равно будет строка и последующая конвертация.
Не вижу смысла городить какие-то "угадыватели", что вот тут в json написано "param":"123" — это строка, а вот в другом месте "param":123 — это уже int.
В итоге окажется, что в клиентском коде нужен float и получим вместо прямого конвертера string -> float цепочку преобразований string -> int -> float.
И все эти конвертеры будут плодиться в геометрической прогрессии и непонятно что это даёт.
А может вообще клиенту этот параметр не нужен и конвертацию можно было и не выполнять.

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

K>·>Т.е. по факту в json все скаляры — строки, а потом уже в коде "удобная" обёртка над parseInt/parseDouble/etc. В самом json информация о типах не предусмотрена.
K>json — строковый формат и там изначально всё равно будет строка и последующая конвертация.
K>Не вижу смысла городить какие-то "угадыватели", что вот тут в json написано "param":"123" — это строка, а вот в другом месте "param":123 — это уже int.
По сути это просто два разных способа закодировать одно и то же. И в парсере json.net (и многих других) эти два представления будут неразличимы с точки зрения клиентского кода.

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

·>По сути это просто два разных способа закодировать одно и то же. И в парсере json.net (и многих других) эти два представления будут неразличимы с точки зрения клиентского кода.

С точки зрения клиента нет никакой разницы, кроме того, что он может получить какие-нибудь лишние ошибки парсинга параметров, которые ему и не были нужны.
С точки зрения реализации огромная разница и я не понимаю смысл усложнения парсера.