Комментарии 23
Судя по описаниям, SCSU — самое оно. Особенно для собственного клиента.
Правда не совсем понял что такое:
Можешь привести пример возможных конфликтов?
Правда не совсем понял что такое:
SCSU неподходящим форматом для таких протоколов как MIME
Можешь привести пример возможных конфликтов?
Нет, пример привести не могу. В спецификации MIME заголовков указанно, что внутри поля заголовка не должны встречаться символы CR и LF, а результатом SCSU кодирования не латинских символов могут быть как раз CR (0x0A) и LF (0x0D).
Так в MIME-заголовках и так только ASCII может быть (по крайней мере так интерпретируют большинство софтописателей).
Возможно, вы имели в виду, что перекодирование CR/LF внутри тела письма зависит от заголовка Content-transfer-encoding (не перекодируется только в случае binary и base64) и особенностей конкретного почтового ПО(?)…
Возможно, вы имели в виду, что перекодирование CR/LF внутри тела письма зависит от заголовка Content-transfer-encoding (не перекодируется только в случае binary и base64) и особенностей конкретного почтового ПО(?)…
Применение архиватора общего назначения, когда объем данных меньше килобайта, редко дает положительный результат. Возможно, имеет смысл рассмотреть схему с внешним словарем.
Согласен. Вполне можно, кстати, подобрать свое дерево хафмана с соотв. кодами для оптимального сжатия.
Где можно почитать примеры реализации (или уже готовые библиотеки) для сжатия данных со внешним словарем?
Впереди маячит задача когда клиент и сервер передают друг другу плохо упаковываемые данные но содержащие много данных, передаваемых в прошлых запросах, пока есть идеи используя технологию binary diff — высылается разница между неким шаблоном и самим сообщением. Однобокое решение требует допиливания (шаблонов много, какой использовать решить нетривиально и данные в сообщении могут перемешиваться, что не отлавливается этим методом).
Впереди маячит задача когда клиент и сервер передают друг другу плохо упаковываемые данные но содержащие много данных, передаваемых в прошлых запросах, пока есть идеи используя технологию binary diff — высылается разница между неким шаблоном и самим сообщением. Однобокое решение требует допиливания (шаблонов много, какой использовать решить нетривиально и данные в сообщении могут перемешиваться, что не отлавливается этим методом).
Я не занимался этим вопросом применительно к тексту, к сожалению. Думаю, в случае с VCARD должна неплохо работать схема из PPM + Хаффман (либо арифметическое кодирование). Особенность в Вашем случае в том, что словарь для Хаффмана можно тренировать один раз на некотором наборе сэмплов, а не для каждого файла. Т.к. данные достаточно однородные, проигрыш в сжатии не должен быть очень большим, зато можно не передавать словарь каждый раз. Кроме того, думаю, похожую идею можно применить и к PPM.
А можно, собственно, уточнить — какая именно задача оптимизации ставилась? Карточки будут передаваться/сжиматься для передачи по одной? Какие мощности будут в распоряжении передающей/принимающей стороны? Сколько времени и ресурсов можно позволить себе потратить на сжатие/разжатие?
Для этого конкретного случая — хранение визитки в двумерном штрихкоде. Считывание мобильными устройствами. На мобильных телефонах можно устойчиво распознавать штрихкоды содержащие до 500 байт.
При таких исходных данных, юникод компрессия может показывать результат лучше чем универсальные алгоритмы.
При таких исходных данных, юникод компрессия может показывать результат лучше чем универсальные алгоритмы.
Теперь понятно — тогда полностью согласен, что для такой задачи это будет оптимальное решение. А то всё гадал, для чего это может понадобиться ужимать _один_ пакет на сотню байт. Любые сетевые передачи, о которых я думал, упирались в размер пакета порядка килобайта — экономия сотни байт здесь вряд ли что-то радикально дала бы. Хотя, если MTU до 576 опускать — может тогда и здесь было бы тоже актуально…
В таком случае, наверное, еще полезно было бы сжать VCARD сам по себе: убрать максимум метаинформации, перейти к обозначению полей какими-нибудь бинарными тэгами и т.п.
В таком случае, наверное, еще полезно было бы сжать VCARD сам по себе: убрать максимум метаинформации, перейти к обозначению полей какими-нибудь бинарными тэгами и т.п.
Тут изначально задумка была получить VCard, который смогут читать сторонние штрих-читатели, судя по
Меня очень удивило, что ни один из распространенных ридеров штрих кодов не распознает SCSU или BOCU-1.
Ридеры штрих-кодов выдают байтовый поток — зачем им что-то с ним делать? А вот то, куда ридер подключен — там можно и раскодировать этот поток, и сделать lookup в базу, и еще много чего, как правило.
Даже для standalone ридеров — как правило, есть какая-то возможность их программировать — сколько правда их видел — они почему-то все под DOS были: туда через COM-порт передается com/exe/bat-файл, который может вызываться и что-то там с полученными данными делать.
Даже для standalone ридеров — как правило, есть какая-то возможность их программировать — сколько правда их видел — они почему-то все под DOS были: туда через COM-порт передается com/exe/bat-файл, который может вызываться и что-то там с полученными данными делать.
Да рассматривал и вариант изменения VCARD (пример). Но во-первых, кто еще, кроме меня, будет поддерживать мой велосипед. А во-вторых, VCARD (особенно 3.0) интересен сам по себе: многоязычные визитки, версии и источник визитки. Придумывать самому, обязательно бы что-то пропустил.
Спасибо за обзор. Проблема актуальна, особенно в WEB.
В классическом вебе уже давно (очень давно) применяется и gzip и bzip алгоритмы сжатия потока… Даже из вышеприведенных графиков непонятен смысл сжатия дважды в web.
Может пригодиться в будущем Bluetooth low energy.
А при хранении nchar в SQL Server в SCSU экономия пространства составляет от 15% до 50%.
А при хранении nchar в SQL Server в SCSU экономия пространства составляет от 15% до 50%.
«А при хранении nchar в SQL Server ...» — А если взять базу, шринкнуть и запаковать в какой-нибуд 7z архив… вот там экономия… но ведь это не относится к вебу, не так ли?
Равно как и блутувз — оно, конечно, очень (наверно) будет круто съкономить чуть-чуть энергии в блутувс модуле на передачу, при этом потратив б0льшее количество (наверняка) энергии на сжатие\распаковку.
Равно как и блутувз — оно, конечно, очень (наверно) будет круто съкономить чуть-чуть энергии в блутувс модуле на передачу, при этом потратив б0льшее количество (наверняка) энергии на сжатие\распаковку.
Интересно, что за проект )
Вообще VCard нормально хранится в Latin-1 с использованием для UTF-8 кодирования Quoted-Printable. Обычно полей не с латиницей одно-два, и это очень эффективно.
Кроме того, обычно при работе с карточками интересно бывает работать с отдельными полями. А архивирование карточки целиком сильно усложняет дело.
Вообще VCard нормально хранится в Latin-1 с использованием для UTF-8 кодирования Quoted-Printable. Обычно полей не с латиницей одно-два, и это очень эффективно.
Кроме того, обычно при работе с карточками интересно бывает работать с отдельными полями. А архивирование карточки целиком сильно усложняет дело.
Проект — VCard в двумерном штрихкоде (см. выше)
Как вариант, может быть стоит попробовать VCard перевести в base64 encoding (т.е. получить всего всего 64 различных символа) и построить статический словарь для метода Хаффмана или арифметического метода. После перевода в base64 размер текста увеличится на 30%, но статический словарь из одних двухбуквенных слов уже позволит эти 130% уменьшить в 2 раза. Если нет ограничения на размер словаря то можно и и все трехбуквенные слова в него внести, и четырех и т.д.
github.com/aamarks/bocu — JS implementation
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сжатие Юникод данных