JSON vs BSON: очередное торжество больного воображения и кривых рук - Компьютерные священные войны

Здравствуйте, 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 хорош там, где он служит чем-то вроде сокета для обмена с третьесторонним окружением.
А так-то хрень полная.
И вся его избыточность как раз для того, чтобы покрыть как можно больше сценариев, оставив как можно меньше простора для ошибок в каждом из них.
В общем по-классике — самое общее решение является самым худшим для конкретного случая.

Здравствуйте, 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++.

Здравствуйте, 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.

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

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

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

Здравствуйте, 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 приехал. Это и есть доказательство универсальности формата — он прекрасно лёг подо все языки, что никому не пришлось "корёжить" оригинальный формат.

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

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

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

Да, всё по спеке же.

Здравствуйте, 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>Никаких лишних знаков препинания.

Здравствуйте, 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-подобного синтаксиса.

Здравствуйте, 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 не было обязательным заключать имена атрибутов в кавычки, это требование появилось позже.

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

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

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

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

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

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

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

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

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

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

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

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

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

νsb>>>Если не ошибаюсь, это старый юниксовый принцип — будь либерален в том, что принимаешь, будь строг в том, что отдаёшь.
BFE>>Так вот почему в этом семейсте систем ничего нормально не работает...
vsb>Это в самой популярной ОС, на которой весь мир стоит, ничего нормально не работает?
А вы не замечали, что самое популярное почти всегда плохого качества?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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.

	От:	vsb
	Дата:	02.12.22 11:37
	Оценка:

	От:	vdimas
	Дата:	02.12.22 23:36
	Оценка:	-1

	От:	pilgrim_
	Дата:	03.12.22 00:13
	Оценка:	1 (1)

	От:	Baiker
	Дата:	03.12.22 09:00
	Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	03.12.22 09:35
Оценка:

	От:	B0FEE664
	Дата:	05.12.22 10:49
	Оценка:

	От:	B0FEE664
	Дата:	05.12.22 11:17
	Оценка:

	От:	B0FEE664
	Дата:	05.12.22 11:17
	Оценка:	-1

	От:	B0FEE664
	Дата:	05.12.22 13:40
	Оценка: