Есть небольшой массив байт — набор хэшей, длиной от 4 до 618 байт.
Нужно превратить его в UTF-8 строку. Если просто закодировать посредством Base64, получается слишком длинно.
Здравствуйте, LWhisper, Вы писали:
LW>Но, может быть, есть более эффективные способы кодирования? LW>Проверка целостности, обеспечиваемая Base64 не нужна.
Сжать 7z || zip, а потом в Base64. Компактно и надежно.
Здравствуйте, vmpire, Вы писали:
V>Есть Base85, например. V>Но непонятно, нужно ли это вообще, если массив и так небольшой. V>Подумайте, имеет ли смысл вообще экономить на спичках. Может, потери процессора окажутся болше, чем экономия памяти.
Base85 не подходит по той же причине, что и Base64 — удлинение исходной последовательности. Как минимум, хотелось бы получить эквивалентное число символов.
Небольшая потеря процессорного времени не так страшна, полученная строчка будет висеть в аттрибуте над помеченным типом, и, как следствие, чем короче она будет, тем лучше.
V>На таких которких данных сжатие особо не будет работать. Тем более, сжатие хэшей.
Вот тоже думаю, но поэкспериментирую.
V>Base64 не проверяет целостность
Имелась ввиду .NET реализация. Там есть проверка на кратность 4 и левые символы.
Re: Кодирование массива байт в UTF-8 строку (альтернатива Base64)
Здравствуйте, LWhisper, Вы писали:
LW>Есть небольшой массив байт — набор хэшей, длиной от 4 до 618 байт. LW>Нужно превратить его в UTF-8 строку. Если просто закодировать посредством Base64, получается слишком длинно.
Начните с задачи. Если вот это "полученная строчка будет висеть в аттрибуте над помеченным типом" про исходники, то в инструментах общего назначения оно не сработает. В куче компаний исходники ограничены ascii, всё прочее — escaped.
Re[2]: Кодирование массива байт в UTF-8 строку (альтернатива Base64)
Здравствуйте, Sinix, Вы писали:
S>Начните с задачи. Если вот это "полученная строчка будет висеть в аттрибуте над помеченным типом" про исходники, то в инструментах общего назначения оно не сработает. В куче компаний исходники ограничены ascii, всё прочее — escaped.
Но я ведь сказал — UTF-8.
Re[3]: Кодирование массива байт в UTF-8 строку (альтернатива
Здравствуйте, LWhisper, Вы писали:
LW>Но я ведь сказал — UTF-8.
Ну так исходная задача какая? А то ты пока описал своё решение, которое тебя не устраивает, а саму проблему не расписал.
Здравствуйте, LWhisper, Вы писали:
S>>Ну так исходная задача какая? А то ты пока описал своё решение, которое тебя не устраивает, а саму проблему не расписал. LW>Закодировать произвольную последовательность байтиков в максимальную короткую строчку в кодировке UTF-8.
Это, надеюсь, просто этюд, а не реальная задача?
Если этюд, то читаем https://en.wikipedia.org/wiki/UTF-8 и выясняем, что нужно реализовать Base1112064 encoding.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Кодирование массива байт в UTF-8 строку (альтернатива
Здравствуйте, LWhisper, Вы писали:
LW>Закодировать произвольную последовательность байтиков в максимальную короткую строчку в кодировке UTF-8.
Это не задача, это то, как вы собираетесь её решить.
Диалог примерно такой:
- 42! Ну, что скажете?
— Вопрос-то в чём?
— 42!!
— Ну а поточнее?
— 42.000000!!!
— ок.
В общем от меня — ок.
Re[6]: Кодирование массива байт в UTF-8 строку (альтернатива
Здравствуйте, LWhisper, Вы писали:
LW>Есть небольшой массив байт — набор хэшей, длиной от 4 до 618 байт. LW>Нужно превратить его в UTF-8 строку. Если просто закодировать посредством Base64, получается слишком длинно. LW>Но, может быть, есть более эффективные способы кодирования? LW>Проверка целостности, обеспечиваемая Base64 не нужна.
Сделай словарь (просто строковую константу в данном случае) из уникальных символов длиной в 256 символов — кодирование хэша будет заключаться в замене каждого байта символом из словаря с индексом равным значению байта; декодирование в присвоении значению байта индекса соответствующего символа в словаре.
Re: Кодирование массива байт в UTF-8 строку (альтернатива Base64)
Здравствуйте, LWhisper, Вы писали: LW>Но, может быть, есть более эффективные способы кодирования?
UTF-8 — уже и есть кодирование.
Самое плотное кодирование (7 бит на байт) достигается при использовании старшего 0.
Если речь о хороших хеш-кодах, то в них будет недостаточно избыточности, чтобы хоть какой-то алгоритм компрессии мог что-то из них выжать.
Поэтому жать ничем не надо. Просто берёте биты и пакуете их в UTF-8.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Кодирование массива байт в UTF-8 строку (альтернатива Base64)
Здравствуйте, Sinclair, Вы писали:
S>Если речь о хороших хеш-кодах, то в них будет недостаточно избыточности, чтобы хоть какой-то алгоритм компрессии мог что-то из них выжать.
Если хешей много и их порядок не важен, то можно их отсортировать после чего вычесть соседние друг из друга.
Тогда мы получим избыточность, которую можно сжать.
Степень сжатия зависит от размеров хешей и их количества.
Миллион CRC8 таким образом можно сжать очень сильно.
Сотню SHA256 сжать скорее всего не получится совсем. Миллион можно немного сжать, но не факт, что оно того стоит.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Кодирование массива байт в UTF-8 строку (альтернатива
Здравствуйте, WolfHound, Вы писали: WH>Если хешей много и их порядок не важен, то можно их отсортировать после чего вычесть соседние друг из друга.
Так не получится. Речь не о хранении пачки хешей, а о представлении отдельного хеша. WH>Тогда мы получим избыточность, которую можно сжать. WH>Степень сжатия зависит от размеров хешей и их количества. WH>Миллион CRC8 таким образом можно сжать очень сильно.
Массив CRC8 любого размера можно без потерь пожать до 32 байт, если неважен порядок и количество повторов. Коэффициент компрессии будет стремиться к бесконечности.
Но это не та задача, которую решает топикстартер.
UPD: хотя, может быть и та.
Если всё же речь именно о наборе хешей, то да — можно применять компрессию, основанную на знаниях особенностей. Отбрасывание информации о порядке следования уже даёт хорошую экономию — отсортировав хеши, мы уменьшим матожидание дистанции между ними в N раз по сравнению с полным разбросом. Т.е. для хранения разницы нам потребуется в среднем на log2(N) бит меньше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>UPD: хотя, может быть и та. S>Если всё же речь именно о наборе хешей, то да — можно применять компрессию, основанную на знаниях особенностей. Отбрасывание информации о порядке следования уже даёт хорошую экономию — отсортировав хеши, мы уменьшим матожидание дистанции между ними в N раз по сравнению с полным разбросом. Т.е. для хранения разницы нам потребуется в среднем на log2(N) бит меньше.
Именно та.
Всем спасибо, вопрос исчерпан.
Вопрос-то в чём?
