LINUX.ORG.RU
ФорумTalks

Встречайте кодировку будущего — base💯

 , ,


1

2

Для Ъ: https://github.com/AdamNiederer/base100

Для !Ъ:

$ echo "the quick brown fox jumped over the lazy dog" | base100
👫👟👜🐗👨👬👠👚👢🐗👙👩👦👮👥🐗👝👦👯🐗👡👬👤👧👜👛🐗👦👭👜👩🐗👫👟👜🐗👣👘👱👰🐗👛👦👞🐁

Base💯 is very space inefficient. It bloats the size of your data by around 3x, and should only be used if you have to display encoded binary data in as few printable characters as possible. It is, however, very suitable for human interaction. Encoded hashes and checksums become very easy to verify at a glance, and take up much less space on a terminal.

$ base100 --version
base💯 0.2.0

$ base64 --version
base64 (GNU coreutils) 8.28

$ cat /dev/urandom | base100 | pv > /dev/null
 [ 502MiB/s]

$ cat /dev/urandom | base64 | pv > /dev/null
 [ 232MiB/s]

$ cat /dev/urandom | base100 | base100 -dF | pv > /dev/null
 [ 223MiB/s]

$ cat /dev/urandom | base64 | base64 -d | pv > /dev/null
 [ 176MiB/s]

Как видно, base💯 — современная программа и не ущемляет права меньшинств.

Deleted

Внесите шизика!

dk-
()

У меня аж курсор задёргался на этой странице.
Но к чести набора Noto — квадратиков нет.

dogbert ★★★★★
()

Эх, надо мне допиливать мою 6-ти битную кодировку, которая содержит 151 видимый символ. Вот это будет кодировка будущего. Не то что сабжевая.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Я тебя тут кастую, вспоминаю, как ты пишешься, а ты сам пришёл.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от saahriktu

которая содержит 151 видимый символ

мозг инженера в действии:

не представляю, как можно использовать больше 151 символа
151 символа хватит всем

мозг продвинутого инженера:

мы знаем, что есть проблема 152-го символа, но её ещё не скоро решать, этим займутся потомки.

system-root ★★★★★
()

Интересно, если напечатать и отсканировать, какие-нибудь OCR это распознают? Последний FineReader?

TheAnonymous ★★★★★
()
Ответ на: комментарий от system-root

Настоящий инженер должен думать так:
Для 151 символа всё равно надо 8 бит на символ, по этому пусть их будет 256, но стандартизируем пока только 151.

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
$ cat /dev/urandom | base100 | pv > /dev/null
 [ 502MiB/s]

$ cat /dev/urandom | base64 | pv > /dev/null
 [ 232MiB/s]

Выполнение этих команд даст другой результат. Расходимся нас обманули.

Siado ★★★★★
()
Ответ на: комментарий от torvn77

Для 151 символа всё равно надо 8 бит на символ

Только в распакованном виде. С триме может быть 5-6-7 например.

Stil ★★★★★
()
Ответ на: комментарий от Stil

Ну смотри, система выделяет память блоками байт, процессор обрабатывает байты.
Это значит что если информация упакована плотнее этого байта то для работы с ней её всё рано придётся распаковывать до состояния одна «информационная единица» на один байт.

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Ну так поэтому кодировщик/декодировщик будет основан на дополнительной библиотеке, которая пакует/распаковывает группы битов в байты и обратно. Так, например, каждые 4 байта, которые содержат по 6 значащих битов, будут запакованы в 3 байта, а при декодировании наоборот - каждые 3 байта будут становиться 4-мя байтами в каждом из которых по 6 значащих битов.

saahriktu ★★★★★
()
Ответ на: комментарий от torvn77

const uint8_t single_char = (input_byte & 0xf0) >> 4;

Это не аллокация, если что. Что до стрима – он аллоцирует память сразу под всю последовательность символов (с округлением до байта), и сколько там бит на один символ не особо важно (ну только в контекстах распаковки/упаковки).

Stil ★★★★★
()
Последнее исправление: Stil (всего исправлений: 2)
Ответ на: комментарий от saahriktu

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от torvn77

А эта кодировка для read only текстов, которые никто и не собирается редактировать. Чтобы они в итоге были сильнее пожаты. Собственно, и сабжевая кодировка не предполагает редактирование текстов.

А для read-write работы с текстом уже есть KOI8-R.

saahriktu ★★★★★
()

мне уже нравится

Harald ★★★★★
()

Надеюсь, их там психиатры лечат.

WereFox ★☆
()
Ответ на: комментарий от saahriktu

Чтобы они в итоге были сильнее пожаты

расскажи юзкейс, как много у тебя текстов, и почему не возможно их пожать другими способами?

system-root ★★★★★
()
Ответ на: комментарий от system-root

как много у тебя текстов

Сотни гигов. И это уже пожатых lzma.

почему не возможно их пожать другими способами?

Можно, но не так хорошо.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Сотни гигов. И это уже пожатых lzma.

А от того, что ты сделаешь супер-сложную кодировку, которая жмет файл (кстати, как ты её реализуешь, что для записи 151 символа тебе надо всего 6 бит, а не 8 (2^6=64 символа)). Да, кстати, количество информации не уменьшится от предварительного пожатия, а следовательно LZMA просто станет хуже жать и размер твоих файлов не изменится, разве что подрастет из-за того, что LZMA может быть оптимизирован для текста.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Архиваторы жмут по принципу закономерностей. Одинаковые последовательности байтов должны жаться одинаково хорошо независимо и от их содержимого, и от того как и кто их интерпретирует.

кстати, как ты её реализуешь, что для записи 151 символа тебе надо всего 6 бит, а не 8

Через 2 управляющих кода: переключение регистра и рус/лат. Да, если они часто применяются, эффект будет не тот. Но, в обычных текстах они нужны не так уж и часто.

saahriktu ★★★★★
()
Ответ на: комментарий от system-root

Выше писал про библиотеку, которая будет паковать группы битов в байты. И каждые 4 байта с 6-ю значащими битами будут становиться 3-мя байтами.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Это кодировка с переменным количеством бит, как выше правильно заметили, прямо скоро utf-8 изобретешь, только utf-6

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от pftBest

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

saahriktu ★★★★★
()
Ответ на: комментарий от peregrine

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

saahriktu ★★★★★
()

Прикольно. А в чем смысл? Квковы сценарии использования?

PanZagloba
()
Ответ на: комментарий от KivApple

Как можно не уведитеть буквально предыдущий комментарий?

pftBest ★★★★
()
Ответ на: комментарий от KivApple

Через 2 управляющих кода: переключение регистра и рус/лат. Да, если они часто применяются, эффект будет не тот. Но, в обычных текстах они нужны не так уж и часто.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Чтобы они в итоге были сильнее пожаты.

Это будет тест на негодный алгоритм компрессии.

greenman ★★★★★
()
Ответ на: комментарий от saahriktu

Эх, надо мне

Не надо. Ты всё равно в пьяном (или другом) угаре ей наркоманское название даш, которое никто не станет запоминать, так что она сразу канет в безызвестность.

grem ★★★★★
()
Ответ на: комментарий от saahriktu

Запили лучше π-битную кодировку.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.