Tech Help

Varför blir filer större med Base64?

Base64 gör vanligtvis binärdata ungefär en tredjedel större. Se strukturen 3 byte till 4 tecken, utfyllnad, Data URL-tillägg och när extra storleken är värd det.

Kort svar

Base64 gör vanligtvis binärdata ungefär en tredjedel större eftersom varje 3 byte binärdata representeras med 4 utskrivbara Base64-tecken.

Om indatalängden inte är en exakt multipel av 3 kan standardutfylld Base64 lägga till =. Den kodade längden är 4 × ceil(n / 3), där n är ursprunglig bytelängd.

”Cirka 33 %” beskriver stora indata. Små indata kan se ut som en mycket större procentsats på grund av utfyllnad. Base64 är inte komprimering. För kodning kontra kryptering, se [Base64 är inte kryptering: vad det faktiskt gör](/sv/story/base64-is-not-encryption).

Den här artikeln förklarar varför Base64-utdata är större än de ursprungliga byten. Det är inte en säkerhetsguide. Behöver du kodning kontra kryptering, använd Base64 är inte kryptering: vad det faktiskt gör.

Varför behöver Base64 mer utrymme?

3 byte är 24 bitar. Base64 delar de 24 bitarna i 4 grupper om 6 bitar. Varje grupp mappas till ett Base64-tecken, så 3 indatabyte blir 4 utdatatecken. Sparat som 1 byte per ASCII-tecken blir det 4 / 3 ≈ 1,333 — ungefär 33,3 % ökning.

  • 3 byte (24 bitar)
  • Delas i 4 grupper om 6 bitar
  • Varje grupp → ett Base64-tecken
  • 4 tecken (ofta 4 byte text)
Steget 3 byte → 4 tecken är storlekskostnaden. Utfyllnad kan lägga till lite mer på korta indata.

Ett enkelt, kontrollerbart exempel

De här kodningarna stämmer med standardutfylld Base64.

Man

Man

Base64

TWFu

Man är 3 UTF-8/ASCII-byte. TWFu är 4 tecken: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello är 5 byte. SGVsbG8= är 8 tecken, inklusive ett =. På små data gör utfyllnad att procentsatsen ser större ut än 33 %.

Hur beräknar man Base64-storlek?

För standardutfylld Base64 gäller encodedLength = 4 × ceil(originalBytes / 3).

Ursprungliga byte Base64-tecken
14
24
34
48
58
68

1 eller 2 byte ger ändå 4 tecken. Använd formeln, inte ett fast 33 %.

Vad betyder utfyllnaden “=”?

Tecknet = visar att det sista 3-byte-blocket inte var fullt. 1 indatabyte använder två =; 2 byte använder ett; 3 byte inget. Utfyllnad är inte kryptering eller en säkerhetsfunktion.

Tar Base64URL mindre plats?

Base64URL byter + mot - och / mot _, och Koda Base64 utelämnar avslutande = vid kodning. Det kan korta strängen med de =. Strukturen 3 byte → 4 tecken är densamma, så Base64URL är inte ett mer yteffektivt binärformat.

Varför kan små indata växa mer än 33 %?

1 byte → 4 tecken är 300 % längdökning. 2 byte → 4 är 100 %. 3 byte → 4 är cirka 33,3 %. När n växer spelar utfyllnad mindre roll och merkostnaden närmar sig cirka 33 %. Base64 är inte alltid exakt 33 % större.

Varför är en Base64 Data URL ännu större?

En Data URL lägger till ett prefix som data:image/png;base64, före nyttolasten. På en liten fil kan prefixet dominera procentsatsen. Koda Base64 kan ge rå Base64 eller en Data URL; Data URL-utdata använder standardalfabetet.

Base64 mot binärt: vad är mindre?

Rå binärdata är mer yteffektivt för transport och lagring. Base64 är större, men textsäkert i JSON, e-post och andra textvägar. Det är binär-till-text-kodning, inte komprimering.

Komprimerar Base64 filer?

Nej. Base64 är inte ett komprimeringsformat. Den kodade texten är vanligtvis större än originalbyten. Om du sedan kör gzip eller Brotli på den texten kan viss redundans krympa—resultatet beror på data och kompressor. gzip tar inte bort Base64-merkostnaden helt.

Vad händer om Base64 gzippas?

HTTP-komprimering kan minska vissa upprepade mönster i Base64-text. JPEG, PNG eller ZIP komprimeras ofta dåligt redan som råa byte, och Base64-sedan-gzip är fortfarande fallberoende. Det finns ingen universell extra-procent efter gzip.

Ska du lagra filer som Base64?

Base64 kan passa binärdata i ett JSON-fält, en liten inline-resurs, ett text-API, kopiera/klistra in eller en Data URL. För stora filer växer lagring, minne och nyttolast. Det betyder inte ”använd aldrig Base64 för filer”.

