LZ77 і LZ78, алгори́тм Ле́мпеля — Зі́ва (англ. Lempel–Ziv algorithm) — універсальний алгоритм стискування даних без втрат, створений у 1977—1978 роках Авраамом Лемпелем і Яковом Зівом. Алгоритм розроблений так, щоб його можна було швидко реалізувати, але він не обов'язково є оптимальним, оскільки не проводить жодного аналізу вхідних даних. 1984 року Террі Велчем опублікована покращена реалізація алгоритму LZ78 — алгоритм Лемпеля — Зіва — Велча (англ. Lempel–Ziv–Welch algorithm, LZW).

Більше тридцяти років алгоритм стиснення Хаффмана і його варіанти залишалися найпопулярнішими методами. Проте 1977 року ізраїльскі дослідники Авраам Лемпель і Яків Зів запропонували абсолютно інший підхід до цієї проблеми, висунувши ідею формування «словника» загальних послідовностей даних.

При цьому стиснення даних здійснюється за рахунок заміни записів відповідними кодами із словника. Існують два алгоритми стиснення даних — LZ77 і LZ78. Вони вже не вимагають включення словника даних в архів, оскільки якщо ви формуєте ваш словник визначеним способом, програма декодування може його відновлювати безпосередньо з ваших даних. На жаль, LZ77 і LZ78 витрачають багато часу на створення ефективного словника. Лемпель був запрошений фірмою Sperry для допомоги в розробці способу найефективнішої упаковки даних на комп'ютерних стрічках. У цій же фірмі Тері Велч розширив алгоритм LZ78, створивши новий варіант, широко відомий як LZW.

На роботу Велча звернула увагу група програмістів UNIX, які використали його алгоритм в їх додатку LZW, що отримав назву compress. Вони додали декілька удосконалень і опублікували загальнодоступну версію цієї програми в телеконференції Internet, завдяки чому багато користувачів змогли почати з нею працювати.

Популярність алгоритму LZW в значній мірі пов'язана з успіхом програми compress. Початковий текст останньої версії програми, що здійснює як стиснення, так і декомпресію, займає всього 1200 рядків. Ядро коду стиснення займає не більше сотні рядків, а коду декомпресії не набагато більше. Програмісти вважають, що це полегшує читання і розуміння алгоритму, а також дозволяє адаптувати його для найрізноманітніших цілей.

Існує багато практичних алгоритмів стиснення даних, але всі вони базуються на трьох теоретичних способах зменшення надлишковості даних. Перший спосіб полягає в зміні вмісту даних, другий — у зміні структури даних, а третій — в одночасній зміні як структури, так і вмісту даних.

Якщо при стисненні даних відбувається зміна їх вмісту, то метод стиснення є незворотнім, тобто при відновленні (розархівуванні) даних з архіву не відбувається повне відновлення інформації. Такі методи часто називаються методами стиснення з регульованими втратами інформації. Зрозуміло, що ці методи можна застосовувати тільки для таких типів даних, для яких втрата частини вмісту не приводить до суттєвого спотворення інформації. До таких типів даних відносяться відео- та аудіодані, а також графічні дані. Методи стиснення з регульованими втратами інформації забезпечують значно більший ступінь стиснення, але їх не можна застосовувати до текстових даних. Прикладами форматів стиснення з втратами інформації можуть бути:

• JPEG (Joint Photographic Experts Group) для графічних даних;
• MPG — для відеоданих;
• MP3 — для аудіоданих.

Якщо при стисненні даних відбувається тільки зміна структури даних, то метод стиснення є зворотнім. У цьому випадку з архіву можна відновити інформацію повністю. Зворотні методи стиснення можна застосовувати до будь-яких типів даних, але вони дають менший ступінь стиснення у порівнянні з незворотними методами стиснення. Приклади форматів стиснення без втрати інформації: GIF (Graphics Interchange Format) та TIFF (Tagged Image File Format) — для графічних даних; AVI — для відеоданих; ZIP, ARJ, RAR, CAB, LH — для довільних типів даних. Існує багато різних практичних методів стиснення без втрати інформації, які, як правило, мають різну ефективність для різних типів даних та різних обсягів даних.

Візьмемо набір символів

У ньому двічі зустрічається поєднання АБВ, тому його можна записати в так званому словнику, а в початковому тексті тільки залишити посилання на словник. Тоді початковий текст можна перетворити, наприклад, на

