Tech Help
Hvorfor blir filer større med Base64?
Base64 gjør vanligvis binærdata omtrent en tredjedel større. Se strukturen 3 byte til 4 tegn, utfylling, Data URL-påslag og når den ekstra størrelsen er verdt det.
Base64 gjør vanligvis binærdata omtrent en tredjedel større fordi hver 3 byte binærdata representeres med 4 utskrivbare Base64-tegn.
Hvis inndatalengden ikke er et nøyaktig multiplum av 3, kan standard Base64 med utfylling legge til =. Den kodede lengden er 4 × ceil(n / 3), der n er opprinnelig bytelengde.
«Omtrent 33 %» beskriver store inndata. Små inndata kan se ut som en mye større prosent på grunn av utfylling. Base64 er ikke komprimering. For koding kontra kryptering, se [Base64 er ikke kryptering: hva det faktisk gjør](/nb/story/base64-is-not-encryption).
Denne artikkelen forklarer hvorfor Base64-utdata er større enn de opprinnelige bytene. Det er ikke en sikkerhetsguide. Trenger du koding kontra kryptering, bruk Base64 er ikke kryptering: hva det faktisk gjør.
Hvorfor trenger Base64 mer plass?
3 byte er 24 bit. Base64 deler de 24 bitene i 4 grupper à 6 bit. Hver gruppe mappes til ett Base64-tegn, så 3 inndatabyte blir 4 utdatategn. Lagret som 1 byte per ASCII-tegn blir det 4 / 3 ≈ 1,333 — omtrent 33,3 % økning.
- 3 byte (24 bit)
- Delt i 4 grupper à 6 bit
- Hver gruppe → ett Base64-tegn
- 4 tegn (ofte 4 byte tekst)
Et enkelt, sjekkbart eksempel
Disse kodingene matcher standard Base64 med utfylling.
Man
ManBase64
TWFuMan er 3 UTF-8/ASCII-byte. TWFu er 4 tegn: 3 → 4.
Hello
HelloBase64
SGVsbG8=Hello er 5 byte. SGVsbG8= er 8 tegn, inkludert ett =. På små data får utfylling prosenten til å se større ut enn 33 %.
Hvordan beregner du Base64-størrelse?
For standard Base64 med utfylling gjelder encodedLength = 4 × ceil(originalBytes / 3).
| Opprinnelige byte | Base64-tegn |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 eller 2 byte gir likevel 4 tegn. Bruk formelen, ikke et fast 33 %.
Hva betyr utfyllingen «=»?
Tegnet = viser at den siste 3-byte-blokken ikke var full. 1 inndatabyte bruker to =; 2 byte bruker ett; 3 byte ingen. Utfylling er ikke kryptering eller en sikkerhetsfunksjon.
Bruker Base64URL mindre plass?
Base64URL bytter + til - og / til _, og Kod Base64 utelater avsluttende = ved koding. Det kan forkorte strengen med de =. Strukturen 3 byte → 4 tegn er den samme, så Base64URL er ikke et mer plasseffektivt binærformat.
Hvorfor kan små inndata vokse mer enn 33 %?
1 byte → 4 tegn er 300 % lengdeøkning. 2 byte → 4 er 100 %. 3 byte → 4 er omtrent 33,3 %. Når n vokser, betyr utfylling mindre, og merkostnaden nærmer seg omtrent 33 %. Base64 er ikke alltid nøyaktig 33 % større.
Hvorfor er en Base64 Data URL enda større?
En Data URL legger til et prefiks som data:image/png;base64, før nyttelasten. På en liten fil kan prefikset dominere prosenten. Kod Base64 kan gi rå Base64 eller en Data URL; Data URL-utdata bruker standardalfabetet.
Base64 mot binært: hva er mindre?
Rå binærdata er mer plasseffektive for transport og lagring. Base64 er større, men teksttrygt i JSON, e-post og andre tekststier. Det er binær-til-tekst-koding, ikke komprimering.
Komprimerer Base64 filer?
Nei. Base64 er ikke et komprimeringsformat. Den kodede teksten er vanligvis større enn originalbytene. Hvis du siden kjører gzip eller Brotli på den teksten, kan noe redundans krympe—resultatet avhenger av data og kompressor. gzip fjerner ikke Base64-merkostnaden helt.
Hva skjer hvis Base64 gzippes?
HTTP-komprimering kan redusere visse gjentatte mønstre i Base64-tekst. JPEG, PNG eller ZIP komprimeres ofte dårlig allerede som rå byte, og Base64-deretter-gzip er fortsatt tilfelleavhengig. Det finnes ingen universell ekstra-prosent etter gzip.
Bør du lagre filer som Base64?
Base64 kan passe binærdata inn i et JSON-felt, en liten innebygd ressurs, et tekst-API, kopier/lim inn eller en Data URL. For store filer vokser lagring, minne og nyttelast. Det betyr ikke «bruk aldri Base64 for filer».
Hvorfor er Base64 vanlig i JSON-API-er?
JSON har ingen innebygd råbinær type, så API-er legger ofte byte i en Base64-streng. For store filer kan multipart/form-data, objektlagring eller direkte binæropplasting passe bedre. Ingen av valgene er alltid best.
Hvorfor brukes Base64 i e-post?
MIME kan bruke Base64 slik at et binært vedlegg reiser som teksttrygge tegn. Den samme størrelsesmerkostnaden gjelder. Dette er en transportrepresentasjon, ikke en mindre fil.
Når er den ekstra størrelsen verdt det?
Den ekstra størrelsen kan være verdt det når binærdata må ligge i tekst, nyttelasten er liten, et API krever Base64, eller du trenger en Data URL. For store medier, foretrekk rå binærdata når systemet tillater det.
Når bør du unngå Base64?
Hopp over det for store filer, trang båndbredde, hyppige overføringer eller når en binær sti allerede finnes—situasjonsbestemt, ikke «Base64 er dårlig praksis».
Utfylte Base64-lengder du kan sjekke
Opprinnelige byteantall og standard Base64-tegnantall med utfylling:
| Opprinnelige byte | Base64-tegn |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
Alle rader følger 4 × ceil(n / 3). Dette er antall Base64-tegn.
Eksempel: Hvor stor blir en fil på 1 000 byte?
4 × ceil(1000 / 3). ceil(333.333…) = 334, og 4 × 334 = 1336. Så 1 000 byte blir 1 336 Base64-tegn. Lagret som UTF-8/ASCII er hvert tegn vanligvis 1 byte—ikke behandle 1 336 som et nøyaktig minnebyteantall.
Kan Base64 bruke mer minne enn filstørrelsen tyder på?
Noen kjøretider lagrer strenger med mer enn 1 byte per tegn, og koding/dekoding kan holde en buffer og en streng samtidig. Minnebruken er ikke nøyaktig tegnlengden.
En enkel størrelsesveiledning
Hvis systemet godtar rå binærdata, foretrekk det for størrelse. Hvis bare tekst er tillatt, kan Base64 passe. For en stor nyttelast, sjekk etter en binær opplastingssti. For URL-trygg tekst, vurder Base64URL—3-til-4-utvidelsen består.
- Må sende binærdata
- Rå binærdata tillatt? Foretrekk binært for størrelse
- Bare tekstfelt? Base64 kan være passende
- Stor nyttelast? Sjekk binær opplasting
- Trenger URL-trygg tekst? Vurder Base64URL
- Regn med omtrent 33 % mer tekst på store inndata
Base64 er ikke laget for å gjøre data mindre. Det gjør binærdata lettere å representere i tekstbaserte systemer, og kostnaden er ekstra størrelse.
Kod eller dekod Base64 i nettleseren
NEXNARA Kod Base64 koder og dekoder tekst, og kan gjøre en fil til Base64 eller en Data URL og Base64 tilbake til en fil.
Tekst bruker UTF-8-byte, deretter Base64—ikke bare ASCII. Velg Standard eller Base64URL. Filutdata kan være rå Base64 eller en Data URL (standardalfabet). Ugyldige inndata avvises. Byte som ikke er UTF-8 trenger filmodus, ikke tekstdekoding.
Filer over 10 MB kan gjøre fanen treg (advarsel). Filer over 32 MB blokkeres.
Koding og dekoding skjer i nettleseren din. Filen sendes ikke til en NEXNARA-server for dette verktøyet. Annonser og andre nettstedfunksjoner bruker fortsatt nettverket.
Lim inn tekst eller en fil i Kod Base64 og sammenlign opprinnelige byte med den kodede lengden.
FAQ
Hvorfor øker Base64 filstørrelsen?
Den mapper 3 byte (24 bit) til 4 tegn (4 × 6 bit). Lagret som tekst er det omtrent en tredjedel mer for store inndata.
Er Base64 alltid 33 % større?
Nei. Store inndata nærmer seg omtrent 33,3 %. Små inndata kan vokse mer på grunn av utfylling. Bruk 4 × ceil(n / 3).
Hvor mye større er Base64 enn binært?
Standardlengde med utfylling er 4 × ceil(n / 3) tegn. Et Data URL-prefiks legger til mer.
Reduserer Base64-komprimering filstørrelsen?
Base64 komprimerer ikke. gzip eller Brotli på den kodede teksten kan krympe noe av den; de fjerner ikke merkostnaden i alle tilfeller.
Bruker Base64URL mindre plass?
Den kan droppe = -utfylling, så strengen kan bli 0–2 tegn kortere. 3-til-4-kodingsstrukturen er den samme.
Bør jeg bruke Base64 for store filer?
Bare hvis du trenger tekst. For store eller hyppige overføringer er en binær sti ofte mindre. Base64 er ikke alltid feil for API-er.