Base64 je dostupné v každém běžném jazyce, takže se snadno stane univerzálním řešením pro soubory. Jedna funkce vloží binární obsah do JSON nebo textového sloupce. Pohodlí však skrývá větší objem, další kopie v paměti, horší streaming a nulové bezpečnostní záruky. Dobrá architektura proto začíná také otázkou, kdy Base64 nepoužít.
Velké soubory nepatří do běžného JSON
Zakódovaný obsah je přibližně o třetinu větší a parser často načte celý dokument. Server může současně držet request body, string Base64 a dekódovaný buffer. Stomegabajtový upload zatíží systém mnohem více než původní soubor.
Multipart, binární body nebo presigned upload do object storage dovolí streaming. JSON může přenést metadata a odkaz.
Base64 není komprese
Kódování neodstraňuje redundanci, ale zvětšuje přímý zápis. HTTP komprese může část režie získat zpět, ovšem za další výpočet a ne vždy účinně.
JPEG, PNG, ZIP a video jsou už komprimované. Úspora vychází ze změny rozlišení, formátu nebo bitrate, nikoli z Base64.
Databáze má používat odpovídající typ
Binární obsah v textovém sloupci zvětšuje tabulku, replikaci a backup. Textová collation pro zakódované bajty nedává smysl. BLOB nebo externí storage lépe odpovídá povaze dat.
Databáze často potřebuje jen metadata, vlastníka, digest a umístění. Velká pole pak nezpomalují běžné dotazy.
Tajemství se kódováním neochrání
API key nebo heslo v Base64 je stále plaintext s jednoduchým převodem. HTTP Basic Authentication spoléhá na TLS, ne na kódování hlavičky. Log takové hodnoty je únik credentials.
Secrets potřebují manager, access control, rotaci a audit. Base64 může být součást formátu, ale žádnou z těchto funkcí neposkytuje.
Hesla vyžadují specializovaný algoritmus
Base64 je plně vratné a nezpomaluje guessing. Password storage používá Argon2, scrypt nebo bcrypt s unikátním salt a vhodnými parametry.
Některé password hash formáty mají části podobné Base64. Bezpečnost pochází z drahé derivace, ne z textové reprezentace výsledku.
Hash odpovídá na jinou otázku
Pro ověření změny souboru se hodí kryptografický digest s pevnou délkou. Base64 zachovává všechny bajty a roste se vstupem, takže není efektivním integrity identifier.
Hash nedovolí soubor obnovit a očekávaná hodnota musí být důvěryhodná. Oba nástroje řeší jiné úlohy.
Data URL může zhoršit cache
Vložený obrázek se doručuje s HTML či CSS a nelze jej nezávisle aktualizovat. Změna malé ikony zneplatní velký soubor a opakované použití obsah duplikuje.
Pro drobný jednorázový asset je to přijatelné. Logo, font nebo produktová fotografie obvykle lépe funguje jako samostatný cachovaný zdroj.
Log není úložiště payloadu
Zakódování souboru kvůli logování vytvoří obrovské záznamy a může zkopírovat citlivé dokumenty do analytiky. Technicky vypadající string stále obsahuje plná data.
Log má uvést velikost, MIME type, object ID, hash a chybu. Diagnostický obsah patří do řízeného úložiště s krátkou retencí.
Dvojité kódování zůstává syntakticky validní
Když dvě vrstvy zakódují stejnou hodnotu, výsledek stále vypadá jako Base64. Jedno dekódování ale vrátí předchozí text, ne původní soubor. Parser proto nemusí chybu odhalit.
Smlouva má určit, zda pole nese bajty nebo hotovou reprezentaci a kdo transformaci vlastní.
Prohlížeč umí pracovat přímo s bajty
Blob, ArrayBuffer, FormData a Streams API umožňují upload a download bez textového mezikroku. Přímá odpověď lépe streamuje a snižuje paměť JavaScriptu.
Pohodlí stringu není důvod ignorovat schopnosti protokolu.
Limit se kontroluje před dekódováním
Pokud aplikace odmítne soubor až po vytvoření bufferu, náklad už vznikl. Z maximální binární velikosti lze odvodit povolenou délku Base64. Limity mají existovat i na HTTP serveru.
Přísná forma kódování dělá výpočet předvídatelný. Obří vstup se nemá tolerantně opravovat.
Binární protokol se hodí pro vysoký throughput
Protobuf, MessagePack a jiné formáty mají skutečné byte fields. U interních služeb s velkým objemem odstraní textovou režii. Zavedení nového protokolu však samo přidává komplexitu.
Malé dobře popsané pole Base64 může být pragmatické. Velká média v každém JSON requestu jsou signálem k přehodnocení.
Fronty mají vlastní limity a cenový model
Message broker často omezuje velikost jedné zprávy a účtuje přenos i replikaci. Base64 zvětší payload předtím, než broker vytvoří několik kopií pro vysokou dostupnost. Jeden velký event může blokovat partition a prodloužit retry.
Reference na objekt udržuje zprávu malou. Consumer si stáhne obsah pouze tehdy, když jej skutečně zpracovává, a může použít streaming.
Backup a replikace násobí režii storage
Textový sloupec s Base64 se nekopíruje jen jednou. Přechází do read replicas, snapshotů, log shippingu a analytických exportů. Třetinové zvětšení se v celém lifecycle násobí.
Oddělené object storage umožňuje vlastní kompresi, retention a lifecycle policy. Databáze zůstává zaměřená na metadata a transakční vztahy.
Reference bývá lepší než vložený obsah
Event nebo job může obsahovat immutable object ID, expected hash a authorization context. Příjemce soubor streamuje a ověří integritu. Zprávy zůstávají malé a lépe se opakují.
Storage musí zajistit retenci a atomické zveřejnění, aby reference neukazovala na neúplný objekt.
Base64 má konkrétní omezenou úlohu
Pro malé binární hodnoty v JSON, MIME, PEM a standardizovaných tokenech je spolehlivé. Selhává, když má předstírat kompresi, bezpečnost, integrity mechanismus nebo file storage.
Praktické pravidlo: pokud hranice přijímá bajty, pošlete bajty. Pokud přijímá pouze text, zhodnoťte velikost a použijte přesně určenou variantu. Ostatní požadavky řešte samostatně.