так как страницы стали много весить а инет по трафику,
а не халява. то решил сделать уплотнитель контента чисто
ради экономии денег. хотя это копейки..

главным препятствием стало отсутствие подходящих Баз Данных(БД)
аксесовская не хочет различать заглавные и строчные буквы-
а это важно, к другим дрова нужны, mySQL вобще надо устанавливать
отдельно, хотя SQLite есть в комплекте PHP и там всё тоже самое,
вплоть до команд. Все эти базы не поддерживают произвольный
размер ключа - везде фиксирован. а по blob не сортирнешь..
с рус буквами вобще беда, нужно спец. настраивать и нигде не
написано как - искать надо. Вобщем пришлось писать свою БД,
придумывать формат, получилось неплохо. работает быстрее БД и
коллекций на VB/Java, остальные не проверял. Хранится на диске
в сжатом виде с КС. а загружается в память полностью.
Поэтому огр. на размер 16 мб , одна таблица. доступ монопольный.
но можно сделать сетевую версию, много таблиц и пр. прелести.
БД состоит из таблицы пар Ключ-Значение произвольной длины, макс.
длина ключа 250, значения-2^64. отсортировано по частоте/рейтингу.
поэтому при запросе списка с этих 2х букв - сначала идут наиболее
частые слова, потом редкие. для обработки текстов это важно.

Формат такой: индексный файл 64к*4байта - первые 2 буквы ключа,
(любой символ 0-255). - значение-точка входа в связный список 
"хвостов" для этих первых 2х букв.
Основная база- массив-int32 переменной длины.
это набор записей в виде цепочек-связных списков
индекс указывает на точку входа-начало цепочки Записей,
Запись - ячейка БД, состоит из 4 полей:
4*int32 и int32*n переменной длины.
---запись---
1.адрес след. записи этой цепочки или 0-конец цепочки.
2.рейтинг/частота - для ускорения доступа.
3.значение1-адрес в табл. знач. или в той же на значение ключа.
4.значение2-номер слова/пи-код или доп.адрес
5.длина хвоста и хвост по 3+4+4.. байта
-------------
удаление - это коррекция адреса след записи. фактически
ничего не удал-ся, только при упаковке-полной перезаписи в новую 
БД физически удаляются. (но остаются в старой копии БД)

добавление- вставка - физически добавление в конец+модификация
указателей(адресов) на след. запись в 3х записях.
если уже есть то просто увеличивается рейтинг(частота) слова.
таким образом самые часто используемые слова будут первые, а
редко-последними.
Индекс первая_буква+вторая_буква*256 это типа мини-хэш,
для ускорения поиска на первом этапе, а перебор цепочки где
записи в порядке рейтинга - это второй этап ускорения-в среднем
время поиска будет не t*кол-во/2 а значительно меньше.(зависит
от крутизны графика, но в общем случае распределение по эксп.)

Кароче, получилось супер, и вместо тормозных коллекций,
(а в VB ещё невозможно получить список ключей), дальше очень
помогло и при сжатии текста, и при сжатии 3байтного цвета,
так как 16мб массивы это слишком, для подсчёта частоты.

Название будет .dic -(словарь) хотя в лингво и пр. его уже юзают.
но префиксу - мой с 4 начинается, т.к сохр. в PMD_B-4.

Так что забудьте про остальные форматы-они уже отцтой :)

--------------------------
про тексты. и сжатие текстов.
сначала была простая идея - заменять слова их 2байтными номерами 
в словаре- пи-кодами, 64к ходовых слов это 97% текста, остальные
можно кодировать как RAW - 0+как_есть+0
после этого 400кб текст сжимается в 74кб вместо 124кб(rar/pmd)
перед сжатием нужно добиться наибольшей одинаковости,
для этого перед знаками(.,!?ch1310) надо вставить пробел, его
можно потом всегда убрать, т.к по правилам: буква+знак+пробел
знаки заменить на теги, много пробелов на один, таб(9) на __
где нужно четкое выравнивание(в дос моноширный шрифт- там это
важно, а в win всё равно будет криво, там он бесполезен)
ch1310 ch10 ch13 - это конец строки в разных ОС, меняем на 

в результате все слова будут разделены пробелами и
пробел+слово+пробел можно считать как одно слово и присвоить ему
пи-код или в пмд это будет контекстом и сожмется лучше (до 110к)

слова с загл буквами превратить в маленькие. если это имя и есть 
в словаре и нет синонима с мал.буквы, то назад восст. можно.
Если это после (пробел+точка+пробел) то тоже можно.
в других случаях вставляем тег <бол> перед словом.
с дефисом тоже проблема. он часть слова, но если его нет
в словаре а слова что он делит есть, то меняем на тег <деф>


Кодировки все устарели, юникод и utf тоже фигня вобщем.
лучше вначале текста - флажок а потом анси - байт=символ.
перевожу всё в win-rus-1251 без вопросов. а потом можно обратно
по желанию даже в блокноте.


Про правила рус. языка. Они вобщем-то устарели, нужна реформа,
двойные написания типа програММист упразднить, тем более что
куча слов из англ. и там удвоение по другому-путаница.
ё на е ,ъ на ь, щ на ш там где на смысл не влияет и можно
восстановить обратно по словарю автозамены. да и так понять можно.
Слова исключения в отдельный словарь.
редкие слова - упразднить - они не нужны и давно устарели.
сленг узаконить как нормальные слова - синонимы. их много уже.

