Poslední aktualizace: 10 září 2026

Jak funguje komprese uvnitř EPUB, DOCX, XLSX a PPTX
Pokud přejmenujete soubor .docx, .xlsx, .pptx nebo .epub na .zip a dvojkliknete na něj, stane se něco překvapivého: nevygeneruje chybu. Váš operační systém jej otevře jako složku plnou podadresářů, konfiguračních souborů XML, stylových listů, fontů a vložených obrázků.
Moderní architektury dokumentů opustily monolitické binární bloky před desítkami let. Na jejich místo přišly průmyslové standardy — konkrétně Open Packaging Conventions (OPC) pro Microsoft Office a Open Container Format (OCF) pro EPUB — které přijaly překvapivě elegantní základ: skromný ZIP archiv.
Pochopení toho, jak komprese funguje uvnitř těchto formátů, odhaluje, proč jsou moderní dokumenty tak odolné, lehké a rozšiřitelné — a proč některé soubory se komprimují o 90 %, zatímco jiné téměř vůbec nesestoupí.
1. Architektura kontejneru: maskované balíčky ZIP
Než pochopíme samotný kompresní algoritmus, pomůže pochopit, proč jsou moderní formáty dokumentů strukturovány jako balíčky místo samostatných surových souborů.
Problém se starými binárními formáty
V průběhu 90. let a počátku 2000. let Microsoft Office používal proprietární binární formáty (.doc, .xls, .ppt). Tyto soubory byly v podstatě výpisy paměti strukturované kolem formátu Compound File Binary Format (CFBF). Byly notoricky křehké:
- Jedno překlopení bitu mohlo poškodit celou strukturu souboru.
- Vkládání obrázků způsobovalo nepředvídatelný nárůst velikosti souboru.
- Parsování vyžadovalo reverzní inženýrství hustých binárních specifikací.
- Meziplatformní interoperabilita byla noční můrou.
Přechod na otevřené, modulární kontejnery
V polovině 2000. let proběhly dvě paralelní evoluce:
- Office Open XML (OOXML / ISO/IEC 29500): Microsoft představil formáty založené na XML končící na
x(DOCX, XLSX, PPTX). Vnitřně tyto soubory používají Open Packaging Conventions (OPC). - EPUB (IDPF / W3C): Digitální publikování se odklonilo od proprietárních formátů čteček směrem k standardním webovým technologiím (HTML, CSS, SVG) zabaleným v EPUB Open Container Format (OCF).
Obě architektury se opírají o standardní PKZIP 2.0 / ZIP specifikaci. Přípona souboru jednoduše určuje očekávané schéma, výchozí aplikaci pro prohlížení a deklarace 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. Motor pod kapotou: algoritmus DEFLATE
Když softwarová aplikace uloží soubor DOCX nebo EPUB, neukládá soubory jen do nekomprimovaného archivu. Komprimuje vnitřní součásti pomocí DEFLATE (specifikováno v RFC 1951).
DEFLATE je dvoustupňový bezztrátový kompresní systém kombinující dva základní algoritmy informatiky:
Krok 1: LZ77 (Lempel-Ziv 1977) — Odstranění redundance pomocí posuvného okna
XML a HTML jsou extrémně verbózní. Zvažte, jak často se značky objevují ve standardním souboru document.xml nebo chapter1.xhtml:
<w:p><w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t>se v aplikaci Word opakuje tisíckrát.row r="1" spans="1:15"><c r="A1" t="s"><v>se opakuje v Excelu napříč desítkami tisíc buněk.<p class="calibre1"><span class="body-text">se opakuje napříč kapitolami knihy EPUB.
LZ77 prohledává datový proud pomocí posuvného slovníkového okna (obvykle 32 KB). Když narazí na řetězec znaků, který nedávno viděl, nahradí duplicitní text malým zpětným ukazatelem:
(distance, length)— např. „vrátit se o 142 bajtů, zkopírovat 28 bajtů“.
Místo opakovaného ukládání rozsáhlého značkování LZ77 sloučí tisíce opakujících se XML značek do kompaktních souřadnicových odkazů.
Krok 2: Huffmanovo kódování — Kódování frekvence proměnné délky
Po tom, co LZ77 nahradí nadbytečné sekvence tokeny délka‑vzdálenost, Huffmanovo kódování analyzuje četnost každého symbolu v proudu:
- Často se vyskytující symboly (jako běžné znaky
e,t, mezery nebo běžné značky vzdálenosti) jsou přiřazeny krátké binární kódy (např. 2 až 4 bity). - Zřídka používané symboly dostávají delší binární kódy (např. 12 až 16 bitů).
Výsledek je proud proměnlivé délky bitových kódů, které stlačují prostý text XML o 75 % až 88 %.
3. Rozbor formát po formátu: Jak každý zvládá kompresi
Zatímco DOCX, XLSX, PPTX a EPUB všechny používají stejný ZIP obal, jejich vnitřní datové charakteristiky se výrazně liší.
A. DOCX: Vyvažování textu a stylování
- Co je uvnitř: Plain XML (
word/document.xml), tabulky fontů, styly, katalogy vztahů a složkaword/media/. - Jak funguje komprese:
- Surový text a XML značkování dosahují obrovských kompresních poměrů (často klesají z 5 MB surového XML na 500 KB).
- Moderní dokumenty však často obsahují snímky obrazovky, ilustrace a fotografie. Protože soubory JPEG a PNG jsou již komprimované, DEFLATE je nemůže dále zmenšit. Ve skutečnosti aplikace DEFLATE na již komprimovaný obrázek přináší prakticky 0 % úsporu (a může dokonce mírně zvýšit velikost kvůli kompresním hlavičkám).
- V důsledku toho jsou soubory DOCX bez obrázků výjimečně malé, zatímco zprávy s mnoha obrázky mají téměř stejnou velikost jako jejich obsažené soubory obrázků.
B. XLSX: Vysokokapacitní číselná data a sdílené řetězce
Tabulky představují jedinečnou výzvu: list může obsahovat stovky tisíc řádků, což vede k astronomickým velikostem XML souborů, pokud se s nimi nepracuje chytře.
- Strategie sdílených řetězců (
xl/sharedStrings.xml):- Pokud se textová značka jako “United States” nebo “In Progress” objeví 50 000krát v tabulce, uložení
<c t="inlineStr"><is><t>United States</t></is></c>do 50 000 buněk by nafoukl nekomprimované XML na gigabajty. - Excel před kompresí odstraňuje duplicitní text tím, že každou jedinečnou řetězec uloží jednou do tabulky sdílených řetězců a odkazuje na něj pomocí číselného indexu (např.
<v>0</v>,<v>1</v>).
- Pokud se textová značka jako “United States” nebo “In Progress” objeví 50 000krát v tabulce, uložení
- Proč se XLSX dramaticky komprimuje:
- Číselné řádkové záznamy (
sheet1.xml) mají opakující se, předvídatelnou syntaxi. - DEFLATE snadno detekuje opakující se vzory v tabulkovém XML. Je běžné, že surový soubor
sheet1.xmlo velikosti 120 MB se zmenší na méně než 6 MB uvnitř archivu XLSX.
- Číselné řádkové záznamy (
C. PPTX: Mediálně náročné prezentace
Prezentace jsou zásadně odlišné od dokumentů a tabulek:
- Obrázková dilema: Soubory PPTX jsou typicky ovládány vektorovými tvary, pozadími, video klipy a snímky ve vysokém rozlišení.
- Profil komprese: While
ppt/slides/slide1.xmlthroughslideN.xmlcompress efficiently, the media payload (ppt/media/) accounts for 85% to 95% of the total archive weight. - Proč opětovné zipování PPTX nic nezmění: If you try to compress an already-saved PPTX file with 7-Zip or WinRAR, you will notice almost no size reduction. Because the interior is already a DEFLATE-compressed ZIP archive containing pre-compressed JPEGs and MP4s, the entropy is already near maximum.
D. EPUB: Webové technologie s povinnou nekomprimovanou hlavičkou
Soubor EPUB je v podstatě responzivní, zabalená mikrowebová stránka obsahující kapitoly v XHTML, styly v CSS, písma TTF/WOFF a metadata. Nicméně EPUB má jedno přísné pravidlo balení, které jej odlišuje od souborů 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
- Magický soubor
mimetype:- E‑čtečky musí EPUB okamžitě identifikovat, aniž by musely rozbalovat celý archiv nebo spouštět dekompresní pipeline.
- Formát Open Container (OCF) vyžaduje, aby soubor
mimetype:- Musel být první soubor v ZIP archivu.
- Musí obsahovat přesně řetězec
application/epub+zip. - Nesmí být komprimováno (ZIP compression method
0/ “Uloženo”). - Nesmí obsahovat žádná další data pole, aby řetězec MIME vždy začínal na bajtu 38 fyzického souboru.
- Komprese textu: Všechny zbývající soubory (
.xhtml,.css,.opf) jsou komprimovány pomocí standardního DEFLATE (ZIP method8), což umožňuje, aby se celé romány zmenšily na několik stovek kilobajtů.
4. Porovnání komprese napříč formáty
| Formát | Jádrový náklad | Primární zdroj redundance | Typický poměr komprese (text/markup) | Zpracování médií |
|---|---|---|---|---|
| DOCX | WordprocessingML (document.xml) | Opakující se XML značky odstavců/úseků | 75% – 85% | Uloženo v word/media/ (většinou předkomprimováno) |
| XLSX | SpreadsheetML (sheet*.xml) | Opakující se značky buněk/řádků; sdílené řetězce | 80% – 92% | Řídké; obrázky/grafy v xl/media/ |
| PPTX | PresentationML (slide*.xml) | Metadata rozložení snímků, souřadnice tvarů | 70% – 80% | Těžký ppt/media/ payload omezuje celkové úspory |
| EPUB | XHTML, CSS, OPF, NCX | HTML značky, opakující se CSS selektory | 65% – 80% | mimetype nekomprimovaný; média v podsložkách |
5. Praktické poznatky: Jak optimalizovat své dokumenty
Protože nyní víte, jak funguje interní balení, můžete využít kompresní mechanismy k řešení reálných problémů:
- Oprava poškozených dokumentů:
Pokud se dokument odmítá otevřít, změna přípony na
.zipvám umožní rozbalit obsah a obnovit surový text zdocument.xmlnebo jednotlivé kapitoly z adresářetext/EPUBu. - Zmenšení obrovských Office souborů:
Protože komprese XML je již optimalizovaná, obrovské soubory jsou téměř vždy způsobeny neoptimalizovanými obrázky ve složce
media/. Místo používání třetích stran PDF nebo DOCX kompresorů otevřete kontejner ZIP, extrahujte obrázky, projděte je optimalizátorem obrázků (např. WebP, TinyPNG nebo MozJPEG) a nahraďte je v archivu. - Automatizace generování dokumentů: Vývojáři nepotřebují těžké kancelářské balíky k vytváření zpráv. Můžete generovat surové XML šablony, zabalit je pomocí standardních knihoven zlib/ZIP a programově během milisekund vytvořit platné soubory DOCX nebo XLSX.
6. Často kladené otázky (FAQ)
Mohu převést DOCX nebo EPUB na soubor ZIP pouhým přejmenováním přípony souboru? Ano; přejmenování přípony na .zip umožní jakémukoli standardnímu archivnímu nástroji (např. 7-Zip, macOS Archive Utility nebo Windows Explorer) otevřít a přímo prozkoumat vnitřní soubory.
Proč komprese DOCX nebo PPTX pomocí 7-Zip nevede k výrazně menší velikosti? Protože soubor je již interně komprimovaný ZIP archiv, který obsahuje XML kódované DEFLATE a předkomprimované obrázky, takže zůstává jen minimální nadbytek, který by externí nástroj mohl odstranit.
Proč specifikace EPUB vyžaduje, aby soubor mimetype byl nekomprimovaný? Umožňuje to softwaru pro čtečky e-knih ověřit, že soubor je autentický EPUB, kontrolou řetězce MIME na pevně daném offsetu bajtu, aniž by bylo nutné spouštět dekompresní engine.
Zvyšuje změna formátování buněk v Excelu velikost komprimovaného souboru XLSX? Ano; rozsáhlé vlastní formátování narušuje jednotné opakování vzorů napříč buňkami, což vytváří delší definice XML a snižuje efektivitu komprese DEFLATE.
Je možné extrahovat vysoce rozlišené originální obrázky ze souboru Word nebo PowerPoint bez ztráty kvality? Ano; přejmenujte soubor na .zip, otevřete složku word/media nebo ppt/media a najdete originální, nekomprimované zdrojové obrázky přesně tak, jak byly vloženy.