Как работи компресията вътре в EPUB, DOCX, XLSX и PPTX

Ако преименувате файл .docx, .xlsx, .pptx или .epub на .zip и го отворите с двойно кликване, се случва нещо изненадващо: не се появява грешка. Операционната ви система го отваря като папка, пълна с подпапки, XML конфигурационни файлове, стилови листове, шрифтове и вградени изображения.

Съвременните архитектури на документи изоставиха монолитните бинарни блокове преди десетилетия. На тяхно място, индустриалните стандарти — а именно Open Packaging Conventions (OPC) за Microsoft Office и Open Container Format (OCF) за EPUB — приеха изненадващо елегантна основа: скромният ZIP архив.

Разбирането как работи компресията в тези формати разкрива защо съвременните документи са толкова издръжливи, леки и разширяеми — и защо някои файлове се компресират с 90 %, докато други почти изобщо не намаляват размера си.

1. Архитектурата на контейнера: Прикрити ZIP пакети

Преди да разберем самия алгоритъм за компресия, е полезно да разберем защо съвременните формати за документи са структуриран като пакети, а не като самостоятелни сурови файлове.

Проблемът със старите бинарни формати

През 1990‑те и началото на 2000‑те години, Microsoft Office използваше собственически бинарни формати (.doc, .xls, .ppt). Тези файлове по същество бяха дампи на памет, структуриран около Compound File Binary Format (CFBF). Те бяха известни със своята крехкост:

• Едно единично обръщане на бит може да повреди цялата структура на файла.
• Вграждането на изображения караше размерите на файловете да нарастват непредсказуемо.
• Разборът изискваше обратно инженерство на сложни бинарни спецификации.
• Междуплатформната съвместимост беше кошмар.

Преходът към отворени, модулни контейнери

През средата на 2000-те години се случиха две паралелни еволюции:

1. Office Open XML (OOXML / ISO/IEC 29500): Microsoft представи XML-базираните формати, завършващи на x (DOCX, XLSX, PPTX). В сърцевината тези файлове следват Open Packaging Conventions (OPC).
2. EPUB (IDPF / W3C): Цифровото публикуване се отдалечи от собственически формати за четци към стандартни уеб технологии (HTML, CSS, SVG), събрани в EPUB Open Container Format (OCF).

И двете архитектури се базират на стандарта PKZIP 2.0 / ZIP specification. Разширението на файла просто определя очакваната схема, приложението за преглед по подразбиране и декларациите за mime-type.

Sample DOCX File (Unzipped):
├── [Content_Types].xml        <-- Registry of MIME types for parts
├── _rels/                     <-- Package-level relationships
│   └── .rels
├── docProps/                  <-- Core and extended metadata
│   ├── app.xml
│   └── core.xml
└── word/                      <-- Main content payload
    ├── document.xml           <-- Text, paragraphs, and tags
    ├── styles.xml             <-- Typography and presets
    ├── numbering.xml          <-- Lists and counters
    ├── media/                 <-- Embedded images (PNG, JPG)
    └── _rels/
        └── document.xml.rels  <-- Internal hyperlinks & resource pointers

2. Двигателят под капака: Алгоритъмът DEFLATE

Когато софтуерно приложение запише DOCX или EPUB файл, то не просто съхранява файловете в некопресиран архив. То компресира вътрешните ресурси, използвайки DEFLATE (специфициран в RFC 1951).

DEFLATE е двустепенна система за беззагубна компресия, комбинираща два фундаментални алгоритъма от компютърните науки:

Стъпка 1: LZ77 (Lempel-Ziv 1977) — Премахване на излишъци чрез плъзгащ прозорец

XML и HTML са изключително многословни. Помислете колко често се появяват тагове в стандартен document.xml или chapter1.xhtml файл:

• <w:p><w:r><w:rPr><w:sz w:val=\"24\"/></w:rPr><w:t> се повтаря хиляди пъти в Word.
• row r=\"1\" spans=\"1:15\"><c r=\"A1\" t=\"s\"><v> се повтаря в Excel в десетки хиляди клетки.
• <p class=\"calibre1\"><span class=\"body-text\"> се повтаря в главите на EPUB книгата.

LZ77 сканира потока от данни, използвайки плъзгащ се речников прозорец (обикновено 32 KB). Когато срещне низ от знаци, който е виждал наскоро, той заменя дублирания текст с малък обратен указател:

• (distance, length) — напр., "върни се 142 байта назад, копирай 28 байта".

Вместо да съхранява многословен маркиращ код отново и отново, LZ77 компресира хиляди повторящи се XML тагове в компактни координатни референции.

Стъпка 2: Хъфманово кодиране — Кодиране на честоти с променлива дължина

След като LZ77 замени излишните последователности с токени за дължина‑разстояние, Huffman кодиране анализира честотата на всеки символ в потока:

• Често срещаните символи (като често използваните знаци e, t, интервали или общи маркери за разстояние) се присвояват кратки двоични кодове (например 2 до 4 бита).
• Рядко използваните символи получават по-дълги двоични кодове (например 12 до 16 бита).

Резултатът е поток от битови кодове с променлива дължина, които компресират обикновения текстов XML с 75% до 88%.

3. Разбивка формат по формат: Как всеки обработва компресията

Въпреки че DOCX, XLSX, PPTX и EPUB използват една и съща ZIP обвивка, техните вътрешни данни се различават драстично.

A. DOCX: Балансирането между текста и стилизирането

• Какво има вътре: Чист XML (word/document.xml), таблици с шрифтове, стилове, каталози на връзки и папка word/media/.
• Как се представя компресията:
  • Сурият текст и XML маркировката постигат огромни коефициенти на компресия (често намалявайки от 5 MB суров XML до 500 KB).
  • Въпреки това, съвременните документи често вграждат екранни снимки, илюстрации и фотографии. Тъй като JPEG и PNG файловете са вече компресирани, DEFLATE не може да ги намали допълнително. Всъщност, прилагането на DEFLATE върху вече компресиран образ почти не дава спестявания (около 0 %) и може дори леко да увеличи размера поради заглавията на компресията.
  • Следователно, DOCX файловете без изображения са изключително малки, докато докладите, натоварени с изображения, почти отразяват точния размер на включените им файлове с изображения.

B. XLSX: Числови данни с голям обем & Споделени низове

Електронните таблици представляват уникално предизвикателство: лист може да съдържа стотици хиляди редове, което води до астрономически големи XML файлове, ако не се обработват интелигентно.

• Стратегията за споделени низове (xl/sharedStrings.xml):
  • Ако текстов етикет като “United States” или “In Progress” се появи 50 000 пъти в електронна таблица, съхраняването на <c t="inlineStr"><is><t>United States</t></is></c> в 50 000 клетки би надвишило некондензирания XML до гигабайти.
  • Excel премахва дублиращия се текст преди компресиране, като съхранява всеки уникален низ веднъж в таблица със споделени низове и го препраща чрез числов индекс (например <v>0</v>, <v>1</v>).
• Защо XLSX се компресира драматично:
  • Числовите записи на редове (sheet1.xml) следват повтаряща се, предвидима синтакса.
  • DEFLATE лесно открива повтарящи се модели в табличен XML. Обичайно е файл с необработени sheet1.xml от 120 MB да се свие до под 6 MB в XLSX архив.

C. PPTX: Слайдове, натоварени с медия

Презентациите са фундаментално различни от документи и електронни таблици:

• Дилемата с изображенията: PPTX файловете обикновено се състоят предимно от векторни форми, фонова графика, видеоклипове и слайдове с висока резолюция.
• Профил на компресия: Докато ppt/slides/slide1.xml до slideN.xml се компресират ефективно, медийният товар (ppt/media/) съставлява от 85% до 95% от общото тегло на архива.
• Защо повторното компресиране на PPTX не променя нищо: Ако се опитате да компресирате вече запазен PPTX файл с 7-Zip или WinRAR, ще забележите почти никакво намаляване на размера. Това се дължи на факта, че вътрешността вече е DEFLATE‑компресиран ZIP архив, съдържащ предварително компресирани JPEG‑и и MP4‑а, така че ентропията е почти максимална.

D. EPUB: Уеб технологии със задължителен некомпресиран заглавен файл

EPUB файлът е по същество отзивчив, пакетирано микросайт, съдържащ XHTML глави, CSS стилови листове, шрифтове TTF/WOFF и метаданни. Въпреки това, EPUB има едно строго правило за пакетиране, което го отличава от файловете на Microsoft Office:

EPUB Internal Structure:
├── mimetype                    <-- MUST be uncompressed (Stored) & at byte offset 38
├── META-INF/
│   └── container.xml           <-- Tells reader where the OPF manifest lives
└── OEBPS/ (or EPUB/)
    ├── content.opf             <-- Manifest of all book assets
    ├── toc.ncx / nav.xhtml     <-- Table of contents navigation
    ├── styles/style.css        <-- CSS formatting
    ├── images/                 <-- Book cover & illustrations
    └── text/                   <-- chapter1.xhtml, chapter2.xhtml

• Магическият файл mimetype:
  • E‑readers трябва да разпознаят EPUB веднага, без да извличат целия архив или да стартират процеси за декомпресиране.
  • Отвореният контейнерен формат (OCF) изисква файлът mimetype:
    1. Трябва да бъде първият файл в ZIP архива.
    2. Трябва точно да съдържа низа application/epub+zip.
    3. Не трябва да се компресира (метод за компресия ZIP 0 / “Stored”).
    4. Трябва да няма допълнителни данни в полетата, като се гарантира, че MIME низът винаги започва от байт 38 на физическия файл.
• Компресиране на текст: Всички останали файлове (.xhtml, .css, .opf) се компресират с използване на стандартния DEFLATE (метод ZIP 8), позволявайки пълномащабните романи да се свият до няколко стотин килобайта.

4. Сравняване на компресията между формати

5. Практични изводи: Как да оптимизирате вашите документи

Тъй като вече знаете как работи вътрешното пакетиране, можете да използвате механиките за компресия, за да решавате реални проблеми:

1. Поправка на повредени документи: Ако документът отказва да се отвори, промяната на разширението на .zip ви позволява да извлечете съдържанието и да възстановите суровия текст от document.xml или отделни глави от директорията text/ на EPUB.
2. Смаляване на огромни офис файлове: Тъй като компресията на XML вече е оптимизирана, огромните файлове почти винаги се дължат на неоптимизирани изображения в media/. Вместо да използвате компресори от трети страни за PDF или DOCX, отворете ZIP контейнера, извлечете изображенията, обработете ги с оптимизатор за изображения (като WebP, TinyPNG или MozJPEG) и ги заменете в архива.
3. Автоматизиране на генерирането на документи: Разработчиците не се нуждаят от тежки офис пакети, за да създават отчети. Можете да генерирате сурови XML шаблони, да ги пакетирайте с помощта на стандартни библиотеки за zlib/ZIP и програмено да създавате валидни DOCX или XLSX файлове за милисекунди.

6. Често задавани въпроси (FAQ)

Мога ли да конвертирам DOCX или EPUB в ZIP файл само като променя разширението на файла? Да; промяната на разширението на .zip позволява на всеки стандартен архивен инструмент (като 7-Zip, macOS Archive Utility или Windows Explorer) да отвори и директно прегледа вътрешните файлове.

Защо компресирането на DOCX или PPTX с 7-Zip не го прави значително по-малък? Защото файлът вече е вътрешно компресиран ZIP архив, съдържащ DEFLATE-кодирани XML и предварително компресирани изображения, оставяйки минимална излишност, която външен инструмент да премахне.

Защо EPUB спецификацията изисква файлът mimetype да бъде некомпресиран? Той позволява на софтуера за електронни четци да провери, че файлът е автентичен EPUB, като проверява MIME низа на фиксиран байтов отместване, без да е необходимо да се инициализира декомпресиращ двигател.

Увеличава ли променянето на форматирането на клетки в Excel размера на компресирания XLSX файл? Да; обширното персонализирано форматиране нарушава еднородното повторение на шаблони в клетките, създавайки по-дълги XML дефиниции, които намаляват ефективността на компресията на DEFLATE.

Възможно ли е да се извлекат оригинални изображения с висока резолюция от файл на Word или PowerPoint без загуба на качество? Да; преименувайте файла на .zip, отворете папката word/media или ppt/media и ще намерите оригиналните, некомпресирани изходни изображения точно както са били вмъкнати.

Вижте още

• Файлови формати за компресия в FileFormat.com
• ZIP бомби – Разрушаване на вашето съхранение
• Разбиране на 7z файловия формат - Пълен наръчник и ЧЗВ
• 7-те най-добри инструмента за отваряне или извличане на RAR файлове