De eerste versie van de Base64 converter die ik op Toolz.dev heb verzonden had een bug I' ben nog steeds licht beschaamd over Het werkte perfect in elke test die ik schreef - gecodeerd, gedecodeerd, round-tripped, klaar Vervolgens plakte iemand tekst met een emoji en kreeg dit:
Uncaught DOMException: InvalidCharacterError:
Failed to execute 'btoa' on 'Window': The string to be
encoded contains characters outside of the Latin1 range.
Ik heb een tekstcoderingstool gebouwd en vergeten dat tekst, weet je, De meeste tekst. Elk niet-Latijns schrift, elk karakter met accenten, elke emoji - gebroken Mijn tests waren allemaal ASCII omdat ik denk in ASCII. Die bug heeft me meer over Base64 geleerd dan welke spec-lezing dan ook, en I' Ik zal je de oplossing later laten zien, omdat het bijna iedereen die aanraakt, laat struikelen btoa().
Base64 is een van die dingen die ontwikkelaars dagelijks gebruiken - binnen elke JWT, elke e-mailbijlage, elke data: URI - terwijl je zelden onder de motorkap kijkt Let' s kijken onder de motorkap.
tl;dr: Base64-codering converteert binaire gegevens naar 64 veilige ASCII-tekens, zodat deze via alleen-tekstkanalen zoals JSON, URL's en e-mail kunnen reizen - ten koste van ~33% overhead. Het is nee encryptie; iedereen kan het direct omkeren. Gebruik de gratis client-side om nu te coderen of te decoderen Base64-converter op Toolz.dev - uw gegevens verlaten nooit de browser, wat belangrijk is wanneer u ' tokens opnieuw decoderen.
Wat is Base64-codering?
Base64 is een binair-naar-tekst-coderingsschema: het vertegenwoordigt willekeurige bytes met slechts 64 tekens die elk tekstsysteem overleven dat ooit is gebouwd. De gezaghebbende specificaties zijn RFC 4648 (2006), hoewel de codering teruggaat tot RFC 1421 en Privacy Enhanced Mail in 1993 - is Base64 ouder dan de webbrowser.
Het alfabet:
A–Z→ Waarden 0–25a–z→ Waarden 26–510–9→ Waarden 52–61+→ 62,/→ 63=→ opvulling (geen waarde, alleen filler)
Waarom deze 64? Omdat ze niet zijn gemangeld in ASCII, EBCDIC en elke e-mailgateway die ooit is gebouwd. Base64 is een vredesverdrag met tientallen jaren infrastructuur voor alleen tekst.
De kosten van het verdrag: elke 3 input bytes worden 4 output karakters - een vaste 33% grootte belasting Houd dat aantal in je hoofd; het beslist echte architectuur vragen.
Hoe werkt het Base64-algoritme?
Korter antwoord dan jij'd verwacht: hergroepeer bits van 8s in 6s, zoek ze dan op in een tabel. 26 = 64 - dat's waar de naam vandaan komt.
codering Hi!piepsel
Stap 1 - bytes naar bits.
| hoedanigheid | ASCII | tweevoudig |
|---|---|---|
| h | 72 | 01001000 |
| mij | 105 | 01101001 |
| ! | 33 | 00100001 |
samengevat: 010010000110100100100001- 24 bits.
Stap 2 - hergroepeer in 6-bit brokken.
010010 | 000110 | 100100 | 100001
18 | 6 | 36 | 33
Stap 3 - zoek elke waarde op in het alfabet.
18 → S, 6 → G, 36 → k, 33 → h. ook weer Hi! codeert naar SGkh.
Dat is het hele algoritme. Geen wiskunde buiten een opzoektabel.
vulling Behandelt ingangen die geen veelvouden van 3 bytes zijn. gewoon coderen Hi (2 bytes = 16 bits) en u kunt alleen twee-en-een-bits 6-bits groepen vullen; de encoder de bits en de bits en de codes nul. = Om aan te geven hoeveel is vulmiddel:
Hi → SGk= (2 bytes remaining → one '=')
H → SA== (1 byte remaining → two '==')
Hi! → SGkh (multiple of 3 → no padding)
Toen ik dit implementeerde voor de Toolz.dev converter, was padding de plek waar al mijn off-by-one bugs leefden Als je ooit Base64 met de hand rolt - bijvoorbeeld voor een codeerinterview - schrijf dan eerst de opvullingstests.
Decodering is het spiegelbeeld: karakters terug naar 6-bits waarden, hergroeperen in 8-bits bytes, laten de opvulling vallen.
Waar kom je eigenlijk base64 tegen?
JWT's - de grote
Elk JSON-webtoken is drie met Base64url gecodeerde segmenten die zijn samengevoegd met stippen: header, payload, handtekening. Debugging auth is 50% decodering deze.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U
Decodeer het eerste segment en je krijgt {"alg":"HS256","typ":"JWT"}. De tweede geeft je de beweringen. Mijn workflow wanneer een token zich misdraagt: splitsen bij de stippen, decodeer elk onderdeel in de Base64-converter, plak dan de JSON in de JSON-formatter om het goed te lezen. twee pasta's, en je weet of de exp Beweren is jouw probleem.
Het is de moeite waard om duidelijk te zeggen: JWT-payloads zijn Leesbaar door iedereen die het token vasthoudt. De handtekening stopt met knoeien, niet lezen. Ik heb codebases beoordeeld die gevoelige gegevens in claims hebben gestopt, omdat de gebrabbel er impliceerde privacy uitzag. Het niet.
Gegevens-URI
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />
Door kleine activa in te embedden, wordt een HTTP-verzoek opgeslagen. Mijn vuistregel van het bouwen van afbeeldingszware WordPress-beheerders: de moeite waard onder ~ 5 KB, na 10 kB je hebt het document met 33% opgeblazen om toch een verzoek HTTP/2 multiplexen op te slaan.
Kubernetes Secrets - en een tirade
apiVersion: v1
kind: Secret
data:
password: cGFzc3dvcmQ= # decodes to "password"
Kubernetes Secrets zijn Base64-gecodeerd, en de valse beveiliging die dit met zich meebrengt is alarmerend. Die waarde decodeert in één pasta. Base64 bestaat hier, dus binaire waarden overleven YAML - a formatteren beslissing, geen beveiligingslek. Als je geheime verhaal eindigt bij "Ze zijn base64 in etcd, het is nog niet begonnen.
de rest van de lijst
HTTP Basic Auth-headers (Authorization: Basic dXNlcjpwYXNz Decodeert naar duidelijk user:pass- vandaar alleen HTTPS).E-mailbijlagen via MIME Binaire blobs binnen JSON payloads, omdat JSON geen binair type heeft.
Is Base64-codering? (Nee. Alsjeblieft, nee.)
zijn eigen sectie waard omdat de misvatting weigert te sterven.
Base64 is een protest, zoals het schrijven van een getal in hexadecimaal. Geen sleutel. Geen geheim. Decodering vereist niets anders dan de alfabettafel die openbaar is afgedrukt in RFC 4648. Alles base64-"beschermd" wordt beschermd op de manier waarop een brief wordt beschermd door in cursief te worden geschreven.
Als gegevens vertrouwelijkheid nodig hebben: correct versleutelen (AES-GCM of libnatrium), daarna Base64-codeer de cijfertekst als het kanaal tekst nodig heeft Codering en encryptie stellen prima samen - ze zijn gewoon & # 39; t vervangers. En als je integriteit nodig hebt in plaats van geheimhouding, dan is dat & # 39; een hash & # 39; s taak - de Hash-generator Dekt SHA-256 en vrienden.
Hoe verhoudt Base64 zich tot hex, URL-codering en base85?
| Basis64 | Hex (Base16) | URL/Percent codering | Ascii85 | |
|---|---|---|---|---|
| Grootte overhead | +33% | +100% | 0–200%, inhoudsafhankelijk | +25% |
| alfabet | 64 tekens | 16 tekens | ascii + %XX ontsnappingskracht |
85 tekens |
| Mensbare leesbare output | heel weinig | Soort byte grenzen zichtbaar | Meestal voor ASCII-invoer | heel weinig |
| Standaard URL-safe | nee (+, /, =) |
ja | Ja, per definitie | heel weinig |
| je zult het ontmoeten in | JWTS, MIME, data-URI's | Hashes, MAC-adressen, kleurcodes | Queryreeksen | pdf-internals |
Hoe ik kies: hers wanneer mensen de uitvoer zullen lezen of vergelijken - controlesommen, samenvattingen, alles wat met de oogbol wordt gedebugd. Percentage-codering Voor URL-tekst, nooit binair. Basis64 voor binaire kruising van een tekstkanaal - de meeste echte gevallen. Ascii85 Nooit vrijwillig; de 8% besparing moet de compatibiliteitsvragen nog rechtvaardigen.
Wat is URL-Safe Base64 en waarom bestaat het?
Standaard Base64 heeft een probleem: + betekent "space" in queryreeksen, / is de padscheider, = begrenst parameters Zet een standaard-Base64 token in een URL en wat middleware, ergens, zal het verminken - met tussenpozen, en alleen in productie Vraag me hoe ik het weet.
RFC 4648 Sectie 5 definieert de FIX, meestal base64url genoemd:
| standaard- | URL-veilig |
|---|---|
+ |
- |
/ |
_ |
= vulling |
meestal gewoon weggelaten |
Hetzelfde algoritme, twee tekens verwisseld, opvulling gedaald JWT's gebruiken uitsluitend Base64URL - en dat is precies de reden waarom het plakken van een JWT-segment in een strikte standaard-Base64-decoder soms mislukt op een zwerfvuil - of _. de Toolz.dev-converter Behandelt beide varianten, omdat een decoder die de helft van de real-world base64 afwijst, niet echt een decoder is.
Vuistregel: Als de gecodeerde tekenreeks ooit een URL, bestandsnaam of HTTP-header zal aanraken, gebruik dan vanaf het begin de URL-veilige variant. Retrofitten is een vondst en vervangen plus een gebed.
Hoe codeer en decodeer je in code?
JavaScript - de val waar ik in ben gevallen
Hier is de naïeve versie, degene die ik heb verzonden:
btoa('Hello') // "SGVsbG8=" — great!
btoa('café ☕') // InvalidCharacterError — the bug from my intro
btoa Dat is een ouderwetse afhandeling van de Unicode en accepteert alleen Latin-1. De juiste moderne benadering gaat expliciet door UTF-8 bytes:
// Encode: string → UTF-8 bytes → Base64
const bytes = new TextEncoder().encode('café ☕');
const encoded = btoa(String.fromCharCode(...bytes)); // "Y2Fmw6kg4piV"
// Decode: Base64 → bytes → string
const decoded = new TextDecoder().decode(
Uint8Array.from(atob(encoded), c => c.charCodeAt(0))
); // "café ☕"
(In Node.js, sla de ceremonie over: Buffer.from(str, 'utf8').toString('base64').)
pydon
import base64
encoded = base64.b64encode('café ☕'.encode('utf-8')).decode('ascii')
decoded = base64.b64decode(encoded).decode('utf-8')
# URL-safe variant — note -_ instead of +/
token = base64.urlsafe_b64encode(b'binary\xfb\xff').decode('ascii')
Python maakt het juiste duidelijk: jij moest bytes doorgeven, zodat de stap voor code-naar-UTF-8 niet kan worden vergeten. ik wens btoa was ontworpen met dezelfde ruggengraat.
PHP
$encoded = base64_encode('café ☕'); // handles bytes as-is — PHP strings ARE bytes
$decoded = base64_decode($encoded);
// URL-safe requires manual translation — a WordPress-plugin-developer classic:
$urlSafe = rtrim(strtr($encoded, '+/', '-_'), '=');
dat strtr/rtrim Line is verschenen in elke PHP-codebase waar ik ooit aan heb gewerkt, inclusief WP Adminify. PHP heeft nooit een ingebouwde URL-veilige variant gekregen, dus we blijven allemaal dezelfde twee regels schrijven.
Veelgestelde vragen
Waar wordt Base64-codering voor gebruikt?
Het converteert binaire gegevens naar ASCII-tekst, zodat het door systemen kan gaan die alleen tekst afhandelen: JSON-payloads, URL's, e-mail (MIME), HTTP-headers. Je ontmoet het het vaakst in JWT-tokens, data: URI's voor inline-afbeeldingen, Kubernetes-geheimen en API-payloads die bestanden bevatten. Het is een transportformaat, geen opslag- of beveiligingsformaat.
Is base64 hetzelfde als encryptie?
Nee, en het verwarren van de twee veroorzaakt echte beveiligingsincidenten Base64 heeft geen sleutel - voor decodering is alleen de openbare alfabettabel vereist, en er wordt één pasta in verwerkt decoder. Versleutel eerst met een echt algoritme (AES-GCM) en codeer vervolgens de cijfertekst als het kanaal tekst nodig heeft.
Waarom maakt Base64 data 33% groter?
Elk Base64-teken draagt 6 bits informatie maar beslaat een volledige 8-bit byte, dus 3 bytes invoer worden altijd 4 tekens uitvoer - 4/3 ≈ 1.33. it' s een vaste kostprijs van het formaat, onvermijdelijk door ontwerp Als grootte ertoe doet, comprimeer dan vóór codering, nooit erna - gecodeerde uitvoer ziet er willekeurig uit en comprimeert vreselijk.
Wat is het verschil tussen base64 en base64url?
BASE64URL-swaps + om - en / om _, en laat meestal de = opvulling, zodat de uitvoer URL's, bestandsnamen en headers overleeft zonder te ontsnappen Hetzelfde algoritme anders, gedefinieerd in RFC 4648 sectie 5. JWT's gebruiken uitsluitend Base64URL - daarom stikken strikte standaard-Base64-decoders er soms in.
Waarom gooit btoa() invalidcharacterror?
Je string bevat tekens buiten Latin-1 - een emoji, een teken met accenten, elk niet-westers schrift. btoa is een API uit de jaren 90 die dateert van vóór de verstandige afhandeling van Unicode. Encodeer naar UTF-8 bytes eerst met TextEncoder, dan base64 de bytes; ik heb deze exacte bug in een productietool verzonden, dus geen oordeel.
Hoe weet ik of een string base64 is?
Geldige Base64 gebruikt alleen A–Z, a–z, 0–9, +, / (of -, _ voor URL-veilig), optioneel volg =, met een lengte die ' is een veelvoud van 4 wanneer opgevuld Maar ook veel gewone woorden komen overeen met dat patroon - cafe is geldig base64 die decodeert naar garbage bytes. De echte test is het decoderen en controleren of de output zinvol is.
Waarom heeft mijn Base64-snaar aan het einde een verdwaalde nieuwe regel?
aangezien echo voegt er eerder een toe base64 ziet het ooit, dus echo "hunter2" | base64 Codeert acht bytes, niet zeven. printf of echo -n in plaats daarvan. Dit is de belangrijkste oorzaak van Kubernetes-geheimen die er goed uitzien in het manifest en tijdens runtime falen: het gedecodeerde wachtwoord draagt een onzichtbare volg \n. de base64 commando wikkelt de uitvoer op sommige systemen ook op 76 kolommen - pass -w 0 op GNU-kernutils om het te onderdrukken.
Hoe decodeer ik een JWT-token met de hand?
Splits het token op de twee stippen, neem het eerste segment (header) en de tweede (payload) en voer elk door een Base64-decoder- zij're Base64URL, dus gebruik een tool die accepteert - en _. Formatteer vervolgens de resulterende JSON in a JSON-formatter om de beweringen te lezen. Plak nooit productietokens in server-side tools; alleen client-side.
Hoe codeer ik een afbeelding of bestand naar base64?
Lees het bestand als bytes, dan base64 die bytes en prepend een data-uri-header zoals data:image/png;base64, Dus een browser kan het inline maken. In JavaScript, FileReader.readAsDataURL() doet beide stappen voor u; op de opdrachtregel, base64 logo.png drukt de ruwe codering af Houd het bij kleine activa - de 33% groottebelasting maakt Base64 slecht geschikt voor alles wat groot is, en big data-URI's laten uw HTML of CSS opzwellen.
Hoe decodeer ik base64 in javascript, python of de terminal?
Decodeer in het moderne JavaScript Unicode-veilig met new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))) in plaats van bloot atob. In Python, base64.b64decode(str) retourneert bytes - bellen .decode('utf-8') voor tekst. In een terminal, echo "aGk=" | base64 -d (of --decode). Alle drie verwachten standaard Base64, dus vertaal -/_ terug naar +// Eerst als je een Base64url-tekenreeks afhandelt.
de afhaalmaaltijd
Base64 is een 30 jaar oude bit-shuffling truc die stilletjes de helft van het moderne web omhoog houdt - auth tokens, bijlagen, inline assets, secrets-that-aren't-secret Begrijp de 6-bit hergroepering, respecteer de 33% belasting, vergis het nooit voor encryptie, en reik naar de URL-veilige variant waar een URL ook maar bij betrokken is Dat' is 95% van de praktische Base64-beheersing.
Voor het hands-on gedeelte is de Base64-converter op Toolz.dev doet standaard en URL-veilige codering volledig in uw browser - gebouwd door iemand die de Unicode les op de harde manier heeft geleerd, dus u don't hoeft te.
Meer in deze serie: de volledige Handleiding voor coderingshulpmiddelen de rest van de dagelijkse chauffeurs nutsbedrijven, de Regex Builder-gids pakt de andere vaardigheidsontwikkelaars aan die te doen alsof ze dat hebben, en sinds de helft van de debugging van Base64 eindigt in JSON, de Ultieme JSON-toolsgids is de natuurlijke volgende lezing.
Verwante artikelen:
