Base64URL endrer to alfabettegn: standard Base64s pluss blir en bindestrek, og skråstrek blir en understreking. Den kodede informasjonen er uendret. Varianten hjelper når den omkringliggende protokollen gir spesiell betydning til pluss eller skråstrek, men den fritar ikke verdien fra hver URL eller applikasjonsregel.
Bruk en vektor som viser forskjellen
Bytene FB FF koder som +/8= i standard Base64 og -_8= i Base64URL. En test som Hello produserer bare delte alfabettegn, så den kan ikke avsløre om URL-sikker konvertering fungerer.
const standard = btoa(String.fromCharCode(251, 255));
const urlSafe = standard.replace(/\+/g, '-').replace(/\//g, '_');
console.log(standard); // +/8=
console.log(urlSafe); // -_8=Polstring er en egen avtale
Mange tokenformater utelater avsluttende likhetstegn, mens andre systemer beholder dem. Å endre alfabetet og fjerne utfylling er to separate valg. Hvis lengden på inndata uten utfylling gir resten 2 ved divisjon med 4, må det legges til to likhetstegn; hvis resten er 3, trengs ett. En rest på 1 kan ikke rettes bare ved å legge til utfylling, fordi ett enkelt tegn på seks bit ikke kan beskrive en hel byte.
Ved validering, sjekk også ubrukte biter i det siste tegnet. En dekoder som ignorerer dem kan godta flere strenger for samme bytesekvens. Denne tvetydigheten kan ha betydning når en applikasjon sammenligner kodede strenger i stedet for dekodede byte. En kanonisk produsent bør avgi én avtalt representasjon.
Ikke forveksle spørringsanalyse med Base64-dekoding
Parsing av spørring i skjemastil tolker et bokstavelig pluss som et mellomrom. En standard Base64 verdi limt inn uescaped i en spørring kan derfor bli ødelagt før dekoderen ser den. Konstruer spørringen med URLSearchParams, eller bruk Base64URL-varianten hvis mottaksprotokollen spesifiserer det.
const query = new URLSearchParams({ payload: '+/8=' });
console.log(query.toString()); // payload=%2B%2F8%3D
console.log(query.get('payload')); // +/8=Ikke erstatt automatisk hvert mellomrom med pluss: et mellomrom kan være ekte formatering eller bevis på en annen feil. Bevar kilden, identifiser transportlaget som endret den, og bruk en bevisst korreksjon. For JWT-segmenter, bruk tokenformatets Base64URL-regler i stedet for å finne opp en generell reparasjonspolicy.
Standard og URL-sikre alfabeter er beskrevet i RFC 4648. Integrasjonen din trenger fortsatt eksplisitte valg for utfylling, aksept av blanke mellomrom og maksimal lengde.