і окремо запам'ятати, що за символом 1 насправді ховається трійця АБВ. Ясно, що якщо в тексті поєднання АБВ зустрілося не 2 а 100 або ще краще 1000 разів, то стиснення було б вельми відчутним. Проте в реальних ситуаціях на таке везіння розраховувати не слід. Треба все вичавлювати навіть з небагатьох повторень в початковому тексті. Подивимося, чи багато ми вигадали в розглянутому прикладі.

Текст стискувався на 4 символи, але і, як мінімум, 4 символи опинилися у словнику. Крім того, побудова словника зажадає введення роздільників і ін.

Але і це ще не все. А якщо в тексті вже є символи 1 ? Як зрозуміти, що це саме 1, а не посилання на словник? Як же поступити найбільш грамотно? Ось тут відповідь далеко неоднозначна. Вона і не може бути однозначна, тому що стиснення — це не таблиця множення. Один текст краще стискається одним методом, інший — абсолютно іншим способом. Спершу ми розглянемо дуже спрощений варіант, щоб мати від чого відштовхуватися надалі.

Для визначеності вважатимемо, що кожен символ в тексті — це впорядкований набір з 8 бітів, тобто байт, або, що те ж саме ціле число від 0 до 255.

Послідовно читаємо початковий текст і одночасно формуємо вихідний файл. Якщо чергова буква зустрілася вперше, або вона виявилася останньою в тексті, то на вихід посилаємо біт 1 і 8 бітів від самої цієї букви. Так само треба зробити, якщо символ не новий, але в парі з наступним ще не зустрічався. Отже, в нашому прикладі перші три символи дадуть на виході 27 бітів. Тоді, при зворотній операції, як тільки той, що розшифровує, побачив черговий біт 1, він відразу знатиме, що наступні за ним 8 бітів треба вивести, так би мовити, відкритим текстом.

Якщо черговий символ в парі з наступним за ним вже зустрічався, то в принципі від цієї пари можна вивести два біта 01 і вказівку на існуючу аналогічну пару. Тоді декодувальник, побачивши 01, по цій вказівці подивиться на вже розшифровану частину тексту, візьме потрібну пару і припише таку саму в кінець розшифрованої частини.

В нашому прикладі достатньо двохбайтних посилань. Отже на вихід пошлемо:

Далі від букви Я по відомих правилах піде 9 бітів. Залишок тексту шифрується сімома бітами:

Перша група з нулів, що закінчується одиницею, означає, що раніше в тексті вже була аналогічна п'ятірка символів. Друга група представляє число одиницю, вказуюче, на якій відстані треба шукати прототип. Прототип добудовуватиметься по ходу будівництва копії з нього, але випереджаючими темпами, достатніми для того, щоб копіювання не простоювало.

Таким чином, початковий текст в стислому вигляді при декілька вільному зображенні з'явиться у вигляді:

Правильніше (але менш наочно) було б вписати замість А, Би і В їх восьмибітові уявлення.
. Дерево Лемпеля — Зіва виглядає так:

Щоб програма розшифровки годилася не тільки для розглянутого прикладу, ще до стислого тексту треба прикласти деякі параметри: довжину стислого або розгорненого тексту, а також довжину посилань. Само дерево прикладати не треба, якщо воно підкоряється простим широкоспоживаним правилам. Отже, дерево Лемпеля — Зіва може бути достатнє складним і розлогим.

Далі приводиться алгоритм розархівування зі всіма необхідними технічними подробицями і ретельно підібраними значеннями параметрів. Річ у тому, що навіть дуже невеликі варіації параметрів різко міняють ступінь стиснення і, як правило, в гіршу сторону. А боротьба ведеться за долі відсотка. Завдання ускладнюється тим, що немає об'єктивних критеріїв, по яких можна було відразу сказати, що та або інша зміна алгоритму пішла йому на користь. Як ми знаємо, для будь-якого архіватора знайдеться сила-силенна текстів, взагалі непіддатливих стисненню.

Якщо брати тільки такі тексти, то роботу можна не починати. Оцінювати архіватор треба по ходових текстах, але ходові — це не наукове поняття.

Зчитується чергова серія бітів до першого одиничного біта. Нехай N — кількість лічених бітів. Наприклад, якщо в черзі 001000…, то зчитуються 3 біти і відповідно N=3. А якщо перший біт дорівнює одиниці, то зчитується тільки він і N=1. Вводимо число M для формування кількості символів, які пізніше будуть узяті із вже розшифрованого тексту. Спочатку M=N. M і N — цілі двохбайтні числа.

1. Якщо N більше або дорівнює 17, то зчитуються чергові 8 бітів і розміщуються в молодших бітах числа M.
2. Якщо N > 17, то зчитуються чергові 8 бітів і розміщуються в старших байтах числа M. (Воно вважається беззнаковим)
3. Якщо M=1, то зчитуються чергові 8 бітів і надсилаються на вихід, тобто у відновлений текст, і тоді робіться перехід на п. 1.
4. Зчитуються чергові 2 біти, з яких формується ціле число Z від 0 до 3. Вводяться K і R.

Якщо M=2, Z=0, то K=5, R=0. 
Якщо M=2, Z=1, то K=7, R=-32.
Якщо M=2, Z=2, то K=9, R=-160.
Якщо M=2, Z=3, то K=11, R=-672.
Якщо M>2, Z=0, то K=6, R=0.
Якщо M>2, Z=1, то K=9, R=-64.
Якщо M>2, Z=2, то K=12, R=-576.
Якщо M>2, Z=3, то K=14, R=-4672.

1. Зчитуються чергові K бітів і розміщуються в молодших K бітах допоміжного цілого двохбайтного числа S. Решта бітів цього числа заповнюються одиницями. Отже S<0, оскільки у старшому біті, що відповідає за знак, знаходиться одиниця.
2. Визначається адреса в тексті, звідки буде узятий потрібний фрагмент. Адреса — це просто номер байта в послідовності. Для цього до адреси, на якій поки завершено формування розшифрованого тексту, треба додати R і S. З отриманої таким чином адреси беремо M символів і додаємо в кінець сформованого тексту. Переходимо до п.1 (якщо дані ще не вичерпані).

Наступна реалізація алгоритму призначена для COM-програм, що саморозархівуються. Тому, перший десяток команд в основному слугує для переміщення програми в кінець сегменту коду. А вже звідти розшифровані оператори переносяться на початок цього сегменту.

Приведені вище деталі алгоритму і значення параметрів не можуть бути виведені будь-якими раціональними строгими методами. У якійсь мірі, в них відбиті особливості сучасного програмування і людської мови. Але автори кожного архіватора знаходять свій оптимум, і що краще — може підказати тільки практика (критерій загальний, але дещо розпливчатий).

Могутні архіватори зазвичай роблять попередню оцінку початкового файлу і до кожного файлу (або до великих частин одного файлу) здійснюють індивідуальний підхід. Наприклад, перед кожним великим фрагментом стислого коду вказується його обсяг і тип стискування. Для цього досить 3 байти, які не псують загальної якості компресії.

Якщо файл короткий, то це означає, що взагалі дезархіватору не знадобиться заглядати далеко назад. Тоді не потрібний, скажімо, випадок K=14, і біти, що звільнилися, можна використовувати з більшою користю. Проте ефект порівняно невеликий. А оскільки він виявляється тільки на малих файлах, то на загальних (зазвичай гігантських) обсягах інформації він і зовсім втрачається.

Можливі багато інших варіантів удосконалень, не пов'язаних безпосередньо з характерними для Лемпеля — Зіва ідеями. Важливий випадок, коли чисельна інформація набита цифрами. Наприклад: 132, -44.8, 555. Зрозуміло, що цифри можуть бути так перетасовані, що навіть однакові пари будуть вкрай рідкісними. Згадані методи не дають стиснення. Проте, якщо у фрагменті тексту використовуються всього 16 різних знаків, кожен з них репрезентується чотирма бітами, що дає вже двократне стиснення. Додаткові резерви можуть бути розкриті якщо текст тільки українською мовою, де використовується не більше 66 знаків.

Можна виділяти у початковому файлі не стиковані ділянки. Тоді збиток від кожного з них можна понизити до трьох байтів. А в представленому варіанті кожен перенесений без змін символ тягне за собою однобайтову ознаку, тобто збиток 12,5 %.

Проте викладений вище алгоритм не враховує такі деталі, тому що вони відносно рідкісні, а ефект від них досить скромний.

• Лемпель-Зив в плане минимизации программы^{[недоступне посилання з червня 2019]}
• Архивация данных в MS DOS^{[недоступне посилання з серпня 2019]}

Ця стаття не містить посилань на джерела. Ви можете допомогти поліпшити цю статтю, додавши посилання на надійні (авторитетні) джерела. Матеріал без джерел може бути піддано сумніву та вилучено. (грудень 2015)

Ця стаття потребує додаткових посилань на джерела для поліпшення її перевірності. Будь ласка, допоможіть удосконалити цю статтю, додавши посилання на надійні (авторитетні) джерела. Зверніться на сторінку обговорення за поясненнями та допоможіть виправити недоліки. Матеріал без джерел може бути піддано сумніву та вилучено. (грудень 2015)

Це незавершена стаття про алгоритми. Ви можете допомогти проєкту, виправивши або дописавши її.