Base64 a Base64URL používají stejnou práci s bity. Bajty se rozdělují do šestibitových skupin a každá se mapuje na jeden ze 64 znaků. Rozdíl je soustředěn do několika symbolů, které však v URL mají vlastní syntaktický význam. URL-safe varianta proto snižuje riziko, že jiný parser hodnotu změní dříve, než ji aplikace dekóduje.

Standardní abeceda koliduje s URL

Klasické Base64 používá plus a lomítko, znak rovná se bývá padding. Lomítko odděluje segmenty cesty, plus může formulářový parser změnit na mezeru a rovná se odděluje jméno parametru od hodnoty.

Percent-encoding by znaky ochránil, ale řetězec prodlouží a přidá další transformační vrstvu. Base64URL používá místo plusu mínus a místo lomítka podtržítko. Padding se často vynechává.

Výsledné bajty zůstávají stejné

Písmena a číslice mají v obou abecedách stejné pozice. Mnoho testovacích hodnot proto vypadá totožně. Rozdíl se projeví až tehdy, když některá šestibitová skupina odpovídá posledním dvěma symbolům.

Testy mají záměrně vytvořit znaky +, /, - a _ i vstupy s různým paddingem. Jinak chybná implementace projde jednoduchými příklady.

Padding je součástí textové podoby

Standardní Base64 obvykle doplňuje délku na násobek čtyř. Specifikace Base64URL často požadují nepadded tvar. Dekodér může chybějící rovná se dopočítat podle délky.

Protokol by přesto měl určit jediný kanonický výstup. Cache, databázový klíč a podpis rozlišují dva texty, i když po dekódování vzniknou stejné bajty.

JWT je nejznámější příklad

JSON Web Token má tři segmenty oddělené tečkami. Header, payload a podpis používají Base64URL bez běžného paddingu. Hodnota se tak snáze přenáší v HTTP hlavičkách, cookies a odkazech.

Kódování claims neschová. Každý držitel tokenu přečte header i payload. Podpis detekuje změnu, důvěrnost vyžaduje jiný mechanismus.

Podpis závisí na přesném řetězci

JWT podpis chrání zakódovaný header, tečku a zakódovaný payload. Nová serializace JSON může změnit pořadí vlastností nebo whitespace. Přidání paddingu také mění text.

Verifier používá původní segmenty a pravidla formátu. Nesmí dokument dekódovat, přeformátovat a podepsanou část vytvořit znovu.

URL-safe neznamená bezpečný

Token v query se zapisuje do historie, proxy logů, analytiky a někdy Referer hlavičky. Cookie má limity velikosti a vlastní bezpečnostní atributy. Abeceda řeší syntaxi, ne životní cyklus tajemství.

Citlivá credentials patří do vhodného transportu a měla by mít krátkou platnost. Base64URL samo nepřidává oprávnění ani šifrování.

Názvy souborů mají další omezení

Absence lomítka pomáhá v object storage a souborových jménech. Stále však existuje maximální délka, case sensitivity a Unicode normalizace platformy. URL-safe abeceda není úplná záruka přenositelnosti.

Pro content hash může být hex delší, ale provozně čitelnější. Volba reprezentace má zohlednit nástroje a support.

API musí variantu pojmenovat

Popis „Base64 encoded“ je nedostatečný, pokud se očekává URL-safe bez paddingu. Schema, dokumentace a SDK mají používat přesný název a příklady s rozdílovými znaky.

Fakt, že API běží přes HTTPS, variantu neurčuje. Pole JSON může podle smlouvy obsahovat standardní Base64.

Tichá oprava může skrýt poškození

Běžný adaptér nahradí mínus a podtržítko, doplní padding a použije standardní dekodér. Je to správné až po validaci abecedy a délky. Odstranění libovolných znaků vytváří příliš tolerantní parser.

Neplatná hodnota má být odmítnuta. Kompatibilitní normalizace patří na jednu jasnou hranici.

Dvojité URL decoding komplikuje chybu

Standardní Base64 vložené do query může změnit framework ještě před aplikací. Plus se stane mezerou a procenta se rozbalí. Další ruční decode opraví jeden případ a poškodí jiný.

Při diagnostice se porovnává odeslaná URL, raw request target, parsovaný parametr a vstup do Base64 dekodéru. Tak se odhalí skutečná transformační vrstva.

Každá parserová hranice musí mít stejnou smlouvu

CDN, web server, framework a aplikační router mohou URL normalizovat v různém pořadí. Hodnota, která je na první vrstvě ještě standardní Base64, může na další přijít s mezerou nebo dekódovaným procentem. Bezpečnostní kontrola a business logic pak pracují s jinými daty.

Integrační test má projít skutečnou infrastrukturou a zkontrolovat raw i parsovaný tvar. Nestačí otestovat samotnou helper funkci.

Přísná kanonizace omezuje duplikáty

Po úspěšném dekódování může služba pro běžné uložení znovu vytvořit jedinou povolenou Base64URL podobu. Tím zabrání tomu, aby padded a unpadded varianty vytvářely rozdílné cache keys nebo databázové řádky.

Původní text se zachovává tam, kde je součástí podpisu či auditu. Kanonizace pro identitu nesmí přepsat důkazní hodnotu přijaté zprávy.

Kanonická forma zjednodušuje identitu

Pokud databáze přijímá padded i unpadded string jako klíče, může uložit stejnou logickou hodnotu dvakrát. Po validaci lze pro běžné porovnání přejít na jeden tvar.

U podepsaných protokolů se ale musí zachovat původní text pro ověření. Model má rozlišovat identitu bajtů a podepsanou reprezentaci.

Migrace potřebuje smíšené období

Přechod starého pole na Base64URL nezmění klienty a uložené hodnoty najednou. Server může dočasně přijímat oba tvary, měřit využití a vždy vracet novou kanonickou formu.

Globální nahrazování znaků v neznámých stringách je nebezpečné. Transformace patří pouze do pole s jistou semantikou.

Varianta vychází z okolního formátu

Standardní Base64 zůstává správné pro MIME, PEM a mnoho API. Base64URL je správné pro JWT a hodnoty definované jako URL-safe. Ani jedna varianta není kryptograficky silnější.

Když smlouva určí abecedu, padding a kanonický tvar, obě jsou jednoduché a interoperabilní. Malý rozdíl znaků je důležitý kvůli parserům po cestě.