Комментарии 38
Заранее прошу прощения у своего ДИБ ?
В свое время нужно было скачать JAR общедоступной библиотеки (мавен зависимость), но в локальном Nexus ее не было (нужно было ждать добавления), а все попытки (переименование, архивирование, с паролем) переслать jar через почту резались антивирусом. Тогда на помощь пришла утилита конвертации в PNG.
Не нужна никакая утилита, пакуете файл в zip и вызываете
copy /b image.png + archive.zip output.png
На выходе файл output.png который выглядит как исходная картинка, а при переименовании в output.zip "превращается" в архив с исходным файлом
Не фортануло:
File "image.png", size 235609 was deleted by Kaspersky Secure Mail Gateway
Anti-Virus status: Clean
Threats found:
Content filtering status: BannedFileFormat, BannedFileName
Благодаря английскому алфавиту каждый символ можно описать одним байтом
Английский язык и его пунктуация не особо сложны, так что пьеса содержит всего 77 уникальных символов. Значение ASCII каждого символа находится в интервале от 0 до 127
Первое утверждение немного противоречит второму (более точному), для английского достаточно семи бит
Но ведь одним байтом можно описать, два не требуется. В чём противоречие?
Благодаря английскому алфавиту каждый символ можно описать одним байтом
Можно сравнить это с утверждением:
Благодаря русскому алфавиту каждый символ можно описать одним байтом,
то же будет справедливым, по-видимому, для любого европейского языка. Неточность эта не бог весть какая серьезная, но все же фраза не вполне логична, особенно когда речь идет о сжатии текста
Сравнить утверждения можно, но в ваше - заведомо ложное.
В английской латинице 1 символ = 1 байту. В русской кириллице 1 символ занимает 2 байта. Так что, эта фраза не будет справедлива для других языков. А в некоторых странах в латинице есть дополнительные символы. Например ł, å, ø - каждый весит по 2 байта
Сравнить утверждения можно, но в ваше - заведомо ложное.
Надеюсь, вы осознаете, что ваше утверждение является слишком уж безапелляционным? Вы что-нибудь слышили об однобайтовых кодировках Windows-1251, КОИ-8?
В русской кириллице 1 символ занимает 2 байта.
Вам не кажется. что это утверждение ложно до тех пор, пока не указано, о какой кодировке идет речь?
При чем тут windows-1251 или кои-8 если в статье речь идет о Unicode?
автор сначала сделал ложное (или точнее - кривое) утверждение, а только потом выбрал Unicode.
в латинском 26 букв, так что достаточно 5 бит, это известно всем, кто хоть что-то читал по кодированию английских символов. даже добавляя знаки препинания и цифры трудно выбраться за 6 бит, не говоря о 7.
утверждение автора про "уникальность" английского и требование всего одного байта является несуразным допущением, так как к свойству английского это вообще не относится.
более корректно было бы написать, что так как английских символов, цифр и знаков препинания сильно меньше чем 256, то можно использовать 1 байт для кодирования такой информации. Но эта фраза для меня, человека из 80-х, сама по себе режет слух не хуже изначальной авторской, так как история ПК и расцвет в 8-битную эпоху как бы намекает, что "256 символов хватит всем".
Выходит, что байт уже избыточен.
Байты файла интерпретировали не как буквы, а как точки? С некоторой степенью упрощения, игнорируя формат записи данных в png, можно сказать, что содержимое файла не поменялось, лишь добавились картиночные заголовки?
В png есть однобайтный монохромный формат, или там всегда RGB в три байта? А то можно было три буквы в одну точку собрать. Картинка бы визуально уменьшилась.
Ещё нужно решить проблему определения того, что текст уже кончился, а до заполнения прямоугольника картинки ещё есть место. Нужно отдельно сохранять длину.
А еще текст можно сжать в звук...
Так ведь формат PNG использует тот же алгоритм сжатия Deflate, что и ZIP. То есть по сути можно было просто записать текст в семибитной кодировке как битовый массив, а потом сжать обычным архиватором. И так размер должен получиться еще немного меньше, так как не потребуется заголовок PNG. Разве нет?
А как текст в картинку превратить!? Есть утилиты!? Разные шпионы и нехорошие люди кидались в дру друга картинками.
Берётся код символа, которые заведомо меньше 256, и рисуется точка с яркостью, равной этому значению.
Только нужно подобрать ширину и высоту картинки такие, чтобы остался как можно меньший пустой хвост. То есть, найти такие A и B, чтобы (A x B - textLength) было нулевым или положительным, но минимальным из возможных.
Самый сильная компрессия текста достигается с помощью языковых моделей (наподобие ChatGPT). См. "LOSSLESS TEXT COMPRESSION USING LARGE LANGUAGE MODELS". Основная идея - в предсказании следующего токена. В примерах было 0.77 бит на символ. Для сравнения, у Zlib - 2.55.
Есть некоторое подозрение, что словарь, который нужно при этом таскать вместе с распаковщиком, превзойдёт по размеру любые несжатые файлы. Проще будет оставить файл с исходным текстом.
Ваш комментарий напомнил мне «архиватор Бабушкина». Там никакие словари не нужны.
Если бы только словарь токенов - это полбеды, это всего лишь алгоритм Хаффмана. Более популярные токены - короткий код, редкие - длинный. LLAMA требует огромные ресурсы для предсказания следующего токена и это сжимает гораздо лучше Хаффмана. Например, 1 (один бит), если следующий токен совпал с предсказанным и 0+ID токена, если не совпал. Настоящий алгоритм сложнее, но не суть. Да, требуется неординарная вычислительная мощность и память для сжатия и распаковки, но это максимально плотное сжатие текстов, превосходящее все, что было до сих пор. Практически, разумеется, малоприменимо.
Английский язык и его пунктуация не особо сложны, так что пьеса содержит всего 77 уникальных символов. Значение ASCII каждого символа находится в интервале от 0 до 127. Давайте создадим изображение в оттенках серого, в котором каждый пиксель имеет тот же уровень серого, что и значение ASCII символа.
Непонятно, почему точки на изображении имеют яркость в диапазоне 0-127, а не 0-77. Если точнее, то в Пейнте нашел точки с яркостью от 10 до 117, но ширина диапазона все равно больше, чем 77.
Ключевая ошибка автора тут в том, что тексты явно стоит сжимать не по буквам, а по словам - т.е. надо сначала составить словарь слов - перекодировать им текст, и только потом уже думать о преобразовании текста в изображение - т.е. условно говоря работать с палитрой.
Более того, в тексте ещё и разные сочетания слов любят повторяться - их тоже можно пытаться представить разными цветами. Причём тут ещё интересна тема того, что есть достаточно большое множество случаев, когда несколько подряд идущих - 3 или 4 часто в одном и том же тексте имеют не так уж много вариаций различного сочетания - их можно выявлять и кодировать очень сжатой форме - номер группы сочетания и подномер варианта.
Отдельная тема - знаки препинания - их формат кодирования должен иметь отличия и их нужно выносить на отдельный слой кодирования.
Но вообще - моё мнение - узкоспециализированный алгоритм сжатия текста, учитывающий специфику построения текстовых данных - сожмёт всегда лучше, чем какой-либо алгоритм другой направленности! Если говорить об обычном ёмком тексте, а не случайно сгенерированной тарабарщине, или каких-то очень специфических тексах, требующих для сжатия очень специфических подхода!
Но другое дело - это вопросы криптографии и стенографирования - тут уже другие критерии выходят на первое место, но вопрос сжатия тут тоже стоит очень остро
А как насчёт сжатия в jpg? На если текст упаковать в картинку а потом в сохранить аак в jpg, а затем обратно развернуть в текст то как сильно испортится текст?
Сжимаем текст в изображения PNG