A Base64 e-mail mellékletekben, JSON válaszokban, tanúsítványokban, tokenekben és data URL-ekben is megjelenik. A hosszú betű- és számsor első pillantásra titkosított adatnak tűnhet, valójában azonban semmit sem rejt el. A módszer tetszőleges bájtsorozatot ír át egy korlátozott, nyomtatható karakterkészletre. Ez akkor hasznos, amikor a rendszer megbízhatóan tud szöveget továbbítani, de a nyers bináris adatot módosítaná, félreértené vagy elutasítaná.

A valódi probléma a szöveges átviteli határ

Egy kép, PDF vagy tömörített archívum 0 és 255 közötti bájtértékek sorozata. A modern protokollok gyakran közvetlenül kezelik ezeket, régebbi levelezőrendszerek, konfigurációs formátumok és egyes adatmezők viszont vezérlőkaraktereket, meghatározott karakterkódolást vagy sorvégeket feltételeznek.

A Base64 latin betűket, számjegyeket és néhány egyszerű jelet használ. Az eredeti tartalom nem változik meg, csak olyan alakot kap, amely nagyobb eséllyel sértetlenül átjut a szövegközpontú rétegeken.

A hatvannégy jel hat bitet képvisel

Hat bináris pozíciónak pontosan 64 lehetséges kombinációja van. A kódoló három bájtot, vagyis 24 bitet olvas be, majd négy hatbites csoportra osztja. Minden csoport egy karaktert választ az ábécéből.

Az ASCII Man szó például TWFu lesz. A bitek nem váltak titkossá. Ugyanazzal a nyilvános táblázattal kulcs nélkül visszaállíthatók.

A padding a hiányos utolsó blokkot jelöli

A bemenet hossza nem mindig osztható hárommal. Ha egy vagy két bájt marad, a szabványos forma egy vagy két egyenlőségjelet tesz a végére. Ez nem új adat, hanem annak jelzése, hogy az utolsó hatbites csoport egy része csak kitöltés.

Egyes protokollok elhagyják a paddinget, mert a hossz alapján visszaszámítható. A producernek és a fogyasztónak mégis egyetlen kanonikus alakban kell megállapodnia, különösen aláírt vagy cache-kulcsként használt szövegnél.

A kompatibilitás körülbelül egyharmados többlettel jár

Három bemeneti bájtból négy szöveges karakter lesz, ezért az eredmény nagyjából 33 százalékkal hosszabb. A JSON idézőjelei, MIME sortörései és más burkolatok további költséget adhatnak hozzá.

A memóriaigény még nagyobb lehet: az alkalmazás egyszerre tarthatja az HTTP bodyt, a Base64 stringet és a dekódolt buffert. Nagy feltöltéseknél ezért nem elég csak a hálózati méretet vizsgálni.

Az e-mail jól mutatja a formátum értelmét

A történelmi levelezési infrastruktúra nyomtatható karakterekre és korlátozott sorhosszra épült. A MIME leírja a melléklet típusát, majd Base64 blokkban viszi át a fájl bájtjait. Így egy kép vagy dokumentum sok köztes szerveren át is sértetlen maradhat.

A PEM hasonló mintát követ tanúsítványoknál és kulcsoknál. Az olvasható fejléc megnevezi az objektumot, a belső blokk pedig Base64. A biztonságot a kriptográfiai tartalom és a kulcs védelme adja, nem ez a külső szöveges réteg.

A JSON-nak nincs natív bájttípusa

A JSON stringet, számot, logikai értéket, tömböt, objektumot és nullt ismer, önálló byte array típust nem. Egy API ezért kisebb bináris értéket Base64 stringként adhat át. A szerződésnek meg kell neveznie a változatot, a padding szabályát, a maximális méretet és a dekódolt adat jelentését.

Nagy fájlhoz jobb a multipart feltöltés, a bináris HTTP body vagy a közvetlen object storage kapcsolat. A JSON ilyenkor metaadatot, objektumazonosítót és ellenőrző hash-t hordozhat.

A data URL csak kis erőforrásnál előnyös

Egy apró ikon beágyazható HTML-be vagy CSS-be, így elmarad egy külön kérés. Egyszeri, kis erőforrásnál ez egyszerű és gyors lehet.

Egy nagy kép viszont felfújja a dokumentumot, nem cache-elhető külön, és minden módosítása érvényteleníti a szülőfájlt. A döntést valódi mérésnek kell alátámasztania, nem annak az általános feltételezésnek, hogy kevesebb kérés mindig jobb.

A Base64 nem biztosít titkosságot

Jelszó, API token vagy személyes adat dekódolása bármely általános könyvtárral azonnal elvégezhető. A kódolás csak más írásmód, nem titkosítás. A technikainak látszó stringet ugyanúgy védeni kell, mint az eredeti tartalmat.

Integritást sem ad. A támadó megváltoztathatja a bájtokat, majd új, teljesen érvényes Base64 szöveget készíthet. Titkossághoz titkosítás, hitelességhez aláírás vagy MAC, jelszavakhoz speciális password hashing szükséges.

A sikeres dekódolás nem validálja a fájlt

A dekóder legfeljebb azt ellenőrzi, hogy a karakterek és a padding megfelelnek-e a kiválasztott változatnak. Az eredmény lehet sérült, rosszindulatú vagy túl nagy. Egy képnek nevezett bájtsorozat más formátumot is tartalmazhat.

A szolgáltatásnak még a nagy buffer létrehozása előtt méretkorlátot kell alkalmaznia, tartalom alapján kell típust ellenőriznie, és a dekódolt adatot továbbra is megbízhatatlan bemenetként kell kezelnie.

A karakterkódolás külön megállapodás

Ha a forrás szöveg, előbb karakterekből bájtokat kell készíteni, rendszerint UTF-8 segítségével. Csak ezután következik a Base64. Két rendszer helyesen kezelheti a Base64-et, mégis hibás ékezeteket kaphat, ha más charsetet használ.

Hibakereséskor érdemes először hexadecimálisan összevetni a bájtokat, majd külön vizsgálni azok szöveges értelmezését.

A streaming csökkenti a memóriát, nem a méretet

A kódoló blokkokban olvashat, és legfeljebb két megmaradt bájtot vihet tovább a következő blokkhoz. A padding csak a tényleges stream végén kerülhet hozzá. Ugyanez visszafelé is működik.

Ha a protokoll eleve képes bináris streamre, a közvetlen átvitel továbbra is egyszerűbb. A Base64 akkor jó választás, amikor valóban szöveges határt kell átlépni.

A szigorú dekóder feltárja a szerződéshibát

MIME esetén a sortörések elfogadása indokolt. Egy JSON mezőben viszont a tetszőleges whitespace vagy ismeretlen karakter elnézése elrejtheti a sérülést. A strict mód a rossz ábécét, hosszt és paddinget elutasítja.

A legjobb mentális modell a szállítási csomagolás: nagyobb az eredetinél, könnyen kinyitható, és önmagában nem biztonsági eszköz. Pontosan ez a szűk szerep magyarázza, miért maradt a Base64 évtizedeken át hasznos.