Varför är Base64 vanligt i JSON-API:er?

JSON har ingen inbyggd råbinär typ, så API:er lägger ofta byte i en Base64-sträng. För stora filer kan multipart/form-data, objektlagring eller direkt binäruppladdning passa bättre. Inget val är alltid bäst.

Varför används Base64 i e-post?

MIME kan använda Base64 så att en binärbilaga färdas som textsäkra tecken. Samma storleksmerkostnad gäller. Det är en transportrepresentation, inte en mindre fil.

När är extra storleken värd det?

Extra storlek kan vara värd det när binärdata måste ligga i text, nyttolasten är liten, ett API kräver Base64 eller du behöver en Data URL. För stora medier, föredra rå binärdata när systemet tillåter det.

När ska du undvika Base64?

Hoppa över det för stora filer, snäv bandbredd, täta överföringar eller när en binär väg redan finns—situationsbundet, inte ”Base64 är dålig praxis”.

Utfyllda Base64-längder du kan kontrollera

Ursprungliga byteantal och standardutfyllda Base64-teckenantal:

Ursprungliga byte Base64-tecken
14
24
34
1016
100136
1,0001,336

Alla rader följer 4 × ceil(n / 3). Det här är antal Base64-tecken.

Exempel: Hur stor blir en fil på 1 000 byte?

4 × ceil(1000 / 3). ceil(333.333…) = 334, och 4 × 334 = 1336. Alltså blir 1 000 byte 1 336 Base64-tecken. Sparat som UTF-8/ASCII är varje tecken vanligtvis 1 byte—behandla inte 1 336 som ett exakt minnesbyteantal.

Kan Base64 använda mer minne än filstorleken antyder?

Vissa körtider lagrar strängar med mer än 1 byte per tecken, och kodning/avkodning kan hålla en buffert och en sträng samtidigt. Minnesanvändningen är inte exakt teckenlängden.

En enkel storleksguide

Om systemet tar rå binärdata, föredra det för storlek. Om bara text tillåts kan Base64 passa. För en stor nyttolast, kolla efter en binär uppladdningsväg. För URL-säker text, överväg Base64URL—expansionen 3-till-4 finns kvar.

  • Behöver skicka binärdata
  • Rå binärdata tillåten? Föredra binärt för storlek
  • Endast textfält? Base64 kan vara lämpligt
  • Stor nyttolast? Kolla binär uppladdning
  • Behöver URL-säker text? Överväg Base64URL
  • Räkna med cirka 33 % mer text på stora indata
Base64 köper textkompatibilitet. Det köper inte en mindre fil.
Base64 byter utrymme mot textkompatibilitet

Base64 är inte gjort för att göra data mindre. Det gör binärdata lättare att representera i textsystem, och kostnaden är extra storlek.

Koda eller avkoda Base64 i webbläsaren

NEXNARA Koda Base64 kodar och avkodar text, och kan göra en fil till Base64 eller en Data URL och Base64 tillbaka till en fil.

Text använder UTF-8-byte, sedan Base64—inte bara ASCII. Välj Standard eller Base64URL. Filutdata kan vara rå Base64 eller en Data URL (standardalfabet). Ogiltig indata avvisas. Byte som inte är UTF-8 behöver filläge, inte textavkodning.

Filer över 10 MB kan sakta ner fliken (varning). Filer över 32 MB blockeras.

Kodning och avkodning sker i din webbläsare. Filen skickas inte till en NEXNARA-server för det här verktyget. Annonser och andra sajtfunktioner använder fortfarande nätverket.

Klistra in text eller en fil i Koda Base64 och jämför ursprungliga byte med den kodade längden.

FAQ

Varför ökar Base64 filstorleken?

Det mappar 3 byte (24 bitar) till 4 tecken (4 × 6 bitar). Sparat som text är det ungefär en tredjedel mer för stora indata.

Är Base64 alltid 33 % större?

Nej. Stora indata närmar sig cirka 33,3 %. Små indata kan växa mer på grund av utfyllnad. Använd 4 × ceil(n / 3).

Hur mycket större är Base64 än binärt?

Standardutfylld längd är 4 × ceil(n / 3) tecken. Ett Data URL-prefix lägger till mer.

Minskar Base64-komprimering filstorleken?

Base64 komprimerar inte. gzip eller Brotli på den kodade texten kan krympa en del; de tar inte bort merkostnaden i varje fall.

Tar Base64URL mindre plats?

Det kan släppa = -utfyllnad, så strängen kan bli 0–2 tecken kortare. Kodningsstrukturen 3-till-4 är densamma.

Ska jag använda Base64 för stora filer?

Bara om du behöver text. För stora eller täta överföringar är en binär väg ofta mindre. Base64 är inte alltid fel för API:er.