Base64-tekstencoder

Uitgewerkt voorbeeld

Het woord café encoderen:

1. UTF-8-encoding: 63 61 66 C3 A9 (5 bytes; de é is twee bytes in UTF-8)
2. Groepeer in blokken van 3 bytes: 63 61 66 | C3 A9
3. Elke 3 bytes worden 4 Base64-tekens: Y 2 F m | w 6 k =
4. Eindresultaat: Y2Fmw6k=

URL-safe Base64

Standaard Base64 gebruikt + en /, die gereserveerde betekenissen hebben in URL’s en bestandsnamen:

• + kan bij het decoderen van formulierachtige querygegevens in een spatie veranderen
• / scheidt URL-padsegmenten

URL-safe Base64 (RFC 4648 sectie 5) wisselt ze om voor - en _. Deze tool laat =-padding staan tenzij je die bij het coderen afzonderlijk uitschakelt. De variant wordt gebruikt in JWT-segmenten en bestandsnaamveilige contexten.

Opvulling (padding)

Base64-uitvoer is gegroepeerd in blokken van 4 tekens. Als de invoerlengte geen veelvoud van 3 bytes is, wordt het laatste blok aangevuld met = om de 4 tekens te vullen:

Sommige systemen (bijvoorbeeld JWT-segmenten) verwijderen de opvulling. Deze tool accepteert zowel correct opgevulde als correct ongepaddede invoer; andere ontvangers kunnen padding verplicht stellen.

Veelgemaakte fouten

• Base64 behandelen als encryptie. Dat is het niet. Iedereen kan Base64 decoderen; het verbergt niets.
• UTF-8 vergeten. “café” encoderen als Latin-1 geeft andere bytes dan UTF-8. Tenzij je de verwachting van de ontvanger kent, blijf bij UTF-8.
• Whitespace zonder toestemming accepteren. RFC 4648 schrijft standaard voor dat niet-alfabettekens worden afgewezen. Schakel de optie die ASCII-spaties, tabs, regeleinden en pagina-einden accepteert alleen in als het verwijzende formaat, zoals MIME, die uitdrukkelijk toestaat.