Ma1ahov, для этого приложение нужно нодписать. Чтоб подписать стандартным сертефикатом, то для этого над 200-300". Или ставь даркмена в телефон и подписуй безплатно

Ma1ahov, пользуйся прогами на симбе елки палки, они все видят и работают на много быстрей.

Здраствуйте Уважаемый Malcolm - к сожалению не знаю вашего имени. Очень хотел бы взглянуть на исходники вашего PPM алгоритма. Тут занялся доработкой приложения. Имеется Java приложение j2me под сотовый телефон (некое подобие букридера но с жестко заданным контентом в виде большого количества текстовых файлов рассованых по папкам) - оно представляет собой JAR файл который есть ни что иное как архив (созданый автоматически при компиляции) с помощью архиватора ZIP (deflate) в который упакованы исходники-классы JAVA программы (они весят очень мало не более 100 кб) и сам контент в виде большого числа небольших текстовых файлов по 3-10 кб каждый. В комплексе они весят 3,5 мГб. То есть прога и тексты в одном JAR. Задача - как лучше обработать каждый текстовый файл что бы потом автоматически применяемая ZIP компрессия дала хорошее ужатие? Вообще стоит ли копать в этом направлении?

Уже попробовал метод Хаффмана - ZIP его не ужимает практически и лучший результат получается если жать напрямую без Хаффмана. Пришёл к выводу что ZIP любит данные кратные байту - из за этого такие проблемы. А то бы стоило применить 6 бит на символ вместо 8-ми - но похоже надо делать словарь как минимум из 256 сочетаний символов. Сегодня поробывал как бы уменьшить словарь в 2 раза введя спец символ для обозначения верхнего регистра букв русского алфавита - что нашёл в рекомендациях. Надеялся вдруг это понравится стандартно применяемому архиватору ZIP - не понравилось - ZIP лучше жать не стал. Даже не знаю что ещё придумать для обработки текстовиков, что бы потом ZIP всю эту кучу нормально ужимал.

В моём случает от ZIP нельзя отказаться. Это стандартное ужатие мобильных приложений - оно все равно применится по верх всех данных. Я подозреваю что как то надо уменьшить представление текстов, но что бы оно было в кратном байту виде - то есть надо строить словарь на 256 (или 4096) комбинаций символов (одиночных и диграм допустим) кратных байту. Видимо только это понравится ZIP. Словарь естественно применять нужно статический - так как динамический и так применяется в ZIP. По идее и сам ZIP должен все эти статические комбинации находить - и поэтому есть вероятность получить результат ещё хуже чем без сжатия. Если получится так, то нужно сразу применять алгоритмы превосходящие стандартный ZIP как уже реализовали LZMA PPMd. Я пробовал с помощью архиватора 7-zip этими способами (предварительно создав tar, который почему-то раздул тексты с 3,5 мгб до 4,5 мгб), но с самыми лёггими параметрами, но ужать менее чем в 1,2мгб не удалось. Zip жмёт до 1.7 мгб а надо уместить в 1 мгб.

Если поставить памяти побольше то удаётся ужать в 700 кб и довольно быстро. Мне не ясно есть ли такие алгоритмы которые могли бы сносно работать на телефонах с ограничением по максимальному размеру приложения в 1мГб (затрудняюсь сказать сколько оперативной памяти при этом выделяется на таких телефонах ) - словарь или дерево при этом навено будет статическим и не очень большим. На более дорогих и современных телефонах потребности ужимать до 1 мГб совешенно нет - там можно приложения объемами в десятки мегабайт запускать - то есть надо адаптировать приложение к обычным не навороченным телефонам.

Я могу использовать единый словарь для всех блоков текста и как-то ужимать каждый текстовый блок по отдельности после чего применится стандартный ZIP на весь комплект. Вот как ужать текстовые файлы что бы это понравилось ZIP вот в чем вопрос. На счёт отдельного хранения текстов от приложения я тоже думал (допустим в дополнительном jar файле) но к сожалениюя не знаю как это делается в рамках j2me - был бы очень признателен если бы просветили. Проблема в том что нет нормального интернета - GPRS очень не дёшев - других вариантов пока нет. Шарить по инету просто не реально. Помогите выбрать сам подход решения проблемы и исходники которые имеет смысл адаптировать в рамках j2me мобильного приложения.

К сожалению я никогда раньше не занимался проблемой сжатия данных и являюсь новичком - в алгоритмах которые в исходниках мне очень не просто разбираться - желательно описание. Кроме того чуть ли ни во всех которые попадались из них требуется весьма солидное количество памяти что не всегда возможно в телефоне. Если можно ответьте на мыло. Суважением Роман

roman_er, PPMd - это изобретение Дмитрий Шкарина, я тут совершенно не при чем. Кроме того, у меня используется только алгоритм распаковки, исходные тексты PPMd можешь посмотреть на сайте автора: compression.ru/ds/ . Коды Хаффмана применять бессмысленно, DEFLATE сам по себе - это и так сочетание алгоритма LZ77 с кодами Хаффмана. PPMd - контекстная модель сжатия, хорошо работающая с текстами, работает в сочетании с интервальным кодированием, так что дожимать как-то еще не придется. PPMd, кстати, вполне поддерживается в ZIP, там же можно использовать не только DEFLATE.
P.S. Мое имя есть в анкете (жми на ник).

Что то на ник не получается нажать. Дело в том что я плоховато на с++ читаю исходники и адаптировоть под j2me сложновато - мне бы на яве посмотреть примерчик и дошлобы до меня как по аналогии переделывать. Кроме того разновидностей ppmd весьма не мало и мне не ясно что лучше подойдёт для моей задачи в рамках j2me - я думаю надо статический словарь-дерево прикрутить к ppmd. Zip хотя и поддерживает ppmd но навено такой вариант JAR телефон врядли откроет.

roman_er, PPMd в оригинале - это именно то, на что я выложил ссылку. Если хочешь посмотреть реализацию на Java, смотри вот здесь: java-unrar.sourceforge.net/ . Правда, алгоритма архивации, разумеется, там не будет. Кроме того, не очень понятно, как ты собрался совмещать PPMd и статический словарь, ведь весь смысл алгоритма именно в адаптирующейся динамической модели. В ZIP телефон да, вряд ли откроет, но можно положить архив в JAR.

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