Устаканился формат кодирования YAC

Что: 95425c88b8df424f92b5e95529ce4ae2a0d4da75

Когда: 2024-11-07 11:25:32+03:00

Темы: yac

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

Вот только кодирование int-ов меня напрягало. А ведь, казалось бы, самая
такая простая и базовая вещь в компьютерах, которые с числами и работают.
Закодировать фиксированной длиной: может быть большой overhead.
Закодировать с выбором длины (8, 16, 32, ...): тоже неплохо, но нет
bigint-ов. В тэге есть много места и напрашивается возможность вшивания
и длины и маленьких значений int-ов в него. И так у меня долгое время и
было: длины int-ов от 1 до 16 вшивались, и значения до 32-х тоже.

Не давала покоя мысль о том, что берёшь Tcl, берёшь Python -- и там
везде int-ы без ограничений по умолчанию. В MessagePack bigint-ов нет.
В CBOR они эмулируются через тэг добавленный к строке (тоже по сути нет).
Но раз YAC заявляет, что может заменить прозрачно JSON, то значит bigint
обязателен. Ввёл ещё 8 и 64-бит кодирование его длины. Вышло так, что
для кодирования int-а есть аж четыре разных способа в итоге. Перебор и
безумие. Хотя, да, компактно.

Всё это надоело и пришёл к следующему: оставляю только bigint
кодирование, сделанное в виде обычной уже существующей бинарной строки,
перед которой тэг указывает что это положительный или отрицательный int.
По факту -- как в CBOR, но только у меня нет тэгов, а это просто особое
кодирование int-ов. Тэги CBOR ой как не все поддерживают. 0/-1
кодируются двумя байтами. До 256 -- тремя. Не так компактно как было, не
так как в MessagePack или CBOR. Но схоже с ASN.1 BER. Зато экономнее
всего по коду, плюс появились bigint-ы, прозрачные для использования в
Tcl/Python.

И вот сейчас я полностью удовлетворён кодированием. Надо только тестами
уже покрыть это всё.

оставить комментарий

Сгенерирован: SGBlog 0.34.0