Článek
Soubor o velikosti 20 MB se po vložení do e-mailu nemusí přes síť přenášet jako 20 MB. V jednoduchém testu jsem vzal binární soubory o přesně 1 000 000, 10 000 000 a 20 000 000 bajtech a zakódoval je do Base64. Dvacetimegabajtový soubor se změnil na 26 666 668 bajtů. Po zalomení řádků podle MIME na maximálně 76 znaků měl samotný kódovaný blok 27 368 424 bajtů.
Nejde o kompresi, chybu ani „daň“ konkrétního poskytovatele. Base64 je způsob, jak převést libovolná binární data na textovou sadu znaků, která se bezpečně přenáší v prostředích založených na textu. Za tuto kompatibilitu se platí velikostí.
Proč z každých tří bajtů vzniknou čtyři znaky
Základní matematika Base64 je přímočará. Tři vstupní bajty mají dohromady 24 bitů. Base64 je rozdělí na čtyři skupiny po šesti bitech a každou skupinu zapíše jedním znakem z 64znakové abecedy. Tři bajty vstupu se tedy typicky změní na čtyři znaky výstupu.
To je poměr 4 ku 3, tedy nárůst o zhruba třetinu. U souborů, jejichž délka není dělitelná třemi, se na konci může objevit doplnění znakem =, ale u větších souborů je vliv těchto jednotek zanedbatelný.
Můj test: 1 MB se změnil na 1,37 MB MIME těla
1 000 000 B raw → 1 333 336 B Base64 → 1 368 424 B po MIME zalomení CRLF.
10 000 000 B raw → 13 333 336 B Base64 → 13 684 214 B po MIME zalomení CRLF.
20 000 000 B raw → 26 666 668 B Base64 → 27 368 424 B po MIME zalomení CRLF.
Čisté Base64 v testu přidalo prakticky 33,33 %. Když jsem výstup rozřezal na řádky po nejvýše 76 znacích a mezi ně vložil standardní CRLF, dostal se samotný přenosový blok přibližně na 36,84 % nad původní binární velikost.
Výsledek není závislý na tom, zda soubor obsahuje fotografii, ZIP nebo náhodná data. Base64 u stejného počtu vstupních bajtů vytváří předvídatelný počet znaků. Obsah by velikost změnil až tehdy, kdyby se před kódováním například komprimoval.
MIME přidává ještě něco navíc
RFC 2045 požaduje u MIME Base64 řádky nejvýše 76 znaků. Zalomení samo o sobě tedy přidá další bajty. Skutečný e-mail navíc obsahuje hlavičky MIME, hranice multipart zprávy, informace o názvu a typu souboru a samozřejmě vlastní text zprávy.
Proto moje číslo 27 368 424 bajtů není univerzální velikost celého e-mailu s dvacetimegabajtovou přílohou. Je to změřená velikost Base64 těla s CRLF v popsané metodě. Kompletní zpráva bude ještě o něco větší a konkrétní poštovní systém může velikost počítat jiným způsobem.
Limit přílohy a velikost souboru nejsou totéž
Praktický důsledek je jednoduchý: když služba uvádí limit pro velikost zprávy nebo přenášeného obsahu, nelze automaticky předpokládat, že stejně velký binární soubor projde jako příloha. Někde se limit vztahuje na soubor před kódováním, jinde na výslednou zprávu a pravidla se mezi poskytovateli liší.
Proto nedává smysl z tohoto článku odvozovat univerzální hranici typu „20 MB vždy projde“ nebo „20 MB nikdy neprojde“. Jistá je jen fyzika kódování: samotné Base64 udělá z binárních dat přibližně o třetinu větší text.
Cena za starou kompatibilitu, která pořád funguje
Base64 vzniklo proto, aby šlo binární data reprezentovat pomocí znaků, které transportní systémy bezpečně zvládnou. Dnes může působit zvláštně, že kvůli tomu posíláme více dat, ale tento mechanismus je jednoduchý, předvídatelný a velmi široce podporovaný.
A tak může mít fotografie na disku 20 MB, zatímco její textová podoba uvnitř e-mailu má přes 26,6 MB a po MIME zalomení v mém testu přes 27,3 MB. Příloha se nezvětšila obrazově ani obsahově. Jen byla přeložena do jazyka, který e-mail umí bezpečně přenést.
Zdroje
RFC Editor – RFC 4648, Base64 – Base64 převádí 24bitové skupiny vstupu na čtyři šestibitové znaky
RFC Editor – RFC 2045, MIME – MIME Base64 používá řádky nejvýše 76 znaků
Vlastní dataset – BASE64_2026-10-03_measurements.csv + BASE64_measure.py (součást ZIP balíčku)