при сжатии текста нужно учитывать вероятность/частоту/рейтинг
пробел+?(буква)
(пробел+буква1)+?(буква/зпт)
(пробел+буква1+буква2)+?(буква/зпт/пробел=конец_слова)
это нес-ко словарей. буквы заменяются на номер в словаре.
в рез-те для самого частого слова будет: 122332211
т.е мин-макс диапазон будет намного уже и сжать можно ещё.
рейтинг буквы в зависимости от предыдущих -это 1й уровень инф 
в PMD фактически такой же принцип, но он динамический.

можно даже цифрами от 0 до 9 почти все слова закодировать.
дальше возможно макро кодирование на уровне всего предложения.
(точка+пробел)+?(номер_слова)
(точка+пробел+номер_слова1)+?(номер_слова/точка)
это другие вероятности. слова идущие после других слов
это 2й уровень информации текста.

после замены пи-коды будут тоже в более узком диапазоне
Таблиц будет много. архиватор большой. но жать будет ого-го.
(пока не доделано много)

----------------------------
Изображения-картинки.
новый формат изображения .img - лучше gif/png/ico в 2-50 раз.
прозрачный цвет и анимация тоже есть(но пока не сделано)

изучая алгоритм lzw на предмет: а выход если сжать моими БРЧ
вместо кодов Хаффмана? внезапно обнаружил что PMD жмёт лучше
почти в 2 раза. так что все алгоритмы LZ* давно в прошлом,
сейчас есть намного эффективней-один из них PMD.
вместо кодов Хаффмана- коды Xинга(мои)-они лучше до 10%.
потому что гибрид БРЧ и фикс. - их много видов. Запатентовано :)

GIF если разжать в BMP-256 и сжать PMD то лучше будет в 2+ раз.
я добавил 2D повторы(по площади) (с линейными сам PMD лучше
разбирается), а вот в два направления иногда дают выгоду до 50% 
в ч/б схемах.
формат - маркер_повтора+цвет+ширина+высота.
были идеи 4 маркера и мп2+цв+ширина (а высота до конца)
но выигрыш мизер. ограничение блока 256-большие разбиваются по 
256, декодер понимает завороты за края. кодер пока нет. и не 
очень. оптимальные блоки ищет если сложная картинка.
дальше сжатие палитры.
256*3=768 байт макс. но в среднем 16*3=48, в общем то не много,
но в инете полно мелких gif и это много в %% к общему размеру.
так что принято решение - если цвета много то бит/палитра больше,
а если мало то можно сделать приближение цвета грубее - на общую
картину мало повлияет. среднее отклонение меньше 1% - практически
не отличить, если тока приглядеться.. но на маленьких заляпаных
экранах планшетов/телефонов это не заметно, а вот скорость 
загрузки и экономия трафика лучше в 2-5 раз!!
все картинки страницы лучше в jar контейнер поместить-
потом ява аплетом разжать в BMP/ICO, потом может декодеры img в
браузеры встроят..
jpg тоже можно сжать- палитру сжать по частоте цвета и выход
вместо кодов Хаффмана - кодами Хинга. но я алгоритм не видел,
все интеловскую dll юзают и есть описание что там косинус 
преобразовние Фурье по квадрату, поэтому цвета перемешиваются
но в общей картине соответствие прежнее и на глаз не различить.
еще можно учесть что распределение цвета по экспоненте и
частые цвета можно менять на номера в словаре.

так же можно изменить формат RGB 8-8-8
номер цвета формировать по младшим битам затем по старшим
а за точку отсчета взять 808080- и зигзагообразное расхождение
к границам 0 и FFFFFF

число= b7g7r7 b6g6r6 b5g5r5 b4g4r4 b3g3r3 b2g2r2 b1g1r1 b0g0r0
bN-номер бита цвета. от 0 до 16м от темных к светлым
число=зигзаг(число-7FFFFF)*2-знак
0=среднее, 1=ср+2, -1=ср+1 итд.
таким образом средние цвета будут иметь наименьший номер.
но это ещё надо исследовать, вроде зеленого много, так что
общий словарь как для слов тоже можно и для цветов сделать.

еще была идея заменить буквы - цветами и сжать в jpg+табл поправок
но там от исх текста ничего не осталось - надо исследовать дальше,
может что-то в этом есть, хотя вряд ли. линейный контекст 
переводить в 2D - там по вертикали вобще никакого порядка-очень 
случайно. но может при какой то хитрой замене - например разброс 
цветов большой 32 симв+знаки меньше . если табл поправок будет 
маленькая то может быть..

вобщем сжатие трафика будет заметное.
потом может в браузеры встроят это дело.

архиватор минус 
-.exe
это вместо платного RAR, плохого ZIP и малоизвестного 7z/PMD
ключей знать не надо.
если надо макс сжать то -0
картинки жмет до 1% разницы, но если ключ -0 то %3
разжимает пока тока в BMP-24
если надо выжать всё то -best 
медленно переберёт 23 метода, проанализирует структуру,
равномерность, экпоненциальность, пропуски,
короткие таблицы значений сжимает спец. алгоритмом-аналогов нет.
оценка БРЧ (кодера/декодера пока нет, но будет)
может сжимать * все файлы. но во много архивов.
их потом можно поместить в контейнер zip без сжатия.
макс размер 512 терабайт 2^49 в формате 778 1-7байт

у всех прог есть нормальное описание, сообщения не в консоль а в окно,
и можно назад отмотать и скопировать, и с рус. проблем нет.
2016 г