Comments 33
В CBOR мало того, что на ровном месте осложнили дебаг, используя тег
001, так ещё и не предусмотрели поддержку больших чисел.
Можно подробнее об этом? На cbor.me без проблем кодируется c избыточностью в 1 байт.
Еще такие вопросы:
Реализация только одна? Только TS? По этому параметру тоже нужно сравнивать!
Сравнение на реальных данных где-то уже выкладывали? Есть предположение, что CBOR на простых типах нифига не проиграет по избыточности.
Есть ли конвертируемость в/из JSON как в CBOR (без ext)?
Непонятно, чем BSON прибит к MongoDB, там есть все базовые типы, что и в MsgPack или JSON и несколько MongoDB specific, которые можно не использовать.
Поддерживать их всё равно придётся, даже если не используешь.
кто вас заставит поддерживать, если не нужно?
вот, скажем, библиотека поддерживает Bson, но только те типы, что есть в Json
https://github.com/nlohmann/json
В сравнении нет примеров, какие данные упаковывались и какой бинарь получился.
CBOR мало того, что на ровном месте осложнили дебаг, используя тег 001, так ещё и не предусмотрели поддержку больших чисел.
Маленькие числа упаковывает в 1 байт. Поддержка bigint заявлена с 2021 года.
Добавьте web-playgorund, будет убедительнее тысячи скриншотов.
Правда ли что из-за backref-ов требует линейную память при декодировании? Аналогичный вопрос при кодировании (но там проще, т.к. можно поддерживать только для шейпов (если пользователю ок)).
, так?
Продукт выглядит здорово. Спасибо, что делитесь им с миром.
Длина в символах же обычно известна заранее, так как в памяти строки обычно хранятся в двухбайтовой кодировке. Это позволяет быстро сериализовывать
Разные ЯП хранят строки по разному. Кто-то в UTF-16, кто-то в UTF-8, кто-то, возможно, иным способом.
К сожалению, 2 байт не достаточно для кодирования 1112064 символов Юникода, поэтому с даухбайтовой кодировкой (поддерживающей весь Юникод) нельзя за О(1) понять, сколько в строке символов. JavaScript хранит строки в UTF-16, а не UCS-2, то есть в строках могут быть суррогатные пары, кодирующие символ 4 байтами.
Вы не учли это и допустили ошибку в коде VaryPack. То есть в заголовке строки хранится не количество символов (как написано в статье), а количество пар байт в кодировке UTF-16.
А в каких языках юникодовые строки хранятся не в UCS-2?
JS хранит строки как раз в UCS-2. Именно поэтому смайлик '😀' имеет длину 2, а не 1.
Количество символов в кодировке UCS-2, если быть точнее. Суррогатные пары в ней представляются двумя отдельными кодепоинтами. Так что никакой ошибки там нет.
А в каких языках юникодовые строки хранятся не в UCS-2?
Например, C, Rust, Go, PHP. Там строки хранятся в виде байт, чаще в UTF-8, но бывают и в других кодировках.
JS хранит строки как раз в UCS-2. Именно поэтому смайлик '😀' имеет длину 2, а не 1. Количество символов в кодировке UCS-2, если быть точнее. Суррогатные пары в ней представляются двумя отдельными символами. Так что никакой ошибки там нет.
😀 это 1 символ, а не 2. Доказательства:
'😀'.codePointAt(0); // 128512, что больше 2 байт
[...new TextEncoder().encode('😀')]
.map(byte => byte.toString(2));
// ["11110000", "10011111", "10011000", "10000000"]
// Первый байт начинается с 11110, значит, это 1 символ длиной 4 байтаUCS-2 не может хранить символы с кодом выше 65535. Вы путаете с UTF-16, который хранит символы с более высокими кодами через суррогатные пары, которые не являются парами символов.
Возможно, вы путаете 😀 с другими эмодзи, которые действительно состоят из отдельных символов. Например, 👱🏿♂️.
C и PHP не поддерживают юникод, но да, преобразовывать пользовательские строки в UCS-2 для вычисления длины, чтобы потом преобразовать в UTF-8 для сериализации - было бы избыточно. В Rust строки в UTF-8, а значит их байтовая длина легко доступна, в отличие от числа кодепоинтов. В Go - UTF-8 или UCS-32, в зависимости от представления. Думаю лучше тогда перейти всё же на байтовые длины.
UCS-2 ничего не знает про суррогатные пары, отсюда и такие вот приколы:
Кстати, наткнулся тут на интересную кодировку: https://habr.com/ru/articles/521110/
Не путайте, символы ("кодпоинты") и кодюниты. Длина в js выдаётся в кодюнитах, но храниться всё же utf-16. Просто одна из фишек utf-16, что он позволяет разрезать один кодпоинт на две суррогатных пары.
Сами найдёте, где вы сами себя передушнили, или подсказать?
Не знаю, где там Вы и что нашли. Но факт остаётся фактом: js хранит строки в utf-16, не в ucs-2.
Всё правильно @cpud47 написал, за исключением того, что один кодпоинт может храниться в двух суррогатных парах. Суррогатная пара — это 2 кодюнита, т.е. 4 байта.
Кодпоинт — это число, номер символа в Юникода.
Кодюнит — это пара байт, их которых состоит строка в UTF-16. Кодпоинт (символ) кодируется одним или двумя кодюнитами. Когда двумя — это называется суррогатная пара.
В UCS-2 нет суррогатных пар. Она не может кодировать весь Юникод.
Знаешь, прочитал я эту статью, и такое чувство, будто меня хотят взять за ручку и мудро подвести к единственно верному выводу, как ребёнка. Всё тут такое... самоуверенное. «Проектируем как синьор» — название сразу настраивает на то, что сейчас будет какой-то высший пилотаж, откровение. А по факту — это просто очень качественная презентация своего же велосипеда .
Меня бесит эта манера говорить о конкурентах. «Дикий запад», «гвоздями прибит», «на ровном месте осложнили». Это не техническая критика, это троллинг. Когда хочешь доказать, что твоя штука лучше, ты показываешь цифры на честных тестах, объясняешь, почему в таком-то сценарии твой подход выигрывает. А здесь — просто навешиваешь на чужие форматы модные негативные ярлыки, а на свой — зелёные галочки.
И этот вечный оптимизм в адрес своего детища! Длина строки в символах — гениально, потому что «известна заранее». Мало того, что это спорное утверждение для мира за пределами его конкретной песочницы, так ещё и потенциальные минусы этого подхода (тот же blame на ленивое декодирование) тут же ловко превращаются в нейтральные или даже положительные пункты. А у конкурентов — сплошные «неизвестна», «кратно растёт». Однобоко как-то, не находишь?
Самое смешное — это пункт «Совместимость». У него стоит жирная галочка у VaryPack с пояснением «общий стандарт». Да какой же это «общий стандарт»? Это твой личный формат, который работает в твоей же библиотеке! CBOR — это RFC, его поддерживает полмира. MessagePack — де-факто стандарт для многих. А VaryPack — это красивая идея в твоём гараже. Называть это «общим стандартом» — это либо самообман, либо наглая подмена понятий для читателя.
Итоговые таблицы выглядят как полный разгром. Но когда начинаешь вглядываться, возникают вопросы. «Размер данных: 100%» против «+40%» у других. На основе чего? Какие данные сериализовали? Один маленький объект или гигабайтный дамп? Нет ссылок, нет методологии. Просто вера в слово автора. И скорость: его реализация «не сильно уступает», а другие «+20%» и «+50%». То есть они всё-таки быстрее? Но подаётся это так, будто это не важно, потому что у нас тут «формат лучше».
В общем, после прочтения остаётся осадок. Не от технической сложности, а от этого раздражающего патерналистского тона: «Забудьте всё, что вы знали, я сейчас вам расскажу, как надо по-настоящему». Хочется сказать: «Дружище, твой формат — возможно, отличная штука для твоих задач. Но перестань, пожалуйста, рядить свой субъективный техностек в мантию объективного технического прорыва. Ты не уничтожил индустриальные стандарты, ты просто сделал ещё одну нишевую альтернативу, идеально заточенную под себя. И в этом нет ничего плохого, пока ты не пытаешься выдать это за революцию».
Ссылки на онлайн-бенчмарки есть на странице библиотеки. Спасибо, что не поленились пройтись по ним, вместо того, чтобы высасывать тут претензии из продолговатых предметов. Впрочем, к теме статьи сравнение реализаций мало относится. Главное, что все реализации VaryPack концептуально совместимы. А вот все реализации того же CBOR потенциально не совместимы, из-за подхода к расширениям.
Через чур сильное утверждение про CBOR. Под .net, например, есть только одна неофициальная реализация. Написать документ и сгенерить реализации под все популярные языки не то чтобы проблема сейчас.
Опять непризнанный гений современности, имеющий свое особое мнение по всем вопросам, пиарит свой велик на потеху публике. Любимый сериал!
Как всегда радует презентация продукта, который подается как убийца конкурентов и единственно верное решение - спецификация на тысячу символов и пара картинок на фоне испуганного мальчика. Берегись, CBOR, ща тебя заменят!
Реально, каждый раз я пытаюсь понять что там автор хотел донести. Но каждый раз какой-то сюр получается. Вот была какая-то БД от автора. Как обычно презентуют БД? Ну там минимальный quickstart для затравки, доки, спецификации. Что у автора? Ну сами видите. Простой пример хрен сыщешь, вместо quickstart какая-то статья. Чтобы запустить и потрогать руками, предлагается погрузиться в лор авторских поделий - и система сборки авторская, и формат данных обязательно свой, ну и без mol никуда. Страница с АПИ - вообще кайф.
Проектируем как синьор: универсальная бинаризация