JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 27.11.22 18:53
Оценка:
BSON, бинарный формат — по идее должен быть компактее и быстрее.
На практике, пишем простейший массив чисел:
            var data = new int[count];
            for (var i = 0; i < data.Length; i++)
            {
                data[i] = i;
            }
            
            ...

BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

Как, вот как можно было всё настолько изгадить?
Ад пуст, все бесы здесь.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Zhendos  
Дата: 27.11.22 19:41
Оценка:
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.

C>На практике, пишем простейший массив чисел:
C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

C>Как, вот как можно было всё настолько изгадить?


BSON is also designed to be fast to encode and decode. For example, integers are stored as 32 (or 64) bit integers,


Поэтому, то что результат будет больше при записи чисел от 0 до N, неудивительно,
при N < 100, каждое число в JSON будет занимать 2 байта, а в BSON 4 байта.

А вот что это работает медленнее, это скорее претензии к C#,
почему у него простое копирование занимает времени больше чем перевод текста в число.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Константин Б. Россия  
Дата: 27.11.22 19:48
Оценка: :))
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.

C>На практике, пишем простейший массив чисел:

С чего бы ему быть компактнее

"1,2,3,4,5,6,7,8,9,10" — 20 байт
"01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 0A 00 00 00" — 40 байт
Если 64-битные числа хранить уже все 80 байт будет.

Собственно в текстовом представлении json минимум накладных расходов на самом деле.
Re[2]: JSON vs BSON: очередное торжество больного воображени
От: Codealot Земля  
Дата: 27.11.22 19:59
Оценка:
Здравствуйте, Zhendos, Вы писали:

Z>Поэтому, то что результат будет больше при записи чисел от 0 до N, неудивительно,

Z>при N < 100, каждое число в JSON будет занимать 2 байта, а в BSON 4 байта.

На самом деле, N = 0x2_000_000

Z>А вот что это работает медленнее, это скорее претензии к C#,

Z>почему у него простое копирование занимает времени больше чем перевод текста в число.

Фигня. Простая запись бинарных чисел без каких-либо попыток оптимизации получается в 4.5 раза быстрее и в 2.16 раза компактнее, чем JSON. Ну а во сколько раз быстрее и компактнее чем BSON, можно и вообще не говорить
Ад пуст, все бесы здесь.
Отредактировано 27.11.2022 20:01 Codealot . Предыдущая версия .
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 27.11.22 20:01
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>Если 64-битные числа хранить уже все 80 байт будет.


Как нетрудно убедиться из кода, числа 32-битные.
Ад пуст, все бесы здесь.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Baiker  
Дата: 27.11.22 21:36
Оценка:
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.


Непонятно, зачем он тебе вообще нужен. Гонять числа по сети? Если это СУБД, то наверняка там тонны ТЕКСТОВЫХ данных, а значит пользы от BSON ноль. Если же данные специфичные (числа), опять же зачем BSON — посмотри на задачу и подумай, может тупо записать массив в файл?
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 27.11.22 22:18
Оценка:
Здравствуйте, Baiker, Вы писали:

B>Непонятно, зачем он тебе вообще нужен.


С такими скоростями и объемами — нафиг не нужен. И я с трудом представляю, кому и зачем он такой может быть нужен
Ад пуст, все бесы здесь.
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: νsb Казахстан  
Дата: 28.11.22 00:25
Оценка: :))
Размер надо сравнивать после gzip-а. Скорость — скорей всего недоработка реализации. В целом не вижу места никаким форматам общего назначения кроме JSON.
Re: JSON vs BSON: очередное торжество больного воображения и
От: swame  
Дата: 28.11.22 08:55
Оценка: 1 (1) :)
Здравствуйте, Codealot, Вы писали:

C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.


C>Как, вот как можно было всё настолько изгадить?


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

{
    "Table": {
        "Name": "Analogs",
        "colCount": "7",
        "rowCount": "10001"
    },
    "Columns": "ID,Name,Path,Tag,Min,Max,Value",
    "CanWrite": "1,1,1,1,1,1,1",
    "Rows": [
        "0,analog_0,0,0,10,90,18",
        "1,analog_1,0,1,10,90,97",
        "2,analog_2,0,2,10,90,25",
        "3,analog_3,0,3,10,90,81",
        "4,analog_4,0,4,10,90,43",
        "5,analog_5,0,5,10,90,88",
     ...
      "9999,analog_9999,99,9999,10,90,29",
        "10000,analog_10000,100,10000,10,90,10"
    ]
}
Отредактировано 28.11.2022 8:57 swame . Предыдущая версия . Еще …
Отредактировано 28.11.2022 8:56 swame . Предыдущая версия .
Отредактировано 28.11.2022 8:55 swame . Предыдущая версия .
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: romangr Россия  
Дата: 28.11.22 11:41
Оценка:
Здравствуйте, Codealot, Вы писали:

C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.


C>Как, вот как можно было всё настолько изгадить?


Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 28.11.22 14:00
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>Собственно в текстовом представлении json минимум накладных расходов на самом деле.

Json очень сложно парсить. Я не уверен, что существует хотя бы один парсер который делает это корректно. Вот известная статья по проблемам Json.
И каждый день — без права на ошибку...
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 28.11.22 16:15
Оценка:
Здравствуйте, romangr, Вы писали:

R>Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?


А ты думаешь, что они сильно лучше?
Ад пуст, все бесы здесь.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: romangr Россия  
Дата: 28.11.22 17:21
Оценка: 1 (1)
Здравствуйте, Codealot, Вы писали:

C>А ты думаешь, что они сильно лучше?


Для сериализации массива интов что Protobuf, что MessagePack будут существенно лучше BSON,
достаточно посмотреть спецификацию — BSON, Protobuf, MessagePack.
А если нужна сериализация конкретно массивов интов, то можно смотреть что-то специфическое, типа FastPFOR
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.11.22 17:38
Оценка:
Здравствуйте, Codealot, Вы писали:

R>>Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?


C>А ты думаешь, что они сильно лучше?


Думаю, что Protobuf точно сильно лучше
Маньяк Робокряк колесит по городу
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 28.11.22 17:46
Оценка:
Здравствуйте, romangr, Вы писали:

R>Для сериализации массива интов что Protobuf, что MessagePack будут существенно лучше BSON,


Там много всего кроме массивов, просто они самые объемистые.

R>А если нужна сериализация конкретно массивов интов, то можно смотреть что-то специфическое, типа FastPFOR



Для такой примитивной задачи мне не нужны никакие библиотеки.
Ад пуст, все бесы здесь.
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 28.11.22 22:39
Оценка:
Здравствуйте, romangr, Вы писали:

R>Для сериализации массива интов что Protobuf, что MessagePack будут существенно лучше BSON,


Попробовал. Лучше чем BSON, но все равно хуже чем самый примитивный неоптимизированный велосипед.
Ад пуст, все бесы здесь.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Константин Б. Россия  
Дата: 29.11.22 06:51
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, Константин Б., Вы писали:


КБ>>Собственно в текстовом представлении json минимум накладных расходов на самом деле.

BFE>Json очень сложно парсить. Я не уверен, что существует хотя бы один парсер который делает это корректно. Вот известная статья по проблемам Json.

Вообще я имел в виду именно размер представления, но и со сложностью парсинга согласиться нельзя. Написать корректный парсер json — тривиально.
Даже хитрые тесты этого исследователя большинство реализаций проходит http://seriot.ch/json/parsing_pruned.html#all_results
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.11.22 08:17
Оценка: -1
Здравствуйте, Codealot, Вы писали:

R>>Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?


C>А ты думаешь, что они сильно лучше?


Есть большое сравнение по перформансу с этими форматам/либами. Погугли. Под рукой нет ссылки. Подозреваю, в твоем случае либа BSON сильно корявая.
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 11:17
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>>>Собственно в текстовом представлении json минимум накладных расходов на самом деле.

BFE>>Json очень сложно парсить. Я не уверен, что существует хотя бы один парсер который делает это корректно. Вот известная статья по проблемам Json.
КБ>Вообще я имел в виду именно размер представления, но и со сложностью парсинга согласиться нельзя. Написать корректный парсер json — тривиально.
КБ>Даже хитрые тесты этого исследователя большинство реализаций проходит http://seriot.ch/json/parsing_pruned.html#all_results

Размер представления — это ещё не всё. К тому же, когда размер представления зависит от данных, то могут быть сюрпризы при изменении данных.
А в накладные расходы входит сложность и корректность парсинга.

Если вы внимательно посмотрите на приведённую таблицу, то увидите, что там нет ни одного парсера удовлетворяющего следующим условиям:
1) парсер не должен падать на любых входных данных
2) парсер должен разбирать данные за конечное время
3) парсер должен успешно разбирать корректные данные

вот тут из 63 (если я правильно подсчитал) парсеров остаются только 32, т.е. половина. Причем большая часть — это разные версии одних и тех же парсеров.

Если добавить требование:
4) парсер должен выдавать ошибку, если данные не корректны, то останется 9 парсеров

И добавив последние требование:
5) для всех таких данных, для которых результат является неопределённым, парсер должен либо выдавать ошибку, либо успех. Другими словами: либо все неопределённые результаты — успех, либо ошибка, но не так, что часть данных разбираем, а для части выдаём ошибку.

В итоге получаем что нет ни одной корректной реализации.
А ещё в этих тестах рассмотрены не все случаи. Например, там не рассмотрен случай, типа 0.1E+0000000000000000000...(очень много нулей)...0001 — единица представима как число на любой платформе, а значит парсер должен (в соответствии с rfc7159) разобрать это число без ошибок даже если по длине записи данное число превышают гигабайт, скажем. Ведь здесь нет выхода ни за пределы точности, ни за лимиты представления чисел.


Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:
[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000]
И каждый день — без права на ошибку...
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Константин Б. Россия  
Дата: 29.11.22 12:02
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, Константин Б., Вы писали:


КБ>>>>Собственно в текстовом представлении json минимум накладных расходов на самом деле.


BFE>Размер представления — это ещё не всё. К тому же, когда размер представления зависит от данных, то могут быть сюрпризы при изменении данных.

Какие сюрпризы?

BFE>А в накладные расходы входит сложность и корректность парсинга.

JSON.parse(x) — для меня достаточно просто.

BFE>Если добавить требование:

BFE>4) парсер должен выдавать ошибку, если данные не корректны, то останется 9 парсеров

BFE>И добавив последние требование:

BFE>5) для всех таких данных, для которых результат является неопределённым, парсер должен либо выдавать ошибку, либо успех. Другими словами: либо все неопределённые результаты — успех, либо ошибка, но не так, что часть данных разбираем, а для части выдаём ошибку.

А теперь вопрос: зачем мне предьявлять к парсеру такие требования? Что плохого случится если парсер сможет распарсить "[NaN]" например? По спеке вроде как нельзя. Повод ли это отказываться от парсера?

BFE>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000]

Ошибку конечно же.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: scf  
Дата: 29.11.22 12:23
Оценка: +1
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.


Компактный формат, быстрый формат и формат с поддержкой обратной/прямой совместимости данных — это, как правило, три разных формата.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 29.11.22 12:43
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Как, вот как можно было всё настолько изгадить?


Так частный случай же. Я как-то сравнивал на своих реальных объектах JSON и BSON (благо там пару строк кода всего поменять нужно).
BSON был и быстрее и компактнее, чем JSON (обе реализации были от Newtonsoft).
Правда у нас в итоге победил json, упакованный в zip
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rollcoin  
Дата: 29.11.22 13:05
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000...000000000000000000000000000000000000000000]

Re[2]: JSON vs BSON: очередное торжество больного воображения и
От: Mihas  
Дата: 29.11.22 13:13
Оценка:
Здравствуйте, swame, Вы писали:

S> Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам

S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Прикольно
Работая с электронным документооборотом в бюджетной сфере, я насмотрелся всяких текстовых структурированных форматов. Запомню и этот в своей копилке возможного
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:19
Оценка:
Здравствуйте, rollcoin, Вы писали:

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000...000000000000000000000000000000000000000000]
R>Image: aekPFxJ0eeE.jpg

Забавно. Где-то потеряли 383. Это нормально?
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rollcoin  
Дата: 29.11.22 14:22
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Забавно. Где-то потеряли 383. Это нормально?


Кого потеряли? Какое 383?
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:26
Оценка:
Здравствуйте, Константин Б., Вы писали:

BFE>>Размер представления — это ещё не всё. К тому же, когда размер представления зависит от данных, то могут быть сюрпризы при изменении данных.

КБ>Какие сюрпризы?
Разные. Буфера не хватит, канал забьётся...

BFE>>А в накладные расходы входит сложность и корректность парсинга.

КБ>JSON.parse(x) — для меня достаточно просто.
И что там с корректностью?

КБ>А теперь вопрос: зачем мне предьявлять к парсеру такие требования? Что плохого случится если парсер сможет распарсить "[NaN]" например? По спеке вроде как нельзя. Повод ли это отказываться от парсера?

Несоблюдение спецификации ведёт к невозможности использования сторонних клиентов, например.

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000]
КБ>Ошибку конечно же.
Ошибку или ошибочный результат
Автор: rollcoin
Дата: 29.11.22
?
И каждый день — без права на ошибку...
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:30
Оценка:
Здравствуйте, rollcoin, Вы писали:

BFE>>Забавно. Где-то потеряли 383. Это нормально?

R>Кого потеряли? Какое 383?

Передали: 18446744073709551617.0
Получили: 18446744073709552000
Разница : +383
И да: не потеряли, а приобрели.
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rollcoin  
Дата: 29.11.22 14:32
Оценка:
Здравствуйте, B0FEE664, Вы писали:

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


BFE>>>Забавно. Где-то потеряли 383. Это нормально?

R>>Кого потеряли? Какое 383?

BFE>Передали: 18446744073709551617.0

BFE>Получили: 18446744073709552000
BFE>Разница : +383
BFE>И да: не потеряли, а приобрели.


Все согласно IEEE754
В JavaScript Object Notation все числа — это 53-битные флоаты.
https://www.rfc-editor.org/rfc/rfc7159#section-6
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Dair Россия  
Дата: 29.11.22 14:35
Оценка:
Здравствуйте, rollcoin, Вы писали:

R>Кого потеряли? Какое 383?


Третье число увеличилось.

Это потому что оно, поди, в double хранится, и не хватило мантиссы, поэтому округлилось ...1617 до ...2000.
Re[10]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:42
Оценка: :)
Здравствуйте, rollcoin, Вы писали:

R>Все согласно IEEE754

R>В JavaScript Object Notation все числа — это 53-битные флоаты.
R>https://www.rfc-editor.org/rfc/rfc7159#section-6

Ну, т.е. это нормально — никакой надёжности, зато просто.
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:54
Оценка: +1
Здравствуйте, Dair, Вы писали:

D>Это потому что оно, поди, в double хранится, и не хватило мантиссы, поэтому округлилось ...1617 до ...2000.


Ну разумеется.
В результате нормальные программы передают в Json только строки. И числа передают строками, а уж потом сами парсят строки в числа.
Потому как формат дебильный.
Чего стоит одно то, что число 1. является некорректной записью!
И каждый день — без права на ошибку...
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 29.11.22 17:43
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Есть большое сравнение по перформансу с этими форматам/либами. Погугли. Под рукой нет ссылки.


Иди туда не знаю куда, ищи то не знаю что? Имей хоть какое-то уважение к чужому времени.

P>Подозреваю, в твоем случае либа BSON сильно корявая.


Newtonsoft.Json.Bson
Ад пуст, все бесы здесь.
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 29.11.22 17:43
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Так частный случай же.


Массив простых типов — очень распространенный случай.

K>BSON был и быстрее и компактнее, чем JSON (обе реализации были от Newtonsoft).

K>Правда у нас в итоге победил json, упакованный в zip

Шо, и по скорости?
Ад пуст, все бесы здесь.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 29.11.22 18:26
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Массив простых типов — очень распространенный случай.


Так в итоге всё в простые типы сериализуется.
Вопрос только в наборе данных, иерархиях и т.п.
Ну, как тут уже заметили: важен размер чисел. 1 в виде строки занимает меньше, чем 1 как int и т.п.

C>Шо, и по скорости?


Нет конечно. Так получилось, что важнее был объём, а время записи типа: 100 мс или 300мс — это не важно.
BSON и JSON по скорости записывались примерно одинаково, а вот чтение BSON проходило существенно быстрее.
Упакованный в zip JSON естественно сливал и в чтении и записи, т.к. там же сначала JSON генерируется (BSON совсем не сжимался).
Re[2]: JSON vs BSON: очередное торжество больного воображени
От: vdimas Россия  
Дата: 29.11.22 18:54
Оценка:
Здравствуйте, swame, Вы писали:

S>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам

S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.

Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек).
Тогда твой пример будет таким:
{
    Table: {
        Name: "Analogs",
        colCount: 7,
        rowCount: 10001
    },
    Columns: ["ID","Name","Path","Tag","Min","Max","Value"],
    CanWrite: [1,1,1,1,1,1,1],
    Rows: [
        [0,"analog_0",0,0,10,90,18],
        ...
        [10000,"analog_10000",100,10000,10,90,10]
    ]
}


То бишь, сохраняется структурированность описания, но выходит чуть компактней.

В синтаксисе JS порой намного удобней, бо можно вводить промежуточные значения:
part1 = { 
    A: 1, 
    B: 0 
};

part2 = { C: "X", D: ["Y", "Z"] };

config = { L: part1, M: part2 };

Что в развесистых описаниях резко повышает читабельность.

Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:
part1: { A: 1 B: 0 }
part2: { C: "X" D: ["Y" "Z"] }
config: { L: part1 M: part2 }


Оно же с форматированием:
part1: { 
  A: 1 
  B: 0 
}

part2: { 
  C: "X" 
  D: [
    "Y" 
    "Z"
  ] 
}

config: { 
  L: part1 
  M: part2 
}


Т.к. оно и без лишних знаков препинания парсится всё тем же LR(1) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.
Отредактировано 29.11.2022 18:56 vdimas . Предыдущая версия . Еще …
Отредактировано 29.11.2022 18:55 vdimas . Предыдущая версия .
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 29.11.22 19:57
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Ну, как тут уже заметили: важен размер чисел. 1 в виде строки занимает меньше, чем 1 как int и т.п.


Если тупо всегда писать 32 бита, то да.

K>BSON и JSON по скорости записывались примерно одинаково


Даже и не близко.
Ад пуст, все бесы здесь.
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: maxkar  
Дата: 30.11.22 20:56
Оценка: 3 (1)
Здравствуйте, B0FEE664, Вы писали:


BFE>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

А что вам по задаче нужно? У меня есть куча кирпичиков, я из них почти что угодно могу собрать. Из коробки есть три варианта. Первый просто скажет, что ваш JSON — валидный (валидация — частный случай парсинга). Второй построит
Json.Array(
  Json.Number("4294967297"),
  Json.Number("-4000000000"),
  Json.Number("18446744073709551617.0"),
  Json.Number("1.0000000000000...000"),
)

(нолики ограничил, но будут ровно те, которые в исходном массиве указаны). Дальнейшее поведение зависит от того, в какой именно тип нужно приводить значения (и нужно ли вообще) в программе. Например, в BigDecimal значения приведутся (и весь массив может быть преобразован в List[BigDecimal]). А вот в Int/Long — будут ошибки. Третий вариант очень похож на второй, но будет еще сохранять позицию в исходном файле. С помощью небольшой черной магии при преобразовании можно генерировать ошибки вида "<line>:<column>: значение по пути root(2) не является валидным целым числом" — есть как позиции в json, так и позиции в исходном тексте. А еще я могу собрать сразу все такие (валидный JSON-синтаксис но не соответствуют ожидаемой структуре) ошибки в один проход. Или не все, а, например, не более 42-х.

Парсеры ограничения по глубине не имеют (для типичного сценария в веб ограничения идут на длину потока, парсеру это не нужно), но легко сделать новый, с поддержкой такой фичи. Мегабайт вложенных квадратных скобок все парсыре разбирают, это вообще один из юнит-тестов. Можно собрать "инкрементальный" парсер — пришло нам 3Кб, мы их в парсер отправили и ожидаем следующих по сети. Во всех этих случах практически весь код переиспользуется (есть совсем небольшая разница в конструировании моделей на верхнем уровне, так оказалось удобнее, чем пытаться собрать универсальнй построитель). Всякие детали синтаксиса (формат чисел и т.п.) — полностью общие.

В общем, я учился (и вроде научился) декомпозировать синтаксис (тот же JSON) от всего остального: генерируемой модели, собираемых метаданных, обработки ошибок, потоков данных, синхронности/асинхронности вывода. Получились удобные кирпичики. В качестве побочного эффекта получился еще универсальный движок для корутин. Я потом на его базе сделал поддержку QoS для обработки http-запросов (например, admin получит приоритет и в выделении CPU, и в доступе к SQL-соединениям в пуле), но это уже совсем другая история.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: νsb Казахстан  
Дата: 30.11.22 23:42
Оценка:
Здравствуйте, B0FEE664, Вы писали:

КБ>>Собственно в текстовом представлении json минимум накладных расходов на самом деле.

BFE>Json очень сложно парсить. Я не уверен, что существует хотя бы один парсер который делает это корректно. Вот известная статья по проблемам Json.

Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 10:57
Оценка:
Здравствуйте, maxkar, Вы писали:

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

M>А что вам по задаче нужно?
Речь не про задачу, речь про стандартизованный формат — он крайне, просто на редкость неудобный: числа выделены в отдельный тип данных, но целые числа не отличаются от чисел с плавающей точкой, зачем-то выделен отдельный тип boolean и загадочное значение null, которое можно было бы заменить отсутствием значения { "x":null } <=> { "x": }. При этом умудрились упустить из виду некоторые простейшие формы записи чисел (типа 1.), которые широко используются, но не стандартны. Не удосужились ввести ограничения на значения.

M>Парсеры ограничения по глубине не имеют

Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?
И каждый день — без права на ошибку...
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 11:04
Оценка:
Здравствуйте, νsb, Вы писали:

νsb>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.

Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
И каждый день — без права на ошибку...
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: νsb Казахстан  
Дата: 01.12.22 13:50
Оценка:
Здравствуйте, B0FEE664, Вы писали:

νsb>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.

BFE>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.

Можно пример, который не парсится общепринятым способом?
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 01.12.22 15:41
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> числа выделены в отдельный тип данных, но целые числа не отличаются от чисел с плавающей точкой,


1 — целое число, 1.0 — число с плавающей точкой.

BFE> зачем-то выделен отдельный тип boolean и загадочное значение null, которое можно было бы заменить отсутствием значения { "x":null } <=> { "x": }.


Явное лучше неявного.
avalon/3.0.1
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 15:49
Оценка:
Здравствуйте, rudzuk, Вы писали:

BFE>> числа выделены в отдельный тип данных, но целые числа не отличаются от чисел с плавающей точкой,

R>1 — целое число, 1.0 — число с плавающей точкой.

Логично, но в Json этого различия нет.
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 01.12.22 15:59
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> BFE>> числа выделены в отдельный тип данных, но целые числа не отличаются от чисел с плавающей точкой,


BFE> R>1 — целое число, 1.0 — число с плавающей точкой.


BFE> Логично, но в Json этого различия нет.


Это в JS его нет, а JSON есть.
avalon/3.0.1
Re[10]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 16:12
Оценка:
Здравствуйте, rudzuk, Вы писали:

BFE>> R>1 — целое число, 1.0 — число с плавающей точкой.

BFE>> Логично, но в Json этого различия нет.
R>Это в JS его нет, а JSON есть.

1E-2 — это целое или с плавающей точкой?
И каждый день — без права на ошибку...
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 16:15
Оценка:
Здравствуйте, νsb, Вы писали:

νsb>>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.

BFE>>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
νsb>Можно пример, который не парсится общепринятым способом?

1. — парсится, а не должен
1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?
И каждый день — без права на ошибку...
Re[11]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 01.12.22 17:26
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> BFE>> R>1 — целое число, 1.0 — число с плавающей точкой.

BFE> BFE>> Логично, но в Json этого различия нет.

BFE> R>Это в JS его нет, а JSON есть.


BFE> 1E-2 — это целое или с плавающей точкой?


Экспоненциальная форма используется для записи вещественных чисел — значит, это число с плавающей точкой.
avalon/3.0.1
Re[12]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 17:40
Оценка:
Здравствуйте, rudzuk, Вы писали:

BFE>> BFE>> R>1 — целое число, 1.0 — число с плавающей точкой.

BFE>> BFE>> Логично, но в Json этого различия нет.
BFE>> R>Это в JS его нет, а JSON есть.
BFE>> 1E-2 — это целое или с плавающей точкой?
R>Экспоненциальная форма используется для записи вещественных чисел — значит, это число с плавающей точкой.

Экспоненциальная форма может использоваться для записи целых чисел: 1E2 == 100

Я согласен, что формально можно разделить на целые и на вещественные, но вот только это никак не обозначено (видимо намеренно) в Json.
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Videoman Россия https://hts.tv/
Дата: 01.12.22 17:42
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?


Смотря что считать общепринятым способом. Вот, общепринятый способ для С++:
#include <charconv>
#include <iostream>

int main()
{
    const char number[] ="1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001"; 

    double value = 0.0;
    auto[ptr, ex] = std::from_chars(std::cbegin(number), std::cend(number), value);

    std::cout << value;
}

Раз парсится, значит ничего в этом нестандартного нет
Re[13]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 01.12.22 17:50
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> R>Экспоненциальная форма используется для записи вещественных чисел — значит, это число с плавающей точкой.


BFE> Экспоненциальная форма может использоваться для записи целых чисел: 1E2 == 100


Не, это вещественное число с нулевой дробной частью. У целых чисел нет понятия мантиссы.

BFE> Я согласен, что формально можно разделить на целые и на вещественные, но вот только это никак не обозначено (видимо намеренно) в Json.


Разделение вполне очевидно, как по мне
avalon/3.0.1
Re[14]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 18:41
Оценка:
Здравствуйте, rudzuk, Вы писали:

BFE>> R>Экспоненциальная форма используется для записи вещественных чисел — значит, это число с плавающей точкой.

BFE>> Экспоненциальная форма может использоваться для записи целых чисел: 1E2 == 100
R>Не, это вещественное число с нулевой дробной частью. У целых чисел нет понятия мантиссы.

Вещественное число является целым, если его десятичное представление не содержит дробной части

отсюда
Ну это и понятно, так как целые — подмножество вещественных.

BFE>> Я согласен, что формально можно разделить на целые и на вещественные, но вот только это никак не обозначено (видимо намеренно) в Json.

R>Разделение вполне очевидно, как по мне

Наверное всё же следует отличать вещественные от чисел с плавающей точкой...
Ну да не суть в данном вопросе.
Я о другом. Смотрите, если формат предполагает, например, запись числа в виде двух шестнадцатеричных цифр HH, то я знаю, что мне для парсинга хватит одного байта и при любом раскладе, всё, что выходит за эти два символа — ошибка. Здесь же, для разбора придётся на каждом шаге проверять переполнение числа, что заметно усложняет разбор. При этом парсер либо должен использовать максимально большой тип для результата, либо ему надо задавать пределы ожидаемого значения, до парсинга, что усложняет сам парсер.
Возьмём, число 9223372036854775809 — если это целое, то в 64 бита оно не поместится, но его можно с округлением записать хоть в float с одинарной точностью. И что делать парсеру? Выдавать ошибку или же конвертировать в float64 ?
Универсальный парсер этого знать не может. Это может знать только использующая парсер программа. Быть может это IP6 адрес, а может число с плавающей точкой, просто так получилось, что нет дробной части. Из самого формата никак не вывести, что это за значение.
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображени
От: νsb Казахстан  
Дата: 01.12.22 19:43
Оценка:
Здравствуйте, B0FEE664, Вы писали:

νsb>>>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.

BFE>>>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
νsb>>Можно пример, который не парсится общепринятым способом?

BFE>1. — парсится, а не должен

BFE>1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?

В жаве Double.parseDouble оба значения парсит как положено. new BigDecimal, если хочется без ограничений — тоже парсит.

Не очень понял, почему парсер не должен принимать невалидный вход. Парсер должен работать на валидных входах. Как поступать с невалидным входом это уже вопрос философский. В конкретном данном случае парсить 1. без ошибки это скорей правильно, чем неправильно. Очень полная реализация, конечно, может включать и режим абсолютно строгого парсера. А я бы и комментарии парсил и строки без кавычек.

Вот при сериализации нужно генерировать строго валидный JSON, это безусловно.

Если не ошибаюсь, это старый юниксовый принцип — будь либерален в том, что принимаешь, будь строг в том, что отдаёшь.

Впрочем если очень хочется — конкретно это случай с точкой в конце отловить и отдельно обработать не проблема. Не думаю, что таких случаев будет очень много.

PS чтобы не балаболить, прям сейчас напишу строгий парсер жсона, посмотрим, получится ли.
Отредактировано 01.12.2022 19:55 vsb . Предыдущая версия . Еще …
Отредактировано 01.12.2022 19:50 vsb . Предыдущая версия .
Отредактировано 01.12.2022 19:49 vsb . Предыдущая версия .
Отредактировано 01.12.2022 19:48 vsb . Предыдущая версия .
Отредактировано 01.12.2022 19:47 vsb . Предыдущая версия .
Отредактировано 01.12.2022 19:46 vsb . Предыдущая версия .
Отредактировано 01.12.2022 19:44 vsb . Предыдущая версия .
Re[15]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 01.12.22 20:46
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> Вещественное число является целым, если его десятичное представление не содержит дробной части


BFE> отсюда

BFE> Ну это и понятно, так как целые — подмножество вещественных.

Терминологию мы оспаривать не будем (с). Все так, но в информатике разделение вполне конкретное и экспоненциальная запись для целых чисел не используется.

BFE> Я о другом. Смотрите, если формат предполагает, например, запись числа в виде двух шестнадцатеричных цифр HH, то я знаю, что мне для парсинга хватит одного байта и при любом раскладе, всё, что выходит за эти два символа — ошибка. Здесь же, для разбора придётся на каждом шаге проверять переполнение числа, что заметно усложняет разбор. При этом парсер либо должен использовать максимально большой тип для результата, либо ему надо задавать пределы ожидаемого значения, до парсинга, что усложняет сам парсер.


Ну да, в JSON не указан диапазон чисел, но мир вообще не идеален. Да, это усложняет парсер, но чего уж тут поделаешь.

BFE> Возьмём, число 9223372036854775809 — если это целое, то в 64 бита оно не поместится, но его можно с округлением записать хоть в float с одинарной точностью. И что делать парсеру? Выдавать ошибку или же конвертировать в float64 ?


Все довольно просто: пока не встречены явные признаки числа с плавающей точкой (экспоненциальная запись, дробная часть), число считается целым. Ну а там от возможностей парсера зависит, он может и не ограничиваться 64-битами, или же наоборот, может быть ограничен всего 32'я, а то и 16'ю.

BFE> ...а может число с плавающей точкой, просто так получилось, что нет дробной части.


Если число с плавающей точкой, то дробная часть должна присутствовать обязательно, даже если она нулевая. Это и есть та информация, которая позволит диферинцировать тип представленного числа.
avalon/3.0.1
Re[8]: JSON vs BSON: очередное торжество больного воображени
От: νsb Казахстан  
Дата: 01.12.22 21:47
Оценка:
Вроде написал, на простых тестах работает. Как раз где-то в два часа уложился. Старался всё в точности по спеке делать. Баги если и есть, то исправляемые и размер не увеличат. 229 строк. И форматтер еще строк на 50.

  код
package test;

import java.io.IOException;
import java.io.Reader;
import java.io.Writer;
import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public sealed interface Json {
  record Obj(Map<String, Json> members) implements Json {
  }

  record Arr(List<Json> elements) implements Json {
  }

  record Str(String value) implements Json {
  }

  record Num(BigDecimal value) implements Json {
  }

  record Bool(boolean value) implements Json {
  }

  record Null() implements Json {
  }

  static Obj parseObj(Reader reader) throws IOException {
    skipWs(reader);
    expect(reader, '{');
    var members = new HashMap<String, Json>();
    while (true) {
      skipWs(reader);
      if (peek(reader) == '}') {
        expect(reader, '}');
        return new Obj(Map.copyOf(members));
      }
      if (!members.isEmpty()) {
        expect(reader, ',');
      }
      var str = parseStr(reader);
      skipWs(reader);
      expect(reader, ':');
      var elem = parseValue(reader);
      members.put(str.value(), elem);
    }
  }

  static Arr parseArr(Reader reader) throws IOException {
    skipWs(reader);
    expect(reader, '[');
    var elements = new ArrayList<Json>();
    while (true) {
      skipWs(reader);
      if (peek(reader) == ']') {
        expect(reader, ']');
        return new Arr(List.copyOf(elements));
      }
      if (!elements.isEmpty()) {
        expect(reader, ',');
      }
      var elem = parseValue(reader);
      elements.add(elem);
    }
  }

  static Json parseValue(Reader reader) throws IOException {
    skipWs(reader);
    char c = peek(reader);
    return switch (c) {
      case '"' -> parseStr(reader);
      case '-', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' -> parseNum(reader);
      case '{' -> parseObj(reader);
      case '[' -> parseArr(reader);
      case 't' -> {
        expect(reader, 't');
        expect(reader, 'r');
        expect(reader, 'u');
        expect(reader, 'e');
        yield new Bool(true);
      }
      case 'f' -> {
        expect(reader, 'f');
        expect(reader, 'a');
        expect(reader, 'l');
        expect(reader, 's');
        expect(reader, 'e');
        yield new Bool(false);
      }
      case 'n' -> {
        expect(reader, 'n');
        expect(reader, 'u');
        expect(reader, 'l');
        expect(reader, 'l');
        yield new Null();
      }
      default -> throw new RuntimeException("Unexpected character: '" + c + '\'');
    };
  }

  static Str parseStr(Reader reader) throws IOException {
    skipWs(reader);
    expect(reader, '"');
    var sb = new StringBuilder();
    while (true) {
      char c = read(reader);
      if (c == '"') {
        return new Str(sb.toString());
      }
      if (c != '\\') {
        sb.append(c);
        continue;
      }
      c = read(reader);
      sb.append(switch (c) {
        case '"' -> '"';
        case '\\' -> '\\';
        case '/' -> '/';
        case 'b' -> '\b';
        case 'f' -> '\f';
        case 'n' -> '\n';
        case 'r' -> '\r';
        case 't' -> '\t';
        case 'u' -> {
          char c1 = read(reader);
          char c2 = read(reader);
          char c3 = read(reader);
          char c4 = read(reader);
          String hex = new String(new char[] {c1, c2, c3, c4});
          yield (char) Integer.parseInt(hex, 16);
        }
        default -> throw new RuntimeException("Unexpected character: " + c);
      });
    }
  }

  static Num parseNum(Reader reader) throws IOException {
    skipWs(reader);
    var sb = new StringBuilder();
    parseNumInteger(reader, sb);
    char c = peek(reader);
    if (c == '.') {
      expect(reader, '.');
      sb.append(c);
      parseNumDigits(reader, sb);
      c = peek(reader);
    }
    if (c == 'e' || c == 'E') {
      expect(reader, c);
      sb.append(c);
      c = peek(reader);
      if (c == '+' || c == '-') {
        expect(reader, c);
        sb.append(c);
      }
      parseNumDigits(reader, sb);
    }
    return new Json.Num(new BigDecimal(sb.toString()));
  }

  private static void parseNumInteger(Reader reader, StringBuilder sb) throws IOException {
    char c = peek(reader);
    if (c == '-') {
      expect(reader, c);
      sb.append(c);
      c = peek(reader);
    }
    if (c == '0') {
      expect(reader, c);
      sb.append(c);
      return;
    }
    parseNumDigits(reader, sb);
  }

  private static void parseNumDigits(Reader reader, StringBuilder sb) throws IOException {
    char c = expect(reader, '0', '1', '2', '3', '4', '5', '6', '7', '8', '9');
    sb.append(c);
    c = peek(reader);
    while (c >= '0' && c <= '9') {
      expect(reader, c);
      sb.append(c);
      c = peek(reader);
    }
  }

  private static char read(Reader reader) throws IOException {
    int c = reader.read();
    if (c == -1) {
      throw new RuntimeException("Unexpected EOF");
    }
    return (char) c;
  }

  private static void skipWs(Reader reader) throws IOException {
    char c;
    do {
      reader.mark(1);
      c = read(reader);
    } while (c == ' ' || c == '\n' || c == '\r' || c == '\t');
    reader.reset();
  }

  private static char peek(Reader reader) throws IOException {
    reader.mark(1);
    char c = read(reader);
    reader.reset();
    return c;
  }

  private static char expect(Reader reader, char... cs) throws IOException {
    char c = read(reader);
    for (char ec : cs) {
      if (c == ec) {
        return c;
      }
    }
    if (cs.length == 0) {
      throw new UnsupportedOperationException();
    }
    var sb = new StringBuilder("'").append(cs[0]).append("'");
    for (int i = 1; i < cs.length; i++) {
      sb.append('|').append("'").append(cs[i]).append("'");
    }
    throw new RuntimeException("Expected " + sb + " but got " + c);
  }

  static void write(Writer writer, Json value) throws IOException {
    switch (value) {
      case Str str -> writeString(writer, str.value());
      case Num num -> writer.write(num.value().toString());
      case Obj obj -> writeObj(writer, obj.members());
      case Arr arr -> writeArr(writer, arr.elements());
      case Bool bool -> writer.write(bool.value() ? "true" : "false");
      case Null ignored -> writer.write("null");
    }
  }

  private static void writeObj(Writer writer, Map<String, Json> members) throws IOException {
    writer.write('{');
    var it = members.entrySet().iterator();
    if (it.hasNext()) {
      var e = it.next();
      writeString(writer, e.getKey());
      writer.write(':');
      write(writer, e.getValue());
      while (it.hasNext()) {
        e = it.next();
        writer.write(',');
        writeString(writer, e.getKey());
        writer.write(':');
        write(writer, e.getValue());
      }
    }
    writer.write('}');
  }

  static void writeArr(Writer writer, List<Json> elements) throws IOException {
    writer.write('[');
    var it = elements.iterator();
    if (it.hasNext()) {
      write(writer, it.next());
      while (it.hasNext()) {
        writer.write(',');
        write(writer, it.next());
      }
    }
    writer.write(']');
  }

  private static void writeString(Writer writer, String str) throws IOException {
    writer.write('"');
    for (int i = 0; i < str.length(); i++) {
      char c = str.charAt(i);
      switch (c) {
        case '"' -> writer.write("\\\"");
        case '\\' -> writer.write("\\\\");
        default -> writer.write(c);
      }
    }
    writer.write('"');
  }
}
Отредактировано 01.12.2022 22:14 vsb . Предыдущая версия . Еще …
Отредактировано 01.12.2022 22:12 vsb . Предыдущая версия .
Отредактировано 01.12.2022 22:10 vsb . Предыдущая версия .
Отредактировано 01.12.2022 22:06 vsb . Предыдущая версия .
Отредактировано 01.12.2022 21:52 vsb . Предыдущая версия .
Отредактировано 01.12.2022 21:48 vsb . Предыдущая версия .
Отредактировано 01.12.2022 21:48 vsb . Предыдущая версия .
Re[15]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 01.12.22 21:48
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Универсальный парсер этого знать не может. Это может знать только использующая парсер программа. Быть может это IP6 адрес, а может число с плавающей точкой, просто так получилось, что нет дробной части. Из самого формата никак не вывести, что это за значение.


Так парсеру ничего знать и не нужно. У формата есть несколько управляющих символов: {}[],:"
Вот посредством них входная строка делится на токены. Значение можно так строкой и хранить, т.к. она из файла и пришла.
Ну, а дальше клиентский код сам скажет что ему нужно. Просто нужны будут конвертеры из строки в нужные типы данных.
Зачем при чтении преобразовывать 12345 в int, если потом клиентский код может захотеть float? Чтобы добавлять лишние проверки и конвертации сначала из строки в int, а потом из int во float?
Re[9]: JSON vs BSON: очередное торжество больного воображени
От: Videoman Россия https://hts.tv/
Дата: 02.12.22 09:44
Оценка: -1
Здравствуйте, νsb, Вы писали:

νsb>Вроде написал, на простых тестах работает. Как раз где-то в два часа уложился. Старался всё в точности по спеке делать. Баги если и есть, то исправляемые и размер не увеличат. 229 строк. И форматтер еще строк на 50.


νsb>...


Грамматика там действительно простая, вот только код у тебя по ходу рекурсивный. Лично у меня такой наивный рекурсивный подход даже на С++ не проканал, по памяти и скорости, с трудом представляю что там на Java будет.
Попробуй вот что-нибудь такое распарсить, можешь закрыть все скобки, если нравится :
  JSON

[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":[{"":
...

Отредактировано 04.12.2022 11:27 Videoman . Предыдущая версия . Еще …
Отредактировано 03.12.2022 10:20 Videoman . Предыдущая версия .
Отредактировано 02.12.2022 10:18 Videoman . Предыдущая версия .
Re[10]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 02.12.22 10:51
Оценка: :)
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, νsb, Вы писали:


νsb>>Вроде написал, на простых тестах работает. Как раз где-то в два часа уложился. Старался всё в точности по спеке делать. Баги если и есть, то исправляемые и размер не увеличат. 229 строк. И форматтер еще строк на 50.


νsb>>...


V>Грамматика там действительно простая, вот только код у тебя по ходу рекурсивный. Лично у меня такой наивный рекурсивный подход даже на С++ не проканал, по памяти и скорости, с трудом представляю что там на Java будет.

V>Попробуй вот что-нибудь такое распарсить, можешь закрыть все скобки, если нравится :
V>


Между 2000 и 3000 стек оверфлу. Не, ну это уже из разряда про японскую бензопилу. Кому это надо. Уверен, что половина существующих реализаций сломаются раньше. По скорости работает моментально. По памяти хз, жаба есть жаба, мерять лень, но там стандартные структуры, которые в любой другой реализации будут плюс-минус такие же.
Отредактировано 02.12.2022 10:52 vsb . Предыдущая версия .
Re[11]: JSON vs BSON: очередное торжество больного воображен
От: Videoman Россия https://hts.tv/
Дата: 02.12.22 11:08
Оценка: -1
Здравствуйте, vsb, Вы писали:

vsb>Между 2000 и 3000 стек оверфлу. Не, ну это уже из разряда про японскую бензопилу. Кому это надо. Уверен, что половина существующих реализаций сломаются раньше. По скорости работает моментально. По памяти хз, жаба есть жаба, мерять лень, но там стандартные структуры, которые в любой другой реализации будут плюс-минус такие же.


Отчасти согласен, но уж если делать свой велосипед, то пусть он будет лучше других. Сам этим же страдал, и у меня в библиотеках своя реализация, которая во первых жрёт всякую такую хрень, а также с флагами поддерживает несколько корневых JSON элементов и запятые в конце.
Вот еще проверь, там всё что в JSON-ах встречается — должен читаться:
  JSON

{
"a": {
"6U閆崬밺뀫颒myj츥휘:$薈mY햚#rz飏+玭V㭢뾿愴YꖚX亥ᮉ푊\u0006垡㐭룝\"厓ᔧḅ^Sqpv媫\"⤽걒\"˽Ἆ?ꇆ䬔未tv{DV鯀Tἆl凸g\\㈭ĭ즿UH㽤": null,
"b茤z\\.N": [[
"ZL:ᅣዎ*Y|猫劁櫕荾Oj为1糕쪥泏S룂w࡛Ᏺ⸥蚙)",
{
"\"䬰ỐwD捾V`邀⠕VD㺝sH6[칑.:醥葹*뻵倻aD\"": true,
"e浱up蔽Cr෠JK軵xCʨ<뜡癙Y獩ケ齈X/螗唻?<蘡+뷄㩤쳖3偑犾&\\첊xz坍崦ݻ鍴\"嵥B3㰃詤豺嚼aqJ⑆∥韼@\u000b㢊\u0015L臯.샥": false,
"l?Ǩ喳e6㔡$M꼄I,(3᝝縢,䊀疅뉲B㴔傳䂴\u0088㮰钘ꜵ!ᅛ韽>": -5514085325291784739,
...

Отредактировано 04.12.2022 11:28 Videoman . Предыдущая версия . Еще …
Отредактировано 03.12.2022 10:23 Videoman . Предыдущая версия .
Re[3]: JSON vs BSON: очередное торжество больного воображени
От: swame  
Дата: 02.12.22 11:17
Оценка:
Здравствуйте, vdimas, Вы писали:

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


S>>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам

S>>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.

V>Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек).

V>Тогда твой пример будет таким:
V>
V>{
V>    Table: {
V>        Name: "Analogs",
V>        colCount: 7,
V>        rowCount: 10001
V>    },
V>    Columns: ["ID","Name","Path","Tag","Min","Max","Value"],
V>    CanWrite: [1,1,1,1,1,1,1],
V>    Rows: [
V>        [0,"analog_0",0,0,10,90,18],
V>        ...
V>        [10000,"analog_10000",100,10000,10,90,10]
V>    ]
V>}
V>


С виду для чтения человеком примерно то же самое, только в этом варианте парсинг строки внутри делается парсером,
за счет чего DOM при чтении/записи памяти займет в несколько раз больше,
и мой вариант все же компактней за счет отсутствия кавычек (но они могут быть, если есть неоднозначность).

V>Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:

V>
V>part1: { A: 1 B: 0 }
V>part2: { C: "X" D: ["Y" "Z"] }
V>config: { L: part1 M: part2 }
V>


Мне не требуется писать свой парсер, у меня только Функция парсинга строки своя, экономичная и хорошо оттестированная.
Если данные не простые-повторяющиеся, как в примере, а сложно-вложенные,
ничего не мешает использовать обычный JSON, в других узлах того же файла.
Отредактировано 02.12.2022 11:33 swame . Предыдущая версия . Еще …
Отредактировано 02.12.2022 11:22 swame . Предыдущая версия .
Re[12]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 02.12.22 11:37
Оценка:
Здравствуйте, Videoman, Вы писали:

vsb>>Между 2000 и 3000 стек оверфлу. Не, ну это уже из разряда про японскую бензопилу. Кому это надо. Уверен, что половина существующих реализаций сломаются раньше. По скорости работает моментально. По памяти хз, жаба есть жаба, мерять лень, но там стандартные структуры, которые в любой другой реализации будут плюс-минус такие же.


V>Отчасти согласен, но уж если делать свой велосипед, то пусть он будет лучше других.


Это да, но мой поинт был в том, что парсер жсона написать недолго. В принципе. Понятно, что если его писать прям по уму, с максимальной производительностью, то это уже совсем другая история. Так-то банальное произведение двух чисел это тема для научной диссертации, если нужные нюансы подтянуть.

V>Вот еще проверь, там всё что в JSON-ах встречается — должен читаться:

V>{
V>}


Вроде нормально, парсится без ошибок. Ну это больше проверка всяких юникод-парсеров, с этим в жаве вроде все в порядке должно быть. У меня парсер простой как два рубля — ищет `\` и `"`, остальное копирует как есть.
Отредактировано 02.12.2022 11:38 vsb . Предыдущая версия .
Re[4]: JSON vs BSON: очередное торжество больного воображени
От: vdimas Россия  
Дата: 02.12.22 23:36
Оценка: -1
Здравствуйте, swame, Вы писали:

S>С виду для чтения человеком примерно то же самое, только в этом варианте парсинг строки внутри делается парсером,

S>за счет чего DOM при чтении/записи памяти займет в несколько раз больше,
S>и мой вариант все же компактней за счет отсутствия кавычек (но они могут быть, если есть неоднозначность).

DOM от поданной строки или массива байт в памяти — это просто разметка, т.е. набор смещений, без реального разбиения/копирования размеченных отрезков.
Если твой парсер делает копии подстрок, то System.Text.Json эффективнее в разы.

Если твой парсер тоже обходится подстроками, — то будет примерно так же, с точностью до вылизывания (системная реализация нехило вылизана).
Просто ты часть работы переносишь из Json парсера в свой, непонятно откуда надеясь, что твой парсер будет эффективнее. ))


S>Мне не требуется писать свой парсер, у меня только Функция парсинга строки своя, экономичная и хорошо оттестированная.

S>Если данные не простые-повторяющиеся, как в примере, а сложно-вложенные,
S>ничего не мешает использовать обычный JSON, в других узлах того же файла.

JSON сам по себе малость убог и избыточен, увы.
Сравни похожий на него QML:
Item {
     Rectangle {
         id: myRect
         width: 120
         height: 100
     }
     Rectangle {
         width: myRect.width
         height: 200
     }
}

Никаких лишних знаков препинания.
Плюс можно ссылаться на элементы описания:

Each object can be given a special unique property called an id. Assigning an id enables the object to be referred to by other objects and scripts.


В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.
А так-то хрень полная.
И вся его избыточность как раз для того, чтобы покрыть как можно больше сценариев, оставив как можно меньше простора для ошибок в каждом из них.
В общем по-классике — самое общее решение является самым худшим для конкретного случая.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: pilgrim_ Россия  
Дата: 03.12.22 00:13
Оценка: 1 (1)
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.

...
C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

C>Как, вот как можно было всё настолько изгадить?


Почему у BSON медленней сериализация это действительно странно, т.к. в отличие от JSON отсутствует конвертация числа в строку.
Касаемо размера, массив в BSON сохраняется как т.н. document, в терминах Монги, т.е. массив целых [1,2,3] в BSON будет представлен как документ, где имена полей индексы, типа: {'0': 1, '1': 2, '2': 3}, отсюда походу и оверхед по сравнению с JSON.
Насколько я понимаю при создании формата BSON у разрабов Монги приоритет был в быстром парсинге при запросах, что происходит на стороне Монги на хардкорном C++.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Baiker  
Дата: 03.12.22 09:00
Оценка: :)
Здравствуйте, B0FEE664, Вы писали:

BFE>Json очень сложно парсить


Нет. Как раз довольно простой формат, даже проще XML.

BFE>Вот известная статья по проблемам Json


Известная среди хабразадротов? Я такую "известную" даже не встречал вне его пределов. Так или иначе, статья в какашечном духе вполне соответствует своему сайту.
Размажем по пунктам:

1. Сама суть статьи, как уже метко подметили в комментах, это известный анек про японскую бензопилу. Не более, чем стресс-тест парсеров, НИКАК не соотносящийся с "теоретическим JSONом". То, что какая-то конкретная реализация залажала с глубиной вложенности, НИКАК не делает JSON сложным — просто у прогера нехватило квалификации для отлова экстремальных случаев.
2. Все претензии по юникодам сразу отметаются — это вообще к формату/парсеру не относится. То, что юникод — тот ещё ИТ-высер, известно всем, так что условно считаем, что файл — нормальный UTF-8/16/32/64. Да, парсер в теории не должен падать на юникод-приколах, но строковый модуль — отдельная часть библиотеки.
3. Аномальные величины вроде "гигабайтных 0.000000001" не принимаются. Вернее, парсер должен уметь им противостоять, но никак не обрабатывать, ибо само наличие таких приколов — аномалия, реальные числа такими не бывают.
4. Все остальные "приколы" — чистой воды грамматика и легко парсится.

Вообще, мы тут именно о JSON — сам формат — простой. Стресс-тесты никак к его простоте не относятся! Это уже экстремальные случаи, которые желательно обрабатывать, но никак не обязательно (если ты только не парсишь чужой код на общедоступном сайте).

Я б ещё ввёл (для скорости и простоты) запрет на экранирование. Пусть будет так же "хитропросто", как в XML — всё, что пересекается с токенами синтаксиса, строго выдавать через \uКОД. Т.е. строка с кавычкой должна быть только как "abc\u22def". Тогда парсер будет ещё проще.

Вообще, JSON не зря так легко, одним пинком, сместил XML — именно за читабельность и простоту. ОСОБЕННО простоту обработки — никогда ещё "маршалинг" не был таким лёгким! (помните времена Corba?) Так что бросайте свои протухшие REST-XML недосервисы и пишите нормальные JSON-RPC.
Re[13]: JSON vs BSON: очередное торжество больного воображен
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 03.12.22 09:35
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Вроде нормально, парсится без ошибок. Ну это больше проверка всяких юникод-парсеров, с этим в жаве вроде все в порядке должно быть. У меня парсер простой как два рубля — ищет `\` и `"`, остальное копирует как есть.


А \', \", \\, \n, \t — понимает?
Маньяк Робокряк колесит по городу
Re[5]: JSON vs BSON: очередное торжество больного воображени
От: Baiker  
Дата: 03.12.22 10:32
Оценка: -1 :))
Здравствуйте, vdimas, Вы писали:

V>JSON сам по себе малость убог и избыточен, увы.


Но не более убог, чем твоё мнение о нём.

V>Сравни похожий на него QML:

V> Rectangle {
V> id: myRect

V>Никаких лишних знаков препинания.


В этом и проблема — твоя убогость суждений говорит о том, что ты ничего, кроме как "валидная структура ЯП" не видишь. JSON был сделан намного универсальнее — ему вообще не нужно опираться на синтаксис ЛЮБОГО из языков! Хочешь — напиши проперть так:
{
    "Some strange @ property": 3.1415
}


Практически никаких ограничений на название поля. Да кто вообще сказал, что это поле?! Это просто "именованное нечто", как хочу — так и интерпретирую.
Ты этого даже не понял.

В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.


V>Each object can be given a special unique property called an id


И шо? Потом бегать по сорсам и панически проверять, нет ли В ТВОЁМ коде поля id, чтобы не пересечься с QML?

V>В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.

V>А так-то хрень полная.

Это твоё утверждение — хрень полная. JSON прекрасно себя показал независимо от сторон, куда/откуда он передаётся.

V>В общем по-классике — самое общее решение является самым худшим для конкретного случая.


В корне неверно. "Конкретный случай" может прекрасно ложиться под "общее решение". Достаточно посмотреть, как JSON реализован в целом множестве ЯП — буквально "однострочная" {де}сериализация даёт возможность ВО ВСЕХ(!) языках вообще не париться, что там за JSON приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.
Re[14]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 03.12.22 12:03
Оценка:
Здравствуйте, Marty, Вы писали:

vsb>>Вроде нормально, парсится без ошибок. Ну это больше проверка всяких юникод-парсеров, с этим в жаве вроде все в порядке должно быть. У меня парсер простой как два рубля — ищет `\` и `"`, остальное копирует как есть.


M>А \', \", \\, \n, \t — понимает?


Да, всё по спеке же.
Re[5]: JSON vs BSON: очередное торжество больного воображени
От: swame  
Дата: 03.12.22 12:51
Оценка: +1
Здравствуйте, vdimas, Вы писали:

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


S>>С виду для чтения человеком примерно то же самое, только в этом варианте парсинг строки внутри делается парсером,

S>>за счет чего DOM при чтении/записи памяти займет в несколько раз больше,
S>>и мой вариант все же компактней за счет отсутствия кавычек (но они могут быть, если есть неоднозначность).

V>DOM от поданной строки или массива байт в памяти — это просто разметка, т.е. набор смещений, без реального разбиения/копирования размеченных отрезков.

V>Если твой парсер делает копии подстрок, то System.Text.Json эффективнее в разы.

Я работаю в Dekphi, в разных реализациях JSON, и, да, там каждая нода представляется объектом и делается копия строки.
А что — я не в курсе — в System.Text.Json под капотом не так? Точно?
Если там хранятся смещения, как ты пишешь, значит нельзя поменять ноду распарсенного JSON по сценарию прочитал — поменял — записал обратно.
Тогда это не DOM, а что-то другое.

V>Если твой парсер тоже обходится подстроками, — то будет примерно так же, с точностью до вылизывания (системная реализация нехило вылизана).

V>Просто ты часть работы переносишь из Json парсера в свой, непонятно откуда надеясь, что твой парсер будет эффективнее. ))

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


V>JSON сам по себе малость убог и избыточен, увы.

V>Сравни похожий на него QML:
V>
V>Item {
V>     Rectangle {
V>         id: myRect
V>         width: 120
V>         height: 100
V>     }
V>     Rectangle {
V>         width: myRect.width
V>         height: 200
V>     }
V>}
V>


по сравнению с повторяющимисч иенами атрибутов разделитель — мелочь.

V>Никаких лишних знаков препинания.
Re[6]: JSON vs BSON: очередное торжество больного воображени
От: vdimas Россия  
Дата: 03.12.22 16:20
Оценка:
Здравствуйте, Baiker, Вы писали:

B>В этом и проблема — твоя убогость суждений говорит о том, что ты ничего, кроме как "валидная структура ЯП" не видишь. JSON был сделан намного универсальнее — ему вообще не нужно опираться на синтаксис ЛЮБОГО из языков!


Я именно это и сказал.
И именно оно является причиной убожества JSON для 99.9% реальных сценариев.


B>Хочешь — напиши проперть так:

B> "Some strange @ property": 3.1415

А с этим кто-то спорит?
Для 0.1% сценариев, типа твоего примера, JSON подходит идеально.


B>В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.


Надо просто не забывать основные правила инженерии в пылу спора. ))


V>>Each object can be given a special unique property called an id

B>И шо? Потом бегать по сорсам и панически проверять, нет ли В ТВОЁМ коде поля id, чтобы не пересечься с QML?

Внимательней надо быть — чтобы пересечься с QML, надо оперировать не значениями, а идентификаторами.


V>>В общем, JSON хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.

V>>А так-то хрень полная.
B>Это твоё утверждение — хрень полная. JSON прекрасно себя показал независимо от сторон, куда/откуда он передаётся.

Л — логика.
Любая избыточная хрень покрывает сценарии, где она избыточна.


V>>В общем по-классике — самое общее решение является самым худшим для конкретного случая.

B>В корне неверно.

Одно из основных правил инженерии "в корне неверно"? (С)
Забавное пошло поколение next.

Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?

Т.е., чтобы спецификацией шёл не просто JSON, а некие JSON-base, JSON-optimized, JSON-optimized-referenced, где каждый следующий уровень без проблем бы парсил описание более младшего уровня?

Решения такого рода вполне обычны для инженерии, но в случае JSON приняты не были.
Почему? — из-за истории развития JSON, из-за уровня подготовки тех людей, которые изначально толкали этот формат.

Сначала это был просто валидный JS в той части синтаксиса, где описывается структура объектов.
Затем эту часть выделили в отдельную спецификацию, чтобы не исполнять атакующий хакерский JS-код в этом описании, т.е. слабость такого подхода всплыла сразу — примерно понятно, какого пошиба люди пользовались этой техникой.

ОК, выделили сугубо описательную часть "наколенным" образом.
Т.е. изначальная идея "ничего не делать", типа чтобы описания JS-объектов "подхватывались сами" вынужденно трансформировалась до задачи "написать отдельный парсер".

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


B>"Конкретный случай" может прекрасно ложиться под "общее решение". Достаточно посмотреть, как JSON реализован в целом множестве ЯП — буквально "однострочная" {де}сериализация даёт возможность ВО ВСЕХ(!) языках вообще не париться, что там за JSON приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.


Это лишь доказательство убогости.

Ну какая хрен разница, в 10 строк парсер или в 100?
Эффективность LL(1)-парсера от этого не зависит, она зависит только от выразительности грамматики.
И чем выразительней грамматика, тем эффективнее парсер, по ней работающий.
Это тоже азы.

Тут причина тупизны в другом — для наколенных разработчиков первых реализаций JSON термины навроде "LL(1)-парсер" — что-то вроде страшного ругательства, бгг...
JSON придумали веб-кодеры для передачи данных вместо принятого ранее XML.

Кстате, я загнул про LR(1) парсер в прошлом сообщении, он нужен только если на парсер не работает предварительно токенайзер-лексер.
С выделенным токенайзером там, действительно, совсем на единицы строчек наколенного LL(1)-парсера, причём в любом из описанных гипотетических "уровней".

То бишь, твой аргумент про "наколенность" не сыграл — там будет простейшая реализация для любого предложенного уровня поддержки JS-подобного синтаксиса.
Отредактировано 03.12.2022 17:30 vdimas . Предыдущая версия . Еще …
Отредактировано 03.12.2022 17:29 vdimas . Предыдущая версия .
Отредактировано 03.12.2022 17:27 vdimas . Предыдущая версия .
Re[6]: JSON vs BSON: очередное торжество больного воображени
От: vdimas Россия  
Дата: 03.12.22 17:20
Оценка:
Здравствуйте, swame, Вы писали:

S>Я работаю в Dekphi, в разных реализациях JSON, и, да, там каждая нода представляется объектом и делается копия строки.

S>А что — я не в курсе — в System.Text.Json под капотом не так? Точно?

Не так. Там просто разметка по смещению, информация хранится с сжатом виде, каждый элемент описывается тройкой int, где сами эти int тоже разбиты на битовые поля:
        // The database for the parsed structure of a JSON document.
        //
        // Every token from the document gets a row, which has one of the following forms:
        //
        // Number
        // * First int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for token offset
        // * Second int
        //   * Top bit is set if the number uses scientific notation
        //   * 31 bits for the token length
        // * Third int
        //   * 4 bits JsonTokenType
        //   * 28 bits unassigned / always clear
        //
        // String, PropertyName
        // * First int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for token offset
        // * Second int
        //   * Top bit is set if the string requires unescaping
        //   * 31 bits for the token length
        // * Third int
        //   * 4 bits JsonTokenType
        //   * 28 bits unassigned / always clear
        //
        // Other value types (True, False, Null)
        // * First int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for token offset
        // * Second int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for the token length
        // * Third int
        //   * 4 bits JsonTokenType
        //   * 28 bits unassigned / always clear
        //
        // EndObject / EndArray
        // * First int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for token offset
        // * Second int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for the token length (always 1, effectively unassigned)
        // * Third int
        //   * 4 bits JsonTokenType
        //   * 28 bits for the number of rows until the previous value (never 0)
        //
        // StartObject
        // * First int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for token offset
        // * Second int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for the token length (always 1, effectively unassigned)
        // * Third int
        //   * 4 bits JsonTokenType
        //   * 28 bits for the number of rows until the next value (never 0)
        //
        // StartArray
        // * First int
        //   * Top bit is unassigned / always clear
        //   * 31 bits for token offset
        // * Second int
        //   * Top bit is set if the array contains other arrays or objects ("complex" types)
        //   * 31 bits for the number of elements in this array
        // * Third int
        //   * 4 bits JsonTokenType
        //   * 28 bits for the number of rows until the next value (never 0)


В публичном АПИ эта информация предоставляется через легковесный value-type:
public readonly struct JsonElement

Причём, JsonElement создаётся на лету как view к массиву индексов распарсенного док-та, в реальности объекты этого типа не хранятся.
То бишь, JsonDocument хранит только два массива — исходные данные и массив разметки над данными.

Через элемент можно пройтись по его детям тоже через легковесный енумератор:
public struct JsonElement.ObjectEnumerator

Тоже будет создание на лету этого представления, без потребления памяти из кучи.

Основная фишка System.Text.Json в том, что он позволяет маппить объекты как в рантайм через рефлексию, там и в design-time через кодогенерацию.
Во втором случае можно задействовать технологию .Net Native AOT, где в скомпилённом бинарнике уже никакой лишней метаинформации нет, как и нет байт-кода.

Делается это так:
[JsonSourceGenerationOptions(
        GenerationMode = JsonSourceGenerationMode.Metadata,
        IncludeFields = true,
        PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase
    )]
[JsonSerializable(typeof(Capabilities))]
internal partial class CMakeJson : JsonSerializerContext {
    public static ValueTask<Capabilities> ParseCapabilitiesAsync(Stream s, CancellationToken ct)
        => JsonSerializer.DeserializeAsync(s, Default.Capabilities, ct);
}

internal class Capabilities {
    public Generator[] Generators;
    public CMakeVersion Version = new CMakeVersion();
}

public struct Generator {
    public string Name;
    public bool PlatformSupport;
    public bool ToolsetSupport;
    public string[]? SupportedPlatforms;
}

internal struct CMakeVersion {
    public string String { get; set; }
}


При компиляции этого файла генерируется код сериализации/десериализации результата вызова "cmake -E capabilities".
В общем, хоть какая-то польза от Roslyn. ))

(в MSVS 2022 генерируется так же при сохранении файла, если ошибок компиляции нет)


S>Если там хранятся смещения, как ты пишешь, значит нельзя поменять ноду распарсенного JSON по сценарию прочитал — поменял — записал обратно.

S>Тогда это не DOM, а что-то другое.

Да нет, это именно DOM, просто он не является редактируемым, заточен на парсинг.
Но это именно объектная модель док-та, кто сказал, что модель документа не может быть read only? ))

Если нужно редактирование — опиши свои типизированные структуры, как показал выше, или используй более общий Dictionary<string, object>.
Прочитал в такие структуры, поредактировал, записал обратно.


V>>Если твой парсер тоже обходится подстроками, — то будет примерно так же, с точностью до вылизывания (системная реализация нехило вылизана).

V>>Просто ты часть работы переносишь из Json парсера в свой, непонятно откуда надеясь, что твой парсер будет эффективнее. ))
S>Я использую этот парсинг строки и в других местах, более быстродействующих чех парсинг файла, никаких тормозов там не наблюдается.

Тут только тесты покажут.
Де-факто системные реализации вылизываются, а наколенные вылизываются намного реже, особенно в таких вот непринципиальных задачах.
Потому что в конкретном проекте подобная фунциональность побочная, а не целевая.


V>>JSON сам по себе малость убог и избыточен, увы.

V>>Сравни похожий на него QML:
V>>
V>>Item {
V>>     Rectangle {
V>>         id: myRect
V>>         width: 120
V>>         height: 100
V>>     }
V>>     Rectangle {
V>>         width: myRect.width
V>>         height: 200
V>>     }
V>>}
V>>

S>по сравнению с повторяющимисч иенами атрибутов разделитель — мелочь.

Это не имена атрибутов, ведь там нет ':'.
Это описание лейаута, вызов конструкторов объектов.
Обрати внимание, что когда я предлагал убрать избыточность синтаксиса, я оставил ':' для атрибутов:
http://www.rsdn.org/forum/flame.comp/8418302.1

В общем, я в разные годы в эту специфику нырял достаточно глубоко (хотя там изначально мелко, бгг), всевозможные сценарии уже не раз рассматривал.

Не сомневаюсь, что рано или поздно JSON будет допиливаться, пойдут другие версии стандарта, ну или от него будут форкаться другие стандарты с другими именами собственными, что не суть важно, как это будет обыграно. ))

Но оно будет обязательно.

Похожий синтаксис получается не только в QML, вот тебе Flutter:
    MaterialApp(
      title: 'Ice Creams FTW',
      home: const HomePage(title: 'Ice Cream Stores in SF'),
      theme: ThemeData(
        primarySwatch: Colors.pink,
        scaffoldBackgroundColor: Colors.pink[50],
      ),
    )

Язык Dart умеет быть скриптовым, т.е. эти описания тоже можно передавать удалённо.

Просто JSON — это наследие конкретно JS со всеми вытекающими. ))
И да, в самом начале своей жизни в JSON не было обязательным заключать имена атрибутов в кавычки, это требование появилось позже.
Отредактировано 05.12.2022 12:34 vdimas . Предыдущая версия . Еще …
Отредактировано 03.12.2022 18:56 vdimas . Предыдущая версия .
Отредактировано 03.12.2022 18:55 vdimas . Предыдущая версия .
Отредактировано 03.12.2022 17:25 vdimas . Предыдущая версия .
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 03.12.22 20:38
Оценка: +1
Здравствуйте, Baiker, Вы писали:

B>именно за читабельность и простоту.

Шта? То, что в проде в json высирают точно так же нечеловекочитаемо. Только лиспер с опытом сможет на глаз увидеть скобочки в многомегабайтном однострочнике.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: JSON vs BSON: очередное торжество больного воображени
От: B0FEE664  
Дата: 05.12.22 10:49
Оценка:
Здравствуйте, νsb, Вы писали:

BFE>>1. — парсится, а не должен

νsb>Не очень понял, почему парсер не должен принимать невалидный вход.
Потому, что если данные не соответствуют стандарту, значит это не валидные данные. Данные содержащие ошибки формата должны отвергаться как ошибочные, иначе получится следующая ситуация, когда новая версия будет немного иначе обрабатывать ошибочную ситуацию и пользователи скажут, что новая версия баговая, когда на самом деле это данные это входящие данные баговые.

νsb>Если не ошибаюсь, это старый юниксовый принцип — будь либерален в том, что принимаешь, будь строг в том, что отдаёшь.

Так вот почему в этом семейсте систем ничего нормально не работает...
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображени
От: vsb Казахстан  
Дата: 05.12.22 10:59
Оценка: :))) :)
Здравствуйте, B0FEE664, Вы писали:

BFE>>>1. — парсится, а не должен

νsb>>Не очень понял, почему парсер не должен принимать невалидный вход.
BFE>Потому, что если данные не соответствуют стандарту, значит это не валидные данные. Данные содержащие ошибки формата должны отвергаться как ошибочные, иначе получится следующая ситуация, когда новая версия будет немного иначе обрабатывать ошибочную ситуацию и пользователи скажут, что новая версия баговая, когда на самом деле это данные это входящие данные баговые.

Ну не надо значит в следующей версии обрабатывать иначе. Браузеры вон 30 лет поддерживают обратную совместимость и нормально.

νsb>>Если не ошибаюсь, это старый юниксовый принцип — будь либерален в том, что принимаешь, будь строг в том, что отдаёшь.

BFE>Так вот почему в этом семейсте систем ничего нормально не работает...

Это в самой популярной ОС, на которой весь мир стоит, ничего нормально не работает?
Re[10]: JSON vs BSON: очередное торжество больного воображени
От: B0FEE664  
Дата: 05.12.22 11:17
Оценка:
Здравствуйте, vsb, Вы писали:

νsb>>>Не очень понял, почему парсер не должен принимать невалидный вход.

BFE>>Потому, что если данные не соответствуют стандарту, значит это не валидные данные. Данные содержащие ошибки формата должны отвергаться как ошибочные, иначе получится следующая ситуация, когда новая версия будет немного иначе обрабатывать ошибочную ситуацию и пользователи скажут, что новая версия баговая, когда на самом деле это данные это входящие данные баговые.

vsb>Ну не надо значит в следующей версии обрабатывать иначе. Браузеры вон 30 лет поддерживают обратную совместимость и нормально.

Вот — да, браузеры — это типичный пример баговости и вызывают у меня столько отвращения, что я решил, что никогда не буду заниматься этой билебирбой. Так что если мне надо что-то написать близкое к HTML, то я надев перчатки издали потыкаю палочкой и больше не трогаю, а некоторым — да, нормально.

νsb>>>Если не ошибаюсь, это старый юниксовый принцип — будь либерален в том, что принимаешь, будь строг в том, что отдаёшь.

BFE>>Так вот почему в этом семейсте систем ничего нормально не работает...
vsb>Это в самой популярной ОС, на которой весь мир стоит, ничего нормально не работает?
А вы не замечали, что самое популярное почти всегда плохого качества?
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображени
От: B0FEE664  
Дата: 05.12.22 11:17
Оценка: -1
Здравствуйте, νsb, Вы писали:

νsb>Вроде написал, на простых тестах работает. Как раз где-то в два часа уложился. Старался всё в точности по спеке делать. Баги если и есть, то исправляемые и размер не увеличат. 229 строк. И форматтер еще строк на 50.


Если разбирать как хочется, а не как должно, то тогда конечно.
Например: где проверка, что значение с именем уже было задано для данного объекта? { "a":"asdf", "a":"fghj"}
И каждый день — без права на ошибку...
Re[10]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 05.12.22 11:20
Оценка: -1
Здравствуйте, B0FEE664, Вы писали:

νsb>>Вроде написал, на простых тестах работает. Как раз где-то в два часа уложился. Старался всё в точности по спеке делать. Баги если и есть, то исправляемые и размер не увеличат. 229 строк. И форматтер еще строк на 50.


BFE>Если разбирать как хочется, а не как должно, то тогда конечно.


Там всё по стандарту.

BFE>Например: где проверка, что значение с именем уже было задано для данного объекта? { "a":"asdf", "a":"fghj"}


Это валидный JSON. Тут никаких проверок не нужно.
Отредактировано 05.12.2022 11:21 vsb . Предыдущая версия .
Re[11]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 05.12.22 11:24
Оценка:
Здравствуйте, B0FEE664, Вы писали:

vsb>>Ну не надо значит в следующей версии обрабатывать иначе. Браузеры вон 30 лет поддерживают обратную совместимость и нормально.

BFE>Вот — да, браузеры — это типичный пример баговости и вызывают у меня столько отвращения, что я решил, что никогда не буду заниматься этой билебирбой. Так что если мне надо что-то написать близкое к HTML, то я надев перчатки издали потыкаю палочкой и больше не трогаю, а некоторым — да, нормально.

А я считаю, что это одна из лучших технологий сегодня. И то, что почти все интерфейсы сегодня пишут на HTML, даже там, где есть альтернативы (в тех же мобильных приложениях 2 из 3 это webview по моим ощущениям) — лучшее тому доказательство.

vsb>>Это в самой популярной ОС, на которой весь мир стоит, ничего нормально не работает?

BFE>А вы не замечали, что самое популярное почти всегда плохого качества?

В IT — не замечал. Когда цена копирования нулевая — выигрывает качество. Иногда выигрывает маркетинг, но только временно, как это было в своё время с виндой, которую втюхали неграмотному населению, но время расставило всё по своим местам.
Отредактировано 05.12.2022 11:24 vsb . Предыдущая версия .
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 05.12.22 13:40
Оценка:
Здравствуйте, Baiker, Вы писали:

BFE>>Json очень сложно парсить

B>Нет. Как раз довольно простой формат, даже проще XML.
Знаете, я ещё проще формат могу сделать:
"<имя>"="<значение>"<новая строка>
Спецификация занимает одну строку и описывает все случаи жизни.
Как вам такое, Baiker?

BFE>>Вот известная статья по проблемам Json

B> Известная среди хабразадротов? Я такую "известную" даже не встречал вне его пределов. Так или иначе, статья в какашечном духе вполне соответствует своему сайту.
Нет, это переводная статья.

B>1. Сама суть статьи, как уже метко подметили в комментах, это известный анек про японскую бензопилу. Не более, чем стресс-тест парсеров, НИКАК не соотносящийся с "теоретическим JSONом". То, что какая-то конкретная реализация залажала с глубиной вложенности, НИКАК не делает JSON сложным — просто у прогера нехватило квалификации для отлова экстремальных случаев.

О! Так можно про любой формат сказать: "просто у прогера нехватило квалификации для отлова экстремальных случаев".

B>2. Все претензии по юникодам сразу отметаются — это вообще к формату/парсеру не относится.

А к кому это относится?

B> То, что юникод — тот ещё ИТ-высер, известно всем, так что условно считаем, что файл — нормальный UTF-8/16/32/64.

А давайте считать, что файл уже разобран и результат — 42.
Парсер, который предполагает, что входные данные валидные следует выкидывать сразу.

B>Да, парсер в теории не должен падать на юникод-приколах

отличные технические требования ! Высокие стандарты Baiker соответствуют высоким стандартам информационных технологий современного мира! В теории.

B>но строковый модуль — отдельная часть библиотеки.

А если корпоративным стандартом запрещено использовать сторонние библиотеки, тогда...

B>3. Аномальные величины вроде "гигабайтных 0.000000001" не принимаются. Вернее, парсер должен уметь им противостоять, но никак не обрабатывать, ибо само наличие таких приколов — аномалия, реальные числа такими не бывают.

парсер должен уметь им противостоять, но многие ли умеют?

B>4. Все остальные "приколы" — чистой воды грамматика и легко парсится.

а там что-то ещё осталось?

B>Вообще, мы тут именно о JSON — сам формат — простой. Стресс-тесты никак к его простоте не относятся!

Относятся. В JSON мало ограничений, поэтому работать с ним сложно.

B>Это уже экстремальные случаи, которые желательно обрабатывать, но никак не обязательно (если ты только не парсишь чужой код на общедоступном сайте).

Либо данные соответствуют стандарту, либо это не Json.
Либо парсер не вылетает, либо хакер радуется.

B>Я б ещё ввёл (для скорости и простоты) запрет на экранирование. Пусть будет так же "хитропросто", как в XML — всё, что пересекается с токенами синтаксиса, строго выдавать через \uКОД. Т.е. строка с кавычкой должна быть только как "abc\u22def". Тогда парсер будет ещё проще.

Или не будет.

B>Вообще, JSON не зря так легко, одним пинком, сместил XML — именно за читабельность и простоту. ОСОБЕННО простоту обработки — никогда ещё "маршалинг" не был таким лёгким! (помните времена Corba?) Так что бросайте свои протухшие REST-XML недосервисы и пишите нормальные JSON-RPC.

В реальности Json никто не использует. Используют что-то отдалённо напоминающее Json.
И каждый день — без права на ошибку...
Re[11]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 05.12.22 13:48
Оценка:
Здравствуйте, vsb, Вы писали:

BFE>>Например: где проверка, что значение с именем уже было задано для данного объекта? { "a":"asdf", "a":"fghj"}

vsb>Это валидный JSON. Тут никаких проверок не нужно.

Я не знаю Java. Скажите, в HashMap будут сохранены оба значения для "a"?
И каждый день — без права на ошибку...
Re[12]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 05.12.22 13:58
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>А я считаю, что это одна из лучших технологий сегодня. И то, что почти все интерфейсы сегодня пишут на HTML, даже там, где есть альтернативы (в тех же мобильных приложениях 2 из 3 это webview по моим ощущениям) — лучшее тому доказательство.

Перед светофором останавливаются два авто – «копейка» и «ламборджини». Из открытого окошка «копейки» выглядывает водитель и тихонько стучит в стекло «ламборджини». Оно плавно опускается, оттуда появляется лицо братка. Водитель «копейки»:
— Слышь, мужик, как твоя машинка, ничего или так себе, говно?
— Да, вроде нормальная тачка, а почему спрашиваешь?
— Да смотрю, что-то наши мужики её не очень берут...


vsb>В IT — не замечал. Когда цена копирования нулевая — выигрывает качество. Иногда выигрывает маркетинг, но только временно, как это было в своё время с виндой, которую втюхали неграмотному населению, но время расставило всё по своим местам.


Когда цена копирования нулевая, тогда качество не важно, а значит в большинстве случаев никакое. Во всём бесплатном я это и наблюдаю, за исключением редких авторских поделок, сделанных ради ЧСВ.
И каждый день — без права на ошибку...
Re[12]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 05.12.22 14:00
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>>>Например: где проверка, что значение с именем уже было задано для данного объекта? { "a":"asdf", "a":"fghj"}

vsb>>Это валидный JSON. Тут никаких проверок не нужно.

BFE>Я не знаю Java. Скажите, в HashMap будут сохранены оба значения для "a"?


Нет, будет сохранено последнее.
Re[13]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 05.12.22 14:15
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Нет, будет сохранено последнее.

Разве это ожидаемый результат?
И каждый день — без права на ошибку...
Re[14]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 05.12.22 14:18
Оценка:
Здравствуйте, B0FEE664, Вы писали:

vsb>>Нет, будет сохранено последнее.

BFE>Разве это ожидаемый результат?

JSON.parse('{ "a":"asdf", "a":"fghj"}')
{a: 'fghj'}


Это JS. От которого JSON, собственно, пошёл. Видимо — да, ожидаемый. Если хочется передавать несколько ключей с одинаковым именем — нужно вместо Map взять Multimap, которого в жаве из коробки нет, но подключив нужную библиотеку это скорей всего будет изменение ровно одной строчки.
Re[15]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 05.12.22 14:24
Оценка: +1 -1
Здравствуйте, vsb, Вы писали:

vsb>Это JS. От которого JSON, собственно, пошёл. Видимо — да, ожидаемый. Если хочется передавать несколько ключей с одинаковым именем — нужно вместо Map взять Multimap, которого в жаве из коробки нет, но подключив нужную библиотеку это скорей всего будет изменение ровно одной строчки.


Нормальный стандарт прояснял бы такую ситуацию, а JSON — неопределённое поведение во всём.
И каждый день — без права на ошибку...
Re[16]: JSON vs BSON: очередное торжество больного воображен
От: rollcoin  
Дата: 05.12.22 14:48
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Нормальный стандарт прояснял бы такую ситуацию, а JSON — неопределённое поведение во всём.


Не очень глупый человек сначала прочитает стандарт, чтобы рассуждать о том, что он определеята, что нет.
Re[17]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 05.12.22 15:42
Оценка:
Здравствуйте, rollcoin, Вы писали:

BFE>>Нормальный стандарт прояснял бы такую ситуацию, а JSON — неопределённое поведение во всём.

R>Не очень глупый человек сначала прочитает стандарт, чтобы рассуждать о том, что он определеята, что нет.

В том-то и дело, что авторы по своей зашоренности изначально упустили из виду множество ситуаций, а потом им пришлось описывать в стандарте наблюдаемое положение дел.
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображени
От: Слава  
Дата: 05.12.22 16:58
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

V>Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?


Мешал хорошо известный опыт реализации таких штук. Был SOAP, херово реализованный примерно везде, был и есть XML/XSLT, который можно написать так, что на винде он в .net core будет работать, а в .net core на линуксе — падать.

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

JSON примитивен, и даже его иногда умудряются испортить.
Re[8]: JSON vs BSON: очередное торжество больного воображени
От: vsb Казахстан  
Дата: 05.12.22 17:12
Оценка: +1
Здравствуйте, Слава, Вы писали:

С>JSON примитивен, и даже его иногда умудряются испортить.


JSON изначально испорчен. И ничем не лучше SOAP. Мне точно так же приходили данные из Java, которые в JS молча парсились неправильно, т.к. в жаве long, а в JS 53-битовые числа, а всё, что больше — округляется там как-то. В SOAP я с таким не сталкивался. Там если что-то не работает, то оно не работает, а не молча портит данные.

Конечно поезд XML уже ушёл, это понятно. Но мне до сих пор смешно, когда я вижу в JSON base64-строку, в которой закодирован ещё один JSON, в котором есть ещё одна BASE64 строка и так далее. Вроде один раз уровня 4 вложенности раскопал. И это предлагается вместо человеческих namespace-ов.
Отредактировано 05.12.2022 17:15 vsb . Предыдущая версия . Еще …
Отредактировано 05.12.2022 17:13 vsb . Предыдущая версия .
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 06.12.22 00:18
Оценка: +2
Здравствуйте, B0FEE664, Вы писали:

B>>3. Аномальные величины вроде "гигабайтных 0.000000001" не принимаются. Вернее, парсер должен уметь им противостоять, но никак не обрабатывать, ибо само наличие таких приколов — аномалия, реальные числа такими не бывают.

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

B>>Вообще, мы тут именно о JSON — сам формат — простой. Стресс-тесты никак к его простоте не относятся!

BFE>Относятся. В JSON мало ограничений, поэтому работать с ним сложно.
Да в общем то нет.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[12]: JSON vs BSON: очередное торжество больного воображен
От: karbofos42 Россия  
Дата: 06.12.22 06:01
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>А я считаю, что это одна из лучших технологий сегодня. И то, что почти все интерфейсы сегодня пишут на HTML, даже там, где есть альтернативы (в тех же мобильных приложениях 2 из 3 это webview по моим ощущениям) — лучшее тому доказательство.


Просто веб — дешёвая кроссплатформа. Пока не было нужно поддерживать зоопарк из винды, линукса, мака и мобильных устройств, то делали десктопы и не парились.
Сейчас всем нужна кроссплатформа и не хотят пилить отдельные приложения под разные ОС.

vsb>В IT — не замечал. Когда цена копирования нулевая — выигрывает качество. Иногда выигрывает маркетинг, но только временно, как это было в своё время с виндой, которую втюхали неграмотному населению, но время расставило всё по своим местам.


И что же время расставило? Что за годы развития, линукс так и не повернулся к пользователям лицом и винда удобнее?
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: maxkar  
Дата: 11.12.22 14:13
Оценка: 2 (1)
Здравствуйте, B0FEE664, Вы писали:

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


BFE>>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

M>>А что вам по задаче нужно?
BFE>Речь не про задачу, речь про стандартизованный формат
И было бы почти то же самое. Потому что стандарты мало кто читает и следует им. Куча фреймоврков в http-ответе использует Content-Type:application/json;charset=UTF-8. Хотя в IANA параметр не зарегистрирован, да и все JSON RFC пишут прямым текстом, что "у application/json нет параметра charset". Для практических применений можно взять какую-нибудь JSON Schema. Там будут и типы полей, и ограничения на строки, и все остальное.

Текущая спецификация дает много на откуп реализации, но позволяет делать много и относительно дешево. В 1150 строк (не кода, а всего исходного текста) входит парсер, писатель, сама модель и утилиты для работы с моделью в коде (построение и разбор). Для практических задач можно использовать. А всякие сложности вроде "0.000..01" во многих случаях можно игнорировать.

M>>Парсеры ограничения по глубине не имеют

BFE>Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?
Про тот, который без ограничения по глубине? Сам парсер — 1857 строк текста. Это включает код разбора, интерфейсы интеграции, документацию кода и утилиты (например, утилиты для создания обработчика ошибок — большинству реализаций достаточно просто вывести сообщение). Парсер длинный, но есть некоторая избыточность. Например, парсить числа можно разными способами: можно вычитывать данные, можно читать отдельные секции, можно использовать "конечный автомат" для распознавания входящей строки. Конкретно парсер про стек ничего не знает, ему нужна в помощь конкретная монада. Простейшие тесты используют Unnest. Это 156 строк — преимущественно комментарии. Кода там строк 50. Более интересные примеры (со вводом/выводом) используют корутины. В них 145 строк, но кода больше, чем в Unnest. Собственно, пример — потоковый форматтер. 562 строки (с комментариями, пустыми строками и прочим).

По времени (wall-time) это было примерно полтора месяца. Там было две итерации (переписывание push в pull, в push не все выходило, что я хотел). Но это были не полные рабочие дни. Рабочего времени там где-то 40-80 часов. Плюс много экспериментов, как с API JSON-парсера, так и с нижележащими потоками (основной вопрос — как абстрагировать блокирующий/неблокирующий ввод, сделать look-ahead, как получать позицию входного потока, если о ней парсер не должен ничего знать и т.д.). Если бы я делал сейчас, было бы гораздо быстрее. Зато я научился делать универсальные вещи. Я когда-нибудь сделаю трекинг позиций для конфигурации приложения. Давно уже хочется иметь возможность спросить у приложения: "а в какой конфигурцаии ты запущено, и почему?". А приложение возьмет, да и ответит: "Конфигурация a.b.c=3, потому что я прочитало это из config.properties (строка 10, позиция 15-17). Да, оно также было определено в defaults.json (строка 20, позиция 28-30), но этот конфиг имеет меньший приоритет". У меня уже есть много готовых кирпичиков и технология их склейки вместе .
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 13.12.22 11:21
Оценка:
Здравствуйте, maxkar, Вы писали:

BFE>>Речь не про задачу, речь про стандартизованный формат

M>И было бы почти то же самое. Потому что стандарты мало кто читает и следует им.
Это почему это? Многие по работе читают и обязаны следовать стандартам.

M> Куча фреймоврков в http-ответе использует Content-Type:application/json;charset=UTF-8. Хотя в IANA параметр не зарегистрирован, да и все JSON RFC пишут прямым текстом, что "у application/json нет параметра charset".

Вот поэтому весь веб такой медленный и глючный.

M>Для практических применений можно взять какую-нибудь JSON Schema. Там будут и типы полей, и ограничения на строки, и все остальное.

Там написано, что 1.0 — это integer. здесь

M>Текущая спецификация дает много на откуп реализации, но позволяет делать много и относительно дешево. В 1150 строк (не кода, а всего исходного текста) входит парсер, писатель, сама модель и утилиты для работы с моделью в коде (построение и разбор). Для практических задач можно использовать. А всякие сложности вроде "0.000..01" во многих случаях можно игнорировать.


Для практических...
Допустим контора по контракту пишет продукт, который должен выдавать данные в Json. Допустим в этих данных встречаются вот такие числа, которые парсер заказчика не понимает. Кто должен править свой код?

M>>>Парсеры ограничения по глубине не имеют

BFE>>Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?
M>Про тот, который без ограничения по глубине?
Парсер посмотрелю, но scala я не знаю и не понял как организована работа с результатом. Там должна быть иерархическая структура, но я её не разглядел.

M>По времени (wall-time) это было примерно полтора месяца. Там было две итерации (переписывание push в pull, в push не все выходило, что я хотел). Но это были не полные рабочие дни. Рабочего времени там где-то 40-80 часов.

Ну вот, что-то реальное.
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: maxkar  
Дата: 13.12.22 20:11
Оценка:
Здравствуйте, B0FEE664, Вы писали:

M>>Для практических применений можно взять какую-нибудь JSON Schema. Там будут и типы полей, и ограничения на строки, и все остальное.

BFE>Там написано, что 1.0 — это integer.
Да уж . В свое оправдание могу сказать только, что схемой не пользуюсь и пишу документацию в markdown.

M>> А всякие сложности вроде "0.000..01" во многих случаях можно игнорировать.

BFE>Для практических...
BFE>Допустим контора по контракту пишет продукт, который должен выдавать данные в Json. Допустим в этих данных встречаются вот такие числа, которые парсер заказчика не понимает. Кто должен править свой код?
Предположу, что заказчим. Потому что поставщик данных приложил дополнительные усилия, чтобы сгенерировать такие числа (в решених по-умолчанию обычно подобного не встречается). Большинство библиотек по разбору это число разберут в 0 и тоже проблем не будет. Так что заказчик здесь скорее всего тоже постарался.

Но в какой-то степени я с вами согласен. Во многих текстовых форматах для машинного обмена есть проблемы с точностью или диапазоном значений — они просто не специфицированы. А там, где специфицированы — опять все сделают не так. Например, apache tomcat был подвержен уязвимости в разборе чисел с плавающей точкой. Это для значения параметра q у значений заголовков, который имеет не более трех десятичных позиций.

BFE>Парсер посмотрелю, но scala я не знаю и не понял как организована работа с результатом. Там должна быть иерархическая структура, но я её не разглядел.

В парсере? Нет, не должно — это нарушает Single Responsibility Principle. Парсер должен уметь парсить. А модель пусть строит кто-нибудь другой, да и моделей может быть много разных . Хотя для стандартных случаев я все же сделал утилиту (строка 147 если вдруг ссылка съехала). Там все скучно и сделано в рекурсивном стиле. Раскруткой рекурсии занимается выше упомянутый Unnest (или корутины). Более сложные случаи вроде атрибутов переиспользуют большую часть реализации, но верхнюю диспетчеризацию делают вручную. Например, сохранение позиции из модели. Я пробовал через callback'и сначала. Мне не понравилось. Особенно не понравились сложности с остановкой в ходе процесса. Например, построитель модели решил, что 500Мб для числа — как-то многовато и нужно бы остановиться. При этом интерфейс модели должен позволять получать позицию в потоке, навешивать дополнительные атрибуты (а их может быть много) и т.п. Вариант с передачей всего контроля наружу и переиспользованием там, где можно, мне пока больше нравится.
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Sharowarsheg  
Дата: 14.12.22 02:25
Оценка:
Здравствуйте, CreatorCray, Вы писали:

B>>именно за читабельность и простоту.

CC>Шта? То, что в проде в json высирают точно так же нечеловекочитаемо. Только лиспер с опытом сможет на глаз увидеть скобочки в многомегабайтном однострочнике.

Плотник заметно дешевле лиспера, и может виселицу построить, для того, кто написал генератор многомегабайтного однострочника.
Re[16]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 14.03.23 13:48
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Так парсеру ничего знать и не нужно. У формата есть несколько управляющих символов: {}[],:"

K>Вот посредством них входная строка делится на токены. Значение можно так строкой и хранить, т.к. она из файла и пришла.
K>Ну, а дальше клиентский код сам скажет что ему нужно. Просто нужны будут конвертеры из строки в нужные типы данных.
K>Зачем при чтении преобразовывать 12345 в int, если потом клиентский код может захотеть float? Чтобы добавлять лишние проверки и конвертации сначала из строки в int, а потом из int во float?

Следующие строки в Json эквивалентны: "12345" и "\u00312345". Вы уверены, что клиентский код должен об этом знать?
И каждый день — без права на ошибку...
Re: JSON vs BSON: очередное торжество больного воображения и
От: DiPaolo Россия  
Дата: 14.03.23 14:01
Оценка:
Все просто и банально: молоток для гвоздей, отвертка для шурупов, а гаечный ключ — для гаек и болтов.

Иначе говоря, назначение и особенности BSON описаны тут: https://bsonspec.org/faq.html:

What is the point of BSON when it is no smaller than JSON in some cases?

BSON is designed to be efficient in space, but in some cases is not much more efficient than JSON. In some cases BSON uses even more space than JSON. The reason for this is another of the BSON design goals: traversability. BSON adds some "extra" information to documents, like length of strings and subobjects. This makes traversal faster.

BSON is also designed to be fast to encode and decode. For example, integers are stored as 32 (or 64) bit integers, so they don't need to be parsed to and from text. This uses more space than JSON for small integers, but is much faster to parse.


Все просто, кратко и понятно ИМХО.
Патриот здравого смысла
Отредактировано 14.03.2023 16:32 DiPaolo . Предыдущая версия .
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 14.03.23 14:11
Оценка: +1 :)
Здравствуйте, CreatorCray, Вы писали:

B>>>3. Аномальные величины вроде "гигабайтных 0.000000001" не принимаются. Вернее, парсер должен уметь им противостоять, но никак не обрабатывать, ибо само наличие таких приколов — аномалия, реальные числа такими не бывают.

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

B>>>Вообще, мы тут именно о JSON — сам формат — простой. Стресс-тесты никак к его простоте не относятся!

BFE>>Относятся. В JSON мало ограничений, поэтому работать с ним сложно.
CC>Да в общем то нет.

Что — нет? Вот на прошлой неделе встретился с очередным маразмом: взяли Json файл, сжали его zip'ом, полученную zip-строку закодировали в BASE64, в полученной строке заменили '=' на '\u003D', результат положили в виде строкового значения в Json файл. Ага, Json ведь для того и придуман, чтобы передавать данные в человекочитаемом виде.
И каждый день — без права на ошибку...
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 14.03.23 15:33
Оценка:
Здравствуйте, DiPaolo, Вы писали:

DP>Все просто, кратко и понятно ИМХО.


Ты читать вообще умеешь?

DP>BSON is also designed to be fast to encode and decode.


А по факту — почти в 4 раза медленнее.
Ад пуст, все бесы здесь.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 14.03.23 16:36
Оценка:
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.


JSON — очень компактный формат.

C>Как, вот как можно было всё настолько изгадить?


Маленькое число вполне может занимать в JSON-е один байт. В бинарном формате или будет отведено с запасом, или придется использовать хитрый формат переменного размера.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 14.03.23 16:38
Оценка:
Здравствуйте, νsb, Вы писали:

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


А совсем недавно сегодняшние любители JSON-а в целом не видели места никаким форматам общего назначения, кроме XML...
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 14.03.23 17:50
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Тоже мне, сложность. Хотя для смузихлебов может быть.
Ад пуст, все бесы здесь.
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: vsb Казахстан  
Дата: 14.03.23 18:24
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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


XML плохой формат для структур данных, т.к. он не соответствует этим самым структурам данных. JSON в этом плане лучше. Для разметки текста XML может и годится.
Re[2]: JSON vs BSON: очередное торжество больного воображения и
От: · Великобритания  
Дата: 14.03.23 18:45
Оценка:
Здравствуйте, 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>}
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 14.03.23 18:48
Оценка:
Здравствуйте, B0FEE664, Вы писали:

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


А я говорил, что должен?
Клиентский код должен знать что ему нужно в итоге получить: int, float, string,...
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 14.03.23 20:00
Оценка: +1 :)
Здравствуйте, Codealot, Вы писали:

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


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


А для нас, настоящих мужчин, только ASN.1, только хардкор?
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 14.03.23 20:00
Оценка:
Здравствуйте, vsb, Вы писали:

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


Однако используют его в основном для структур данных...
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: vsb Казахстан  
Дата: 14.03.23 20:26
Оценка: +1
Здравствуйте, Pzz, Вы писали:

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


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


Я не знаю, зачем, если есть выбор. Я с XML работал больше, чем мне хотелось бы, и по своей воле я его редко где выберу.
Re[18]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: · Великобритания  
Дата: 14.03.23 21:54
Оценка:
Здравствуйте, karbofos42, Вы писали:

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

K>А я говорил, что должен?
K>Клиентский код должен знать что ему нужно в итоге получить: int, float, string,...
json это способ сериализации структур в байтики. Притом не самый лучший. А то, о чём ты говоришь — это определение структур данных. Нужно брать какой-нибудь avro/protobuf/sbe/etc.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 14.03.23 23:01
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Совсем хардкор не надо, но переменный размер — это элементарщина.
Ад пуст, все бесы здесь.
Re[19]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 15.03.23 04:15
Оценка:
Здравствуйте, ·, Вы писали:

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


То, о чём я говорю, реализовано в той же JSON.NET. Файл успешно читается, если является валидным json, а потом падает, если клиентский код хочет int, а в json записана строка (ну, можно дополнительных конвертеров навесить, чтобы получить нужный результат). В процессе чтения библиотека не пытается определять что там записано: целое число, вещественное или строка.
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.03.23 04:59
Оценка: :)
Здравствуйте, Codealot, Вы писали:

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


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


Он чего-то стоит, в плане CPU
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 15.03.23 05:55
Оценка:
Здравствуйте, Pzz, Вы писали:

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


С лихвой компенсируется экономией на дисковых операциях. Тебе это было не очевидно?
Ад пуст, все бесы здесь.
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.03.23 06:32
Оценка:
Здравствуйте, Codealot, Вы писали:

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


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


Это если я упираюсь в дисковые операции
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 15.03.23 06:40
Оценка: +1 :)
Здравствуйте, vsb, Вы писали:

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

Шта?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 15.03.23 06:40
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

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

Никаких пометок. Просто тупо строки as is. Клиент пусть сам разбирается что ему надо было.

BFE>закодировали в BASE64, в полученной строке заменили '=' на '\u003D'

Терминаторы в общем то опциональны.

BFE> результат положили в виде строкового значения в Json файл.

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

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

А по факту передают там что угодно. Ибо молоток и гвоздь.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Ночной Смотрящий Россия  
Дата: 15.03.23 08:10
Оценка: +2 -2
Здравствуйте, Pzz, Вы писали:

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


Ты отстал от жизни. Любители JSON уже переключились на YAML, JSON нынче легаси.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[20]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: · Великобритания  
Дата: 15.03.23 10:25
Оценка:
Здравствуйте, karbofos42, Вы писали:

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

K>То, о чём я говорю, реализовано в той же JSON.NET. Файл успешно читается, если является валидным json, а потом падает, если клиентский код хочет int, а в json записана строка (ну, можно дополнительных конвертеров навесить, чтобы получить нужный результат). В процессе чтения библиотека не пытается определять что там записано: целое число, вещественное или строка.
Т.е. по факту в json все скаляры — строки, а потом уже в коде "удобная" обёртка над parseInt/parseDouble/etc. В самом json информация о типах не предусмотрена.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 15.03.23 10:34
Оценка: +1
Здравствуйте, ·, Вы писали:

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


json — строковый формат и там изначально всё равно будет строка и последующая конвертация.
Не вижу смысла городить какие-то "угадыватели", что вот тут в json написано "param":"123" — это строка, а вот в другом месте "param":123 — это уже int.
В итоге окажется, что в клиентском коде нужен float и получим вместо прямого конвертера string -> float цепочку преобразований string -> int -> float.
И все эти конвертеры будут плодиться в геометрической прогрессии и непонятно что это даёт.
А может вообще клиенту этот параметр не нужен и конвертацию можно было и не выполнять.
Re[22]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: · Великобритания  
Дата: 15.03.23 10:55
Оценка:
Здравствуйте, karbofos42, Вы писали:

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

K>json — строковый формат и там изначально всё равно будет строка и последующая конвертация.
K>Не вижу смысла городить какие-то "угадыватели", что вот тут в json написано "param":"123" — это строка, а вот в другом месте "param":123 — это уже int.
По сути это просто два разных способа закодировать одно и то же. И в парсере json.net (и многих других) эти два представления будут неразличимы с точки зрения клиентского кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[23]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 15.03.23 11:00
Оценка:
Здравствуйте, ·, Вы писали:

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


С точки зрения клиента нет никакой разницы, кроме того, что он может получить какие-нибудь лишние ошибки парсинга параметров, которые ему и не были нужны.
С точки зрения реализации огромная разница и я не понимаю смысл усложнения парсера.
Re[24]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: · Великобритания  
Дата: 15.03.23 11:10
Оценка:
Здравствуйте, karbofos42, Вы писали:

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

K>С точки зрения клиента нет никакой разницы, кроме того, что он может получить какие-нибудь лишние ошибки парсинга параметров, которые ему и не были нужны.
K>С точки зрения реализации огромная разница и я не понимаю смысл усложнения парсера.
Смысла нет, есть legacy. json — это подмножество javascript со своими правилами парсинга.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: vsb Казахстан  
Дата: 15.03.23 14:10
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

CC>Шта?

Самые общераспространённые структуры данных это массивы и отображения (объекты тоже можно представить в виде отображений). В XML нет ни того, ни другого. И если отображения ещё можно как-то имитировать в виде вложенных тегов, то массивы — нельзя. В JSON этой проблемы нет.
Re[7]: JSON vs BSON: очередное торжество больного воображени
От: · Великобритания  
Дата: 15.03.23 15:33
Оценка:
Здравствуйте, vsb, Вы писали:

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

CC>>Шта?
vsb>Самые общераспространённые структуры данных это массивы и отображения (объекты тоже можно представить в виде отображений). В XML нет ни того, ни другого. И если отображения ещё можно как-то имитировать в виде вложенных тегов, то массивы — нельзя. В JSON этой проблемы нет.
Список детей узла — это собственно и есть массив по сути.
А отображение можно свести к массиву kv-пар.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 15.03.2023 15:34 · . Предыдущая версия .
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 15.03.23 15:33
Оценка:
Здравствуйте, Pzz, Вы писали:

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


А во что ты упираешься?
Ад пуст, все бесы здесь.
Re[18]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 15.03.23 16:09
Оценка:
Здравствуйте, karbofos42, Вы писали:

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

K>А я говорил, что должен?
Вот ваши слова: "Значение можно так строкой и хранить, т.к. она из файла и пришла."

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

Если клиентскому коду нужен int, а пришла строка "12345". Это ошибка в файле Json?
И каждый день — без права на ошибку...
Re[23]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 15.03.23 16:12
Оценка:
Здравствуйте, ·, Вы писали:

K>>Не вижу смысла городить какие-то "угадыватели", что вот тут в json написано "param":"123" — это строка, а вот в другом месте "param":123 — это уже int.

·>По сути это просто два разных способа закодировать одно и то же. И в парсере json.net (и многих других) эти два представления будут неразличимы с точки зрения клиентского кода.
Т.е. все ошибки будут игнорироваться? Как это вообще может работать без угадывания?
И каждый день — без права на ошибку...
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 15.03.23 16:29
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

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

CC>Никаких пометок. Просто тупо строки as is. Клиент пусть сам разбирается что ему надо было.
А! Ну отлично: парсер, который ничего не делает действительно просто написать — клиент пусть сам разбирается!
Это, извините, не парсер. Это токинайзер.

BFE>> результат положили в виде строкового значения в Json файл.

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

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

CC>А по факту передают там что угодно. Ибо молоток и гвоздь.
По факту Json никто не использует. А то, что использует не Json.
И каждый день — без права на ошибку...
Re[24]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: · Великобритания  
Дата: 15.03.23 16:38
Оценка:
Здравствуйте, B0FEE664, Вы писали:

K>>>Не вижу смысла городить какие-то "угадыватели", что вот тут в json написано "param":"123" — это строка, а вот в другом месте "param":123 — это уже int.

BFE>·>По сути это просто два разных способа закодировать одно и то же. И в парсере json.net (и многих других) эти два представления будут неразличимы с точки зрения клиентского кода.
BFE>Т.е. все ошибки будут игнорироваться? Как это вообще может работать без угадывания?
Никак. Это же JavaScript Object Notation. Там всё про угадывание.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 15.03.23 16:56
Оценка:
Здравствуйте, Pzz, Вы писали:

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

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

Это в сравнении с переводом числа в десятичную форму?
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 15.03.23 17:53
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>то массивы — нельзя.

И с какого перепугу вдруг массивы точно так же представить нельзя?
<Array Name = "то, что нельзя представить">
 <Element>blah1</Element>
 <Element>blah2</Element>
 <Element Value = "blah3"/>
 <Element index = "100500">blah4</Element>
 ...
</Array>
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 15.03.23 17:53
Оценка: :)
Здравствуйте, B0FEE664, Вы писали:

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

BFE>Если клиентскому коду нужен int, а пришла строка "12345". Это ошибка в файле Json?
json сам по себе это тупо строка. Там всё в текстовом виде. Если клиенту надо int то он значение (строку) затолкает в string->int конвертор, и тот либо сконвертирует либо скажет "Ошибка! Попробуй! Ещё! Раз!" (tm)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 15.03.23 17:53
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>парсер, который ничего не делает

Парсер разбирает формат на токены. Импортировать разобранное — не его задача вообще.

BFE> действительно просто написать — клиент пусть сам разбирается!

BFE>Это, извините, не парсер. Это токинайзер.


https://www.merriam-webster.com/dictionary/parser

parser noun
: one that parses
specifically : a computer program that breaks down text into recognized strings of characters for further analysis


BFE>Парсер, в отличии от токинайзера, должен понимать грамматику и выдавать результат ей соответствующий.

А он именно грамматику формата и понимает. Но конвертацией типов данных он не занимается.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 15.03.23 17:53
Оценка:
Здравствуйте, Pzz, Вы писали:

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

C>>С лихвой компенсируется экономией на дисковых операциях. Тебе это было не очевидно?
Pzz>Это если я упираюсь в дисковые операции
Да в общем то любое IO жрёт ресурсов больше
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: JSON vs BSON: очередное торжество больного воображени
От: vsb Казахстан  
Дата: 15.03.23 18:01
Оценка:
Здравствуйте, CreatorCray, Вы писали:

vsb>>то массивы — нельзя.

CC>И с какого перепугу вдруг массивы точно так же представить нельзя?
CC>
CC><Array Name = "то, что нельзя представить">
CC> <Element>blah1</Element>
CC> <Element>blah2</Element>
CC> <Element Value = "blah3"/>
CC> <Element index = "100500">blah4</Element>
CC> ...
CC></Array>
CC>


Только если у твоего парсера есть внешняя мета-информация о предполагаемой структуре. Иначе ты не сможешь отличить массив с 0 или 1 элементом от других структур данных.

Ну или у тебя такой уродский XML получится, что им будет невозможно пользоваться.

Вот простейший JSON:

{
  "services": {
    "buildroot": {
      "build": "buildroot",
      "volumes": [
        "dl:/build/dl",
        "output:/build/output"
      ]
    }
  },
  "volumes": {
    "dl": null,
    "output": null
  }
}


Попробуй представить его в XML так, чтобы это было в обе стороны однозначно и чтобы от такого XML не хотелось бы уволиться.
Отредактировано 15.03.2023 18:05 vsb . Предыдущая версия . Еще …
Отредактировано 15.03.2023 18:04 vsb . Предыдущая версия .
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.03.23 19:04
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

Pzz>>Это если я упираюсь в дисковые операции
CC>Да в общем то любое IO жрёт ресурсов больше

Не обязательно.

Например, если ты посылаешь свои объекты по сети, причем не пачками, а штучно, то пока объект лезет в пакет, его размер не слишком-то сильно влияет на цену посылки.
Re[9]: JSON vs BSON: очередное торжество больного воображени
От: CreatorCray  
Дата: 15.03.23 20:32
Оценка: 1 (1)
Здравствуйте, vsb, Вы писали:

vsb>Только если у твоего парсера есть внешняя мета-информация о предполагаемой структуре.

Эта информация есть у кода импорта

vsb> Иначе ты не сможешь отличить массив с 0 или 1 элементом от других структур данных.

Это не задача парсера.

vsb>Попробуй представить его в XML

Просто скормил твой пример в JSON2XML, вот выхлоп
<?xml version="1.0" encoding="utf-8"?>
<JSON>
    <services>
        <buildroot build = "buildroot">
            <volumes>
                <ArrayElement Value = "dl:/build/dl"/>
                <ArrayElement Value = "output:/build/output"/>
            </volumes>
        </buildroot>
    </services>
    <volumes
        dl = "null"
        output = "null"
    />
</JSON>



vsb> чтобы от такого XML не хотелось бы уволиться.

Всё равно всё это говно в итоге читается машиной а не человеком. Человеки на это в лучшем случае смотрят через diff или иногда подправляют.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: JSON vs BSON: очередное торжество больного воображени
От: vsb Казахстан  
Дата: 15.03.23 21:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

vsb>>Только если у твоего парсера есть внешняя мета-информация о предполагаемой структуре.

CC>Эта информация есть у кода импорта

Нет. Я вызываю JSON.parse и всё.

vsb>> Иначе ты не сможешь отличить массив с 0 или 1 элементом от других структур данных.

CC>Это не задача парсера.

А что задача парсера? Мне нужно текст преобразовать в массивы и отображения.

vsb>> чтобы от такого XML не хотелось бы уволиться.

CC>Всё равно всё это говно в итоге читается машиной а не человеком. Человеки на это в лучшем случае смотрят через diff или иногда подправляют.

У меня другой опыт. Постоянно приходится на это смотреть.
Re[11]: JSON vs BSON: очередное торжество больного воображени
От: CreatorCray  
Дата: 15.03.23 23:44
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Нет. Я вызываю JSON.parse и всё.

То, что оно делает больше похоже на eval

vsb>>> Иначе ты не сможешь отличить массив с 0 или 1 элементом от других структур данных.

CC>>Это не задача парсера.
vsb>А что задача парсера?

https://www.merriam-webster.com/dictionary/parser

parser noun
: one that parses
specifically : a computer program that breaks down text into recognized strings of characters for further analysis


vsb>У меня другой опыт. Постоянно приходится на это смотреть.

Соболезную
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 16.03.23 01:59
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Например, если ты посылаешь свои объекты по сети, причем не пачками, а штучно, то пока объект лезет в пакет, его размер не слишком-то сильно влияет на цену посылки.


А процессор — тем более.
Ад пуст, все бесы здесь.
Re[25]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 16.03.23 10:29
Оценка:
Здравствуйте, ·, Вы писали:

BFE>>Т.е. все ошибки будут игнорироваться? Как это вообще может работать без угадывания?

·>Никак. Это же JavaScript Object Notation. Там всё про угадывание.

Вот-вот. Вот поэтому парсить Json крайне сложно.
И каждый день — без права на ошибку...
Re[20]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 16.03.23 10:46
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

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

BFE>>Если клиентскому коду нужен int, а пришла строка "12345". Это ошибка в файле Json?
CC>json сам по себе это тупо строка.
Не согласен. json — это не тупо строка. Например: {"x":null} означает, что x — это объект.

CC>Там всё в текстовом виде.

Фраза ни о чём. Если алфавит из 256 символов, то любой файл — это просто текст.

CC> Если клиенту надо int то он значение (строку) затолкает в string->int конвертор, и тот либо сконвертирует либо скажет "Ошибка! Попробуй! Ещё! Раз!" (tm)

А если клиенту надо int, а приходит объект, то нет ничего сложного сконвертировать его в число: null — это 0, а остальное — 1. Я правильно понимаю?
И каждый день — без права на ошибку...
Re[10]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 16.03.23 10:58
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

BFE>>парсер, который ничего не делает

CC>Парсер разбирает формат на токены. Импортировать разобранное — не его задача вообще.
BFE>> действительно просто написать — клиент пусть сам разбирается!
BFE>>Это, извините, не парсер. Это токинайзер.
CC>

CC>https://www.merriam-webster.com/dictionary/parser

CC>

CC>parser noun
CC>: one that parses
CC>specifically : a computer program that breaks down text into recognized strings of characters for further analysis



https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BD%D1%82%D0%B0%D0%BA%D1%81%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7

Синтаксический анализатор (жарг. па́рсер ← англ. parser) — это программа или часть программы, выполняющая синтаксический анализ.

Синтакси́ческий ана́лиз (или разбор, жарг. па́рсинг ← англ. parsing) в лингвистике и информатике — процесс сопоставления линейной последовательности лексем (слов, токенов) естественного или формального языка с его формальной грамматикой. Результатом обычно является дерево разбора (синтаксическое дерево). Обычно применяется совместно с лексическим анализом.


https://www.cs.man.ac.uk/~pjj/farrell/comp3.html

Regardless of where the program comes from it must first pass through a Tokenizer, or as it is sometimes called, a Lexer. The tokenizer is responsible for dividing the input stream into individual tokens, identifying the token type, and passing tokens one at a time to the next stage of the compiler.

The next stage of the compiler is called the Parser. This part of the compiler has an understanding of the language's grammar. It is responsible for identifying syntax errors and for translating an error free program into internal data structures that can be interpreted or written out in another language.


BFE>>Парсер, в отличии от токинайзера, должен понимать грамматику и выдавать результат ей соответствующий.

CC>А он именно грамматику формата и понимает. Но конвертацией типов данных он не занимается.
Конечно конвертацией парсер не занимается. Разве это я утверждал?
И каждый день — без права на ошибку...
Re[11]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 16.03.23 11:18
Оценка: +2
Здравствуйте, B0FEE664, Вы писали:

CC>>Парсер разбирает формат на токены. Импортировать разобранное — не его задача вообще.

BFE>>> действительно просто написать — клиент пусть сам разбирается!
BFE>>>Это, извините, не парсер. Это токинайзер.
Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }. А парсер проверит баланс скобок, проверит, что токены разделителей типа запятых и двоеточий стоят как надо и отдаст уже древовидную структуру клиенту. И собственно всё.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 16.03.2023 11:19 · . Предыдущая версия .
Re[12]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 16.03.23 17:21
Оценка:
Здравствуйте, ·, Вы писали:

·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }. А парсер проверит баланс скобок, проверит, что токены разделителей типа запятых и двоеточий стоят как надо и отдаст уже древовидную структуру клиенту. И собственно всё.


Т.е., таки, строку "\u00312345" в "12345" никто преобразовывать не будет?
И каждый день — без права на ошибку...
Re[6]: JSON vs BSON: очередное торжество больного воображени
От: B0FEE664  
Дата: 16.03.23 17:33
Оценка:
Здравствуйте, Baiker, Вы писали:

B>Практически никаких ограничений на название поля. Да кто вообще сказал, что это поле?! Это просто "именованное нечто", как хочу — так и интерпретирую.

B>Ты этого даже не понял.

B>В JSON может и можно что-то подсократить (к примеру, escape-последовательности), но в целом формат оптимален. Надо просто думать чуть абстрактнее.


О да! вот, например, хороший вариант записывать точку 3D в Json: { "23" : "x", "24": "y", "24" : "z" }. Надо просто думать чуть абстрактнее.
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 16.03.23 17:40
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Самые общераспространённые структуры данных это массивы и отображения (объекты тоже можно представить в виде отображений). В XML нет ни того, ни другого. И если отображения ещё можно как-то имитировать в виде вложенных тегов, то массивы — нельзя. В JSON этой проблемы нет.


В JSON нет массивов. Это, извините, не массив: [1, "not array"]
И каждый день — без права на ошибку...
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: vsb Казахстан  
Дата: 16.03.23 17:46
Оценка:
Здравствуйте, B0FEE664, Вы писали:

vsb>>Самые общераспространённые структуры данных это массивы и отображения (объекты тоже можно представить в виде отображений). В XML нет ни того, ни другого. И если отображения ещё можно как-то имитировать в виде вложенных тегов, то массивы — нельзя. В JSON этой проблемы нет.


BFE>В JSON нет массивов. Это, извините, не массив: [1, "not array"]


Почему?
Re[21]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: CreatorCray  
Дата: 16.03.23 18:50
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>А если клиенту надо int, а приходит объект, то нет ничего сложного сконвертировать его в число: null — это 0, а остальное — 1. Я правильно понимаю?

Нет, неправильно. Попробуй ещё раз.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: JSON vs BSON: очередное торжество больного воображен
От: CreatorCray  
Дата: 16.03.23 18:50
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Т.е., таки, строку "\u00312345" в "12345" никто преобразовывать не будет?

Код импорта.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 16.03.23 18:52
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }. А парсер проверит баланс скобок, проверит, что токены разделителей типа запятых и двоеточий стоят как надо и отдаст уже древовидную структуру клиенту. И собственно всё.

BFE>Т.е., таки, строку "\u00312345" в "12345" никто преобразовывать не будет?
Токенайзер этим занимается. Иначе, например, \" он не сможет правильно на токены побить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: JSON vs BSON: очередное торжество больного воображен
От: Ночной Смотрящий Россия  
Дата: 17.03.23 06:44
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }. А парсер проверит баланс скобок, проверит, что токены разделителей типа запятых и двоеточий стоят как надо и отдаст уже древовидную структуру клиенту. И собственно всё.


Это зависит от конкретного парсера. Бывает по разному. В частности, токены с числовыми константами чуть менее чем во всех видимых мною парсерах преобразуются в число даже не парсером, а лексером.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[13]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 17.03.23 07:10
Оценка: +1
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }. А парсер проверит баланс скобок, проверит, что токены разделителей типа запятых и двоеточий стоят как надо и отдаст уже древовидную структуру клиенту. И собственно всё.


НС>Это зависит от конкретного парсера. Бывает по разному. В частности, токены с числовыми константами чуть менее чем во всех видимых мною парсерах преобразуются в число даже не парсером, а лексером.

Если это было какое-то возражение или хотя бы какая-то новая информация, то я не понял. Ты повторил сказанное мною, только назвал токенайзер лексером, что практически одно и тоже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: JSON vs BSON: очередное торжество больного воображен
От: Ночной Смотрящий Россия  
Дата: 17.03.23 07:58
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Это зависит от конкретного парсера. Бывает по разному. В частности, токены с числовыми константами чуть менее чем во всех видимых мною парсерах преобразуются в число даже не парсером, а лексером.

·>Если это было какое-то возражение или хотя бы какая-то новая информация, то я не понял. Ты повторил сказанное мною, только назвал токенайзер лексером, что практически одно и тоже.

Я запутался. Началось все с заявления CreatorCray

По хорошему, именно что парсер должен разобрать входной поток на структурированные токены а валидацией (т.е. пониманием что это не число нифига, или формат даты неправильный) должен заниматься собственно код импорта этой структуры.


А ты вроде с ним был согласен.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 17.03.23 22:12
Оценка:
Здравствуйте, vsb, Вы писали:

BFE>>В JSON нет массивов. Это, извините, не массив: [1, "not array"]

vsb>Почему?

По определению:

Массив в программировании — набор однотипных элементов, ...

https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%81%D0%B8%D0%B2
И каждый день — без права на ошибку...
Re[10]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 17.03.23 22:30
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> BFE>>В JSON нет массивов. Это, извините, не массив: [1, "not array"]

BFE> vsb>Почему?

BFE> По определению:


BFE> Массив в программировании — набор однотипных элементов, ...


BFE> https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%81%D0%B8%D0%B2


array of Variant;
array of TObject;

Элементы однотипные, но есть нюанс... Впрочем:
https://en.wikipedia.org/wiki/Array_(data_structure)

In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

И ни слова о типах.
avalon/3.0.2
Re[10]: JSON vs BSON: очередное торжество больного воображен
От: vsb Казахстан  
Дата: 17.03.23 23:01
Оценка: :)
Здравствуйте, B0FEE664, Вы писали:

BFE>>>В JSON нет массивов. Это, извините, не массив: [1, "not array"]

vsb>>Почему?

BFE>По определению:

BFE>

BFE>Массив в программировании — набор однотипных элементов, ...

BFE>https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%81%D0%B8%D0%B2

Ну они и есть однотипные. У всех тип JsonNode (или Object или Any или ещё какой-нибудь подобный).

Если не нравится слово "массив", можно назвать это списком, хотя это и некорректно. JSON произошёл от JavaScript-а, в котором эта конструкция называется массивом, нравится это википедии или нет.
Отредактировано 17.03.2023 23:02 vsb . Предыдущая версия .
Re[11]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 20.03.23 11:59
Оценка:
Здравствуйте, rudzuk, Вы писали:

BFE>> BFE>>В JSON нет массивов. Это, извините, не массив: [1, "not array"]

BFE>> vsb>Почему?
BFE>> По определению:
BFE>> Массив в программировании — набор однотипных элементов, ...
BFE>> https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%81%D0%B8%D0%B2
R>array of Variant;
R>array of TObject;
R>Элементы однотипные, но есть нюанс... Впрочем:
Если использовать стиратели типов, тогда конечно.

R>https://en.wikipedia.org/wiki/Array_(data_structure)

R>

In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

R>И ни слова о типах.
Ну не совсем:

Arrays are useful mostly because the element indices can be computed at run time. Among other things, this feature allows a single iterative statement to process arbitrarily many elements of an array. For that reason, the elements of an array data structure are required to have the same size and should use the same data representation. The set of valid index tuples and the addresses of the elements (and hence the element addressing formula) are usually,[3][5] but not always,[2] fixed while the array is in use.


Если array может хранить различные элементы, то чем он тогда отличается кортежа?
И каждый день — без права на ошибку...
Re[11]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 20.03.23 12:04
Оценка:
Здравствуйте, vsb, Вы писали:

BFE>>>>В JSON нет массивов. Это, извините, не массив: [1, "not array"]

vsb>Ну они и есть однотипные. У всех тип JsonNode (или Object или Any или ещё какой-нибудь подобный).
Ага. С пометкой, что за тип у него внутри.

vsb>Если не нравится слово "массив", можно назвать это списком, хотя это и некорректно.

Мне не массив не нравится. Мне эта конструкция не нравится, потому как не нужна и никогда не используется на практике.

vsb>JSON произошёл от JavaScript-а, в котором эта конструкция называется массивом, нравится это википедии или нет.

Ну так я и говорю про зашоренность авторов, которые кроме как про JavaScript ни о чём не подумали.
И каждый день — без права на ошибку...
Re[14]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 20.03.23 12:10
Оценка:
Здравствуйте, ·, Вы писали:

BFE>>·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }. А парсер проверит баланс скобок, проверит, что токены разделителей типа запятых и двоеточий стоят как надо и отдаст уже древовидную структуру клиенту. И собственно всё.

BFE>>Т.е., таки, строку "\u00312345" в "12345" никто преобразовывать не будет?
·>Токенайзер этим занимается. Иначе, например, \" он не сможет правильно на токены побить.

А вот и не подерётесь.
Автор: CreatorCray
Дата: 16.03.23


Что мешает токенайзеру пропустить все пары \" до одиночного символа " ?
И каждый день — без права на ошибку...
Re[14]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 20.03.23 12:10
Оценка:
Здравствуйте, CreatorCray, Вы писали:

BFE>>Т.е., таки, строку "\u00312345" в "12345" никто преобразовывать не будет?

CC>Код импорта.

А вот и не подерётесь.
Автор: ·
Дата: 16.03.23
И каждый день — без права на ошибку...
Re[12]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 20.03.23 12:37
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> R>И ни слова о типах.


BFE> Ну не совсем:

...

Тут речь не о типах, а о представлении данных на физическом уровне (это следует из контекста вычисления адресов элементов по индексу).

BFE> Если array может хранить различные элементы, то чем он тогда отличается кортежа?


У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.
avalon/3.0.2
Re[15]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 20.03.23 13:50
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>·>Токенайзер этим занимается. Иначе, например, \" он не сможет правильно на токены побить.

BFE>Что мешает токенайзеру пропустить все пары \" до одиночного символа " ?
json спека? \", \u и прочие \n определены одинаково. Почему токенайзер каким-то escape-последовательностям отдавать предпочтение — неясно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[16]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 20.03.23 14:15
Оценка:
Здравствуйте, ·, Вы писали:

·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }.

BFE>>·>Токенайзер этим занимается. Иначе, например, \" он не сможет правильно на токены побить.
BFE>>Что мешает токенайзеру пропустить все пары \" до одиночного символа " ?
·>json спека? \", \u и прочие \n определены одинаково. Почему токенайзер каким-то escape-последовательностям отдавать предпочтение — неясно.
Хорошо. Тогда не понятно, почему escape-последовоательность не отдельный токен:
Т.е. почему для Json'а ["\u00312345"] токенайзер выдаст: [, "12345", ], а не [, ", \u0031, 2345, ", ]
И каждый день — без права на ошибку...
Re[17]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 20.03.23 14:31
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Хорошо. Тогда не понятно, почему escape-последовоательность не отдельный токен:

BFE>Т.е. почему для Json'а ["\u00312345"] токенайзер выдаст: [, "12345", ], а не [, ", \u0031, 2345, ", ]
Ровно по тому же, почему для ["x\"y"] выдаст [, x"y, ], а не что-то другое (даже не знаю что тут можно придумать чтобы имело хоть какой-то смысл). Т.е. бэкслеш обрабатывается одинаково той же частью кода, вне зависимости от того что после этого бэкслеша стоит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 20.03.2023 14:34 · . Предыдущая версия . Еще …
Отредактировано 20.03.2023 14:32 · . Предыдущая версия .
Re[18]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 20.03.23 15:24
Оценка: :)
Здравствуйте, ·, Вы писали:

BFE>>Хорошо. Тогда не понятно, почему escape-последовоательность не отдельный токен:

BFE>>Т.е. почему для Json'а ["\u00312345"] токенайзер выдаст: [, "12345", ], а не [, ", \u0031, 2345, ", ]
·>Ровно по тому же, почему для ["x\"y"] выдаст [, x"y, ], а не что-то другое (даже не знаю что тут можно придумать чтобы имело хоть какой-то смысл).
А ведь смысл-то есть, например:

= is a special javascript character that must be escaped to unicode in JSON so that a string literal can be embedded in XHTML without further escaping.

Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?

·>Т.е. бэкслеш обрабатывается одинаково той же частью кода, вне зависимости от того что после этого бэкслеша стоит.

Может так, а может и нет. От задачи зависит.
Так что CreatorCray в чём-то прав с точки зрения практики, но совершенно не понимает в идеологии.
И каждый день — без права на ошибку...
Re[13]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 20.03.23 15:34
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Тут речь не о типах, а о представлении данных на физическом уровне (это следует из контекста вычисления адресов элементов по индексу).

Ну допустим.
Много вы знаете языков поддерживающих массивы разнотипных элементов? В каких задачах это используется?

BFE>> Если array может хранить различные элементы, то чем он тогда отличается кортежа?

R>У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.
— а что же это? К тому же по вашей же ссылке для массива не обязательно иметь индекс, достаточно иметь ключ:

In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

И каждый день — без права на ошибку...
Re[19]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 20.03.23 15:57
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>А ведь смысл-то есть, например:

BFE>

BFE>= is a special javascript character that must be escaped to unicode in JSON so that a string literal can be embedded in XHTML without further escaping.

Это откуда за цитата и о чём?

BFE>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?

Чтобы правильно и однозначно разбить поток символов на токены.

BFE>·>Т.е. бэкслеш обрабатывается одинаково той же частью кода, вне зависимости от того что после этого бэкслеша стоит.

BFE>Может так, а может и нет. От задачи зависит.
Ну можно натянуть, что если у тебя не просто json-либа, а, скажем, умный текстовый редактор, который должен как-то особо обрабатывать json, то наверное да.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: · Великобритания  
Дата: 20.03.23 16:01
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Ну допустим.

BFE>Много вы знаете языков поддерживающих массивы разнотипных элементов? В каких задачах это используется?
Разнотипные элементы ты сам придумал. Тип один — JsonValue или вроде того. И такие массивы object[] поддерживаются в java/c# и т.п.

BFE>>> Если array может хранить различные элементы, то чем он тогда отличается кортежа?

R>>У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.
BFE>- а что же это? К тому же по вашей же ссылке для массива не обязательно иметь индекс, достаточно иметь ключ:
BFE>

BFE>In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

Если ключ, то это так называемый associative array (синоним мапы или словаря).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rudzuk  
Дата: 20.03.23 16:13
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE> Много вы знаете языков поддерживающих массивы разнотипных элементов? В каких задачах это используется?


Я приводил пример с вариантом и базовым типом объектов, там элементы имеют один тип, но содержат данные разных типов. Например, в паскале мы можем передать массив элементов разного типа (на самом деле нет, но да) в параметре:
function Format(const Format : string; const Params : array of const);
...

Format('%d, %s, %f', [1, '2', 3.0]);

Достаточно распространненная функция

BFE> BFE>> Если array может хранить различные элементы, то чем он тогда отличается кортежа?


BFE> R>У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.


BFE> — а что же это?


Это условное именование элементов. Конечно, в каком-нибудь петухоне с динамической типизацией, элементы кортежа могут иметь индексный доступ, но именно благодаря дин. типизации. В общем, смысл в том, что в кортеже размеры элементов могут быть разными, поэтому индекс к ним можно прикрутить только "сбоку" (например, выразив кортеж через более сложную структуру), в массиве же их размер должен быть одинаковым, поэтому индексирование является естественным.

BFE> К тому же по вашей же ссылке для массива не обязательно иметь индекс, достаточно иметь ключ:


BFE> In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.


Это если говорить об интерфейсе "массив". Тогда да, в качестве индекса может выступать и ключ, а под капотом там может быть, например, хеш-таблица, и правильно это будет называться ассоциативным массивом. Если же говорить, о массиве, как базовой структуре, то это просто кусок памяти с индексным доступом.
avalon/3.0.2
Re[3]: JSON vs BSON: очередное торжество больного воображения и
От: swame  
Дата: 20.03.23 16:49
Оценка:
Здравствуйте, ·, Вы писали:

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


S>> Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам

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

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

S>>По скорости когда- то мерял, сериализация / десериализация по скорости в районе 400 Mb/c.

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

Это и так 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>>}
·>
Re[4]: JSON vs BSON: очередное торжество больного воображени
От: · Великобритания  
Дата: 20.03.23 17:40
Оценка:
Здравствуйте, swame, Вы писали:

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

S>Парсеры — форматтеры писать не надо, потому что это по формату обычный JSON, но сформированный с учетом определенных соглашений.
И кто определял эти соглашения? Где стандарт, поддержка этих соглашений в IDE и в разных либах?

S>Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.

Но ведь тебе всё равно придётся где-то парсить содержимое твоих строк. Ты просто перенёс логику из json-парсера наружу. И т.к. как парсер стал делать меньше работы, то и не удивительно замеры показали типа повысилась скорость. Но работа-то никуда не делась... просто ты исключил её из замеров.

Хотя возможно у тебя какой-то корявый медленный json-парсер, который лень фиксить или заменить, и проще обойти вот такими строками.

S>·>Переставь кавычки и получится простейший json.

S>Это и так json
У тебя значения в json требуют дополнительного парсинга. Вот в такой строке "0,analog_0,0,0,10,90,18" — могут быть хитрости. Например, что если значение нужно будет содержать запятую вроде analog_0,1?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 20.03.2023 18:01 · . Предыдущая версия . Еще …
Отредактировано 20.03.2023 17:44 · . Предыдущая версия .
Re[5]: JSON vs BSON: очередное торжество больного воображени
От: swame  
Дата: 20.03.23 18:12
Оценка:
Здравствуйте, ·, Вы писали:

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


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

S>>Парсеры — форматтеры писать не надо, потому что это по формату обычный JSON, но сформированный с учетом определенных соглашений.
·>И кто определял эти соглашения? Где стандарт, поддержка этих соглашений в IDE и в разных либах?

Определил я на уровне своей компании. На мировой стандарт не претендую.

S>>Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.

·>Но ведь тебе всё равно придётся где-то парсить содержимое твоих строк. Ты просто перенёс код из парсера наружу. И т.к. как парсер стал делать меньше работы, то и не удивительно замеры показали типа повысилась скорость. Но работа-то никуда не делась... просто ты исключил её из замеров.

Работы меньше. Размер файла меньше раза в 2-3.
Число узлов в DOM дереве при парсинге меньше на порядок. Соответственно и занимаемая память.
При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.

·>Хотя возможно у тебя какой-то корявый медленный json-парсер, который лень фиксить или заменить, и проще обойти вот такими строками.


Обычный, хороший парсер, просто, условно, вместо обработки миллиона атрибутов в секунду я обработаю 3 миллиона.
У меня объемы очень большие, лишняя скорость не помешает.

S>>·>Переставь кавычки и получится простейший json.

S>>Это и так json
·>У тебя значения в json требуют дополнительного парсинга. Вот в такой строке "0,analog_0,0,0,10,90,18" — могут быть хитрости. Например, что если значение нужно будет содержать запятую вроде analog_0,1?

Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.
Re[6]: JSON vs BSON: очередное торжество больного воображени
От: · Великобритания  
Дата: 20.03.23 18:26
Оценка:
Здравствуйте, swame, Вы писали:

S>>>Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.

S>·>Но ведь тебе всё равно придётся где-то парсить содержимое твоих строк. Ты просто перенёс код из парсера наружу. И т.к. как парсер стал делать меньше работы, то и не удивительно замеры показали типа повысилась скорость. Но работа-то никуда не делась... просто ты исключил её из замеров.
S>Работы меньше. Размер файла меньше раза в 2-3.
Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.

S>Число узлов в DOM дереве при парсинге меньше на порядок. Соответственно и занимаемая память.

Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...

S>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.

S>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).

S>·>Хотя возможно у тебя какой-то корявый медленный json-парсер, который лень фиксить или заменить, и проще обойти вот такими строками.

S>Обычный, хороший парсер, просто, условно, вместо обработки миллиона атрибутов в секунду я обработаю 3 миллиона.
...или вообще поди в память не надо складывать, а можно обрабатывать поточно на порядок быстрее.

S>У меня объемы очень большие, лишняя скорость не помешает.

С DOM хорошей скорости вообще практически никак не обеспечить.

S>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.

Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 20.03.2023 18:28 · . Предыдущая версия .
Re[15]: JSON vs BSON: очередное торжество больного воображен
От: CreatorCray  
Дата: 20.03.23 19:04
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>А вот и не подерётесь.
Автор: ·
Дата: 16.03.23

Что сказать то хотел?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: JSON vs BSON: очередное торжество больного воображен
От: CreatorCray  
Дата: 20.03.23 19:04
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Так что CreatorCray в чём-то прав с точки зрения практики, но совершенно не понимает в идеологии.


Идеология — зло.
Ибо есть теория а есть реальный мир. И уж слишком часто то, что красиво звучит в теории, на практике либо сразу лежит трупом либо лютый багодром, где "вша чОрная, вша жОлтая, и усеницы" (С)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: JSON vs BSON: очередное торжество больного воображени
От: swame  
Дата: 20.03.23 19:11
Оценка:
Здравствуйте, ·, Вы писали:

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


·>Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.


В файле разницы и правда не заметишь, а в памяти DOM разница будет на порядок.

Но я сравниваю не с этим а с обычным json
ID="0"
Name="analog_0"
Path=""
Tag="0"
Min="10"
Max="90"
Average="55"
Value="18"

·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...


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

S>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.

S>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).

Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM

·>С DOM хорошей скорости вообще практически никак не обеспечить.


Пока хватает без лищней сложности, перестанет хватать — перейду на поточный.
К тому же иногда DOM намного удобней, например для внесения точечных изменений — распарсил все, нашел узел, изменил, сохранил обратно.

S>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.

·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.

Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов в строку с разделителями,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
Даже на то, чтобы подобрать подходящий набор параметров для парсера в готовой либе может уйти прилично времени.
Отредактировано 20.03.2023 19:22 swame . Предыдущая версия . Еще …
Отредактировано 20.03.2023 19:17 swame . Предыдущая версия .
Отредактировано 20.03.2023 19:16 swame . Предыдущая версия .
Re[8]: JSON vs BSON: очередное торжество больного воображени
От: · Великобритания  
Дата: 20.03.23 20:14
Оценка:
Здравствуйте, swame, Вы писали:

S>·>Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.

S>В файле разницы и правда не заметишь, а в памяти DOM разница будет на порядок.
S>Но я сравниваю не с этим а с обычным json
Зачем?! Чтоб страшнее было?

S>·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...

S>Я не против событийного, когда понадобится по скоростным характеристикам, но сложность работы с ним будет точно не меньше , чем с моим форматом.
Уж точно не больше. Не бином ньютона, для твоего конкретной схемы json пишется за пол дня с 100% покрытием тестами.

S>>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.

S>>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
S>·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).
S>Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM
Мде. Костыль, короче.

S>·>С DOM хорошей скорости вообще практически никак не обеспечить.

S>Пока хватает без лищней сложности, перестанет хватать — перейду на поточный.
Ну раз ты начал изобретать свой формат, значит не хватало.

S>К тому же иногда DOM намного удобней, например для внесения точечных изменений — распарсил все, нашел узел, изменил, сохранил обратно.

Неясно с чего ты решил, что поточый обработчик будет почему-то сложнее.

S>>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.

S>·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.
S>Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов в строку с разделителями,
S>подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
S>Даже на то, чтобы подобрать подходящий набор параметров для парсера в готовой либе может уйти прилично времени.
Ясно, велосипед он свой, родной.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[16]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 21.03.23 13:43
Оценка:
Здравствуйте, CreatorCray, Вы писали:

BFE>>А вот и не подерётесь.
Автор: ·
Дата: 16.03.23

CC>Что сказать то хотел?

Так кто должен строку конвертировать "код импорта" или токенайзер?
И каждый день — без права на ошибку...
Re[20]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 21.03.23 14:20
Оценка:
Здравствуйте, ·, Вы писали:

BFE>>А ведь смысл-то есть, например:

BFE>>

BFE>>= is a special javascript character that must be escaped to unicode in JSON so that a string literal can be embedded in XHTML without further escaping.

·>Это откуда за цитата и о чём?
С просторов интернета о том, что преобразовывать escape последовательности следует не всегда.

BFE>>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?

·>Чтобы правильно и однозначно разбить поток символов на токены.
Для этого их достаточно распознать.
И каждый день — без права на ошибку...
Re[21]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 21.03.23 15:07
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>·>Это откуда за цитата и о чём?

BFE>С просторов интернета о том, что преобразовывать escape последовательности следует не всегда.
Это что к чему? Какое это имеет отношение к json и парсерам?

BFE>>>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?

BFE>·>Чтобы правильно и однозначно разбить поток символов на токены.
BFE>Для этого их достаточно распознать.
Чтобы их распознать, их надо фактически декодировать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 22.03.23 11:07
Оценка:
Здравствуйте, ·, Вы писали:

BFE>>С просторов интернета о том, что преобразовывать escape последовательности следует не всегда.

·>Это что к чему?
К тому, что строка содержащая escape последовательности может пригодится в том виде, в котором пришла.

·> Какое это имеет отношение к json и парсерам?

Это говорит о том, что существуют ситуации, когда от парсера json не требуется декодирование escape последовательности.

BFE>>>>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?

BFE>>·>Чтобы правильно и однозначно разбить поток символов на токены.
BFE>>Для этого их достаточно распознать.
·>Чтобы их распознать, их надо фактически декодировать.
Нет, не надо: достаточно просто найти конец строки.
И каждый день — без права на ошибку...
Re[20]: JSON vs BSON: очередное торжество больного воображен
От: B0FEE664  
Дата: 22.03.23 11:11
Оценка:
Здравствуйте, CreatorCray, Вы писали:

BFE>>Так что CreatorCray в чём-то прав с точки зрения практики, но совершенно не понимает в идеологии.

CC>Идеология — зло.
Докажите?

CC>Ибо есть теория а есть реальный мир. И уж слишком часто то, что красиво звучит в теории, на практике либо сразу лежит трупом либо лютый багодром, где "вша чОрная, вша жОлтая, и усеницы" (С)

Со стандартом Json мы имеем прямо противоположную ситуацию: практики попытались написать стандарт и написали один из худших стандартов в истории. Они написали такой стандарт, которому никто не следует и не использует.
И каждый день — без права на ошибку...
Re[23]: JSON vs BSON: очередное торжество больного воображен
От: · Великобритания  
Дата: 22.03.23 12:00
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>>>С просторов интернета о том, что преобразовывать escape последовательности следует не всегда.

BFE>·>Это что к чему?
BFE>К тому, что строка содержащая escape последовательности может пригодится в том виде, в котором пришла.
Я не понял зачем. По цитате вообще ничего непонятно. Без контекста смысла никакого.

BFE>·> Какое это имеет отношение к json и парсерам?

BFE>Это говорит о том, что существуют ситуации, когда от парсера json не требуется декодирование escape последовательности.
Называть такое парсером json язык не поворачивается. Скорее тулза для обработки json-текстов.

BFE>>>Для этого их достаточно распознать.

BFE>·>Чтобы их распознать, их надо фактически декодировать.
BFE>Нет, не надо: достаточно просто найти конец строки.
Каким волшебством-то? Чтобы его найти, надо побайтно прочитать вход и декодировать каждый символ до того момента как встретится нужный токен конца строки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: JSON vs BSON: очередное торжество больного воображен
От: CreatorCray  
Дата: 22.03.23 17:21
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Со стандартом Json мы имеем прямо противоположную ситуацию:

Взяли привычку отправлять с сервака сгенерированные скрипты и назвали стандартом

BFE>практики попытались написать стандарт

Получился ASN

Я тут давеча смотрел какой дизайн веберы сделали в гугле — местами данные отдаются даже не в JSON а просто присылается именно что кусок скрипта, с функциями и прочим говном, который предполагает что где то уже загружен другой скрипт и дёргает его, скармливая тому заинлайненые в него данные.
Так что это ещё ничего так.

BFE> и написали один из худших стандартов в истории. Они написали такой стандарт, которому никто не следует и не использует.

Дык никто его не писал. Они просто назвали свою плохую практику стандартом чтоб не доколупывались и не заставляли переходить на нормальные форматы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.