Base64
7 verktyg
Vad är kodning?
Kodning är processen att konvertera data från en representation till en annan. Inom webbutveckling används kodning för att säkert överföra data genom kanaler som utformades för en begränsad teckenuppsättning — till exempel att skicka binärdata via ett textbaserat protokoll eller inkludera specialtecken i en URL.
Teckenkodning definierar hur texttecken mappas till bytes. Base64-kodning konverterar binärdata till ASCII-text. URL-kodning gör godtycklig text säker att använda i URL:er. Att förstå dessa tre kodningslager förhindrar svårfångade buggar och säkerhetsproblem.
Teckenkodningens historia
Teckenkodning är mappningen mellan tecken (bokstäver, symboler) och deras binära representationer. Utvecklingen från ASCII till Unicode speglar webbens globalisering:
7-bitars American Standard Code. 128 tecken: engelska bokstäver, siffror, skiljetecken och kontrollkoder. Definierade den grundläggande kodningen som alla andra bygger på.
Utökad ASCII för västeuropeiska språk. Lade till 128 tecken (betonade bokstäver, symboler). Inte lämplig för icke-latinska skriftsystem.
Universell teckenuppsättning som täcker alla världens skriftsystem. Definierar kodpunkter för över 149 000 tecken i 161 skriftsystem. Definierar inte kodning — det är UTF-8/16/32.
Variabelbredd-kodning av Unicode med 1–4 bytes per tecken. ASCII-kompatibel (de första 128 kodpunkterna är enkelbytes). Den dominerande kodningen på webben — över 98 % av alla webbplatser.
Variabelbredd-kodning med 2 eller 4 bytes per tecken. Används internt av Windows, Java och JavaScript-strängar. Inte ASCII-kompatibel.
Fast bredd-kodning: alltid 4 bytes per tecken. Enkel men slösar utrymme. Används i vissa databasinternaler. Sällan förekommande på webben.
Varför UTF-8 vann
UTF-8 blev dominerande eftersom det är bakåtkompatibelt med ASCII (de första 128 tecknen kodas identiskt), är självsynkroniserande (du kan hitta teckengränser genom skanning) och är utrymmeseffektivt för latinsk text. Varje ASCII-dokument är ett giltigt UTF-8-dokument. Detta gjorde migreringen sömlös.
Base64-kodning
Base64 konverterar binärdata till en textrepresentation med enbart 64 utskrivbara ASCII-tecken: A–Z, a–z, 0–9, + och /. Detta är nödvändigt när binärdata måste passera kanaler som bara hanterar text — e-postbilagor, data-URI:er, JWT-tokens och HTTP Basic Auth använder alla Base64.
Så här fungerar det
Base64 grupperar indatabytesen i 3-bytes (24-bitars) block och kodar varje block som 4 Base64-tecken (6 bitar vardera). Om indata inte är en multipel av 3 bytes läggs =-fyllnadstecken till för att fylla det sista blocket:
| Indata | Hex-bytes | Base64 |
|---|---|---|
| "Man" | 77 61 6E | TWFu |
| "Ma" | 4D 61 | TWE= |
| "M" | 4D | TQ== |
=-fyllnadstecknen i slutet anger hur många bytes som saknades för att fylla det sista 3-bytes-blocket. Ett = betyder att en byte fyllnad behövdes; == betyder att två bytes behövdes. Standard-Base64 ger alltid utdata vars längd är en multipel av 4.
URL-kodning
URL:er kan bara innehålla en begränsad uppsättning säkra ASCII-tecken. Alla tecken utanför den uppsättningen — inklusive mellanslag, skiljetecken, icke-ASCII-tecken och speciella URL-tecken som &, = och # — måste procentkodas (URL-kodas) innan de placeras i en URL.
Procentkodning ersätter varje osäker byte med ett % följt av två hexadecimala siffror som representerar bytens värde. Ett mellanslag blir %20, ett et-tecken blir %26, och så vidare.
Vanligt kodade tecken
| Tecken | Kodat | Noteringar |
|---|---|---|
| Space | %20 | Vanligast; används i formulärinlämningar som + i application/x-www-form-urlencoded |
| & | %26 | Frågesträngsavgränsare; måste kodas när det används som ett literalt värde |
| = | %3D | Nyckel-värde-avgränsare i frågesträngar; koda när det används som data |
| + | %2B | Tolkas som ett mellanslag i application/x-www-form-urlencoded; koda för att bevara literalt + |
| # | %23 | Fragmentidentifierare; koda när det används som literala data i en sökväg eller fråga |
| / | %2F | Sökvägssegmentavgränsare; koda när det används som literala data, inte som sökvägsseparator |
| : | %3A | Schemavgränsare; koda i sökvägs- och frågekontexter |
| @ | %40 | Används i mailto: och autentisering; koda när det används som literala data |
encodeURI vs encodeURIComponent
JavaScript tillhandahåller två kodningsfunktioner med olika räckvidd. encodeURI kodar en komplett URL — det lämnar tecken som har betydelse i URL:er (:, /, ?, #, @) okodade. encodeURIComponent kodar en URL-komponent (ett enskilt frågeparametervärde eller sökvägssegment) — det kodar alla tecken utom A–Z, a–z, 0–9, -, _, ., ~. Använd alltid encodeURIComponent för enskilda värden och encodeURI för kompletta URL:er.
Var kodning förekommer inom webbutveckling
Headern Authorization: Basic kodar inloggningsuppgifter som Base64(användarnamn:lösenord). Detta är kodning för transportbekvämlighet, INTE säkerhet — Base64 är trivialt reversibelt. Använd alltid HTTPS med Basic Auth.
Data-URI:er bäddar in filinnehåll direkt i HTML eller CSS: data:image/png;base64,.... Base64-kodning av bilder och typsnitt inline eliminerar HTTP-förfrågningar till priset av ökad dokumentstorlek (~33 % overhead).
E-post designades för 7-bitars ASCII. Binärbilagor (bilder, PDF-filer) Base64-kodas av MIME före sändning. Din e-postklient avkodar dem transparent när e-posten visas.
JWT-tokens använder Base64url-kodning (en variant som ersätter + med - och / med _, utan fyllnad) för alla tre delar (header, payload, signatur). Detta gör tokens URL-säkra utan ytterligare procentkodning.
All användarangiven data i URL-frågesträngar måste procentkodas. Underlåtenhet att koda & eller = i ett värde kommer tyst att förstöra frågesträngsparsningen. Använd alltid encodeURIComponent på enskilda värden.
Icke-ASCII-domännamn (t.ex. münchen.de) kodas med Punycode (xn---prefix) för kompatibilitet med DNS-systemet. Webbläsaren visar Unicode-formen men skickar Punycode-formen till DNS-resolvers.
Vanliga frågor
Nej. Base64 är kodning, inte kryptering. Det är en reversibel omvandling utan hemlig nyckel. Vem som helst som ser en Base64-sträng kan avkoda den omedelbart. Använd aldrig Base64 som säkerhetsåtgärd.
Base64 bearbetar indata i 3-bytes-grupper. Om indata inte är en multipel av 3 bytes läggs =-fyllnad till för att fylla den sista gruppen. Ett = betyder en byte fyllnad; == betyder två. Vissa implementationer utelämnar fyllnad (Base64url för JWT:er).
Base64url är en URL-säker variant av Base64 som ersätter + med - och / med _, och utelämnar vanligtvis =-fyllnad. Detta gör det säkert att använda i URL:er och HTTP-headers utan procentkodning. JWT:er använder Base64url för alla tre delar.
Använd encodeURIComponent för enskilda värden (frågeparametervärden, sökvägssegmentvärden). Använd encodeURI för en komplett URL-sträng där du vill bevara URL-strukturtecknen (/, :, ?, #). Om du är osäker, använd encodeURIComponent.
UTF-8 är ASCII-kompatibelt och utrymmeseffektivt för latinsk text (de flesta URL:er, HTML-taggar och kod är ASCII). UTF-16 slösar utrymme för ASCII-innehåll och är inte bakåtkompatibelt. HTTP och HTML använder UTF-8 som standard.
Procentkodning (URL-kodning) representerar tecken som % följt av deras tvåsiffriga hexadecimala bytevärde. Till exempel är ett mellanslag %20 (decimal 32, hex 20). Multi-bytes UTF-8-tecken kodar varje byte separat: é är %C3%A9.
Base64 ökar datastorleken med ungefär 33 % och lägger till CPU-overhead för kodning och avkodning. För system med hög genomströmning, föredra binära protokoll. URL-kodning lägger till minimal overhead men kan göra URL:er betydligt längre med många specialtecken.
Punycode är en kodning för att representera Unicode-tecken i det ASCII-kompatibla DNS-systemet. Internationaliserade domännamn som münchen.de kodas som xn--mnchen-3ya.de i DNS-frågor. Webbläsare visar Unicode-formen men använder Punycode internt.