Tech Help
Hvorfor bliver filer større med Base64?
Base64 gør normalt binære data cirka en tredjedel større. Se strukturen 3 bytes til 4 tegn, udfyldning, Data URL-overhead og hvornår den ekstra størrelse er det værd.
Base64 gør normalt binære data cirka en tredjedel større, fordi hver 3 bytes binære data repræsenteres med 4 udskrivbare Base64-tegn.
Hvis inputlængden ikke er et nøjagtigt multiplum af 3, kan standard Base64 med udfyldning tilføje =. Den kodede længde er 4 × ceil(n / 3), hvor n er den oprindelige bytelængde.
”Cirka 33 %” beskriver store input. Små input kan se ud som en langt større procent på grund af udfyldning. Base64 er ikke komprimering. For kodning kontra kryptering, se [Base64 er ikke kryptering: hvad det faktisk gør](/da/story/base64-is-not-encryption).
Denne artikel forklarer, hvorfor Base64-output er større end de oprindelige bytes. Det er ikke en sikkerhedsguide. Har du brug for kodning kontra kryptering, brug Base64 er ikke kryptering: hvad det faktisk gør.
Hvorfor har Base64 brug for mere plads?
3 bytes er 24 bit. Base64 deler de 24 bit i 4 grupper à 6 bit. Hver gruppe mappes til ét Base64-tegn, så 3 inputbytes bliver 4 outputtegn. Gemt som 1 byte pr. ASCII-tegn er det 4 / 3 ≈ 1,333 — cirka 33,3 % stigning.
- 3 bytes (24 bit)
- Delt i 4 grupper à 6 bit
- Hver gruppe → ét Base64-tegn
- 4 tegn (ofte 4 bytes tekst)
Et enkelt, tjekkbart eksempel
Disse kodninger matcher standard Base64 med udfyldning.
Man
ManBase64
TWFuMan er 3 UTF-8/ASCII-bytes. TWFu er 4 tegn: 3 → 4.
Hello
HelloBase64
SGVsbG8=Hello er 5 bytes. SGVsbG8= er 8 tegn, inklusive ét =. På små data får udfyldning procenten til at se større ud end 33 %.
Hvordan beregner man Base64-størrelse?
For standard Base64 med udfyldning gælder encodedLength = 4 × ceil(originalBytes / 3).
| Oprindelige bytes | Base64-tegn |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 eller 2 bytes giver stadig 4 tegn. Brug formlen, ikke et fast 33 %.
Hvad betyder udfyldningen “=”?
Tegnet = viser, at den sidste 3-byte-blok ikke var fuld. 1 inputbyte bruger to =; 2 bytes bruger ét; 3 bytes ingen. Udfyldning er ikke kryptering eller en sikkerhedsfunktion.
Bruger Base64URL mindre plads?
Base64URL skifter + til - og / til _, og Kodér Base64 udelader afsluttende = ved kodning. Det kan forkorte strengen med de =. Strukturen 3 bytes → 4 tegn er den samme, så Base64URL er ikke et mere pladseffektivt binært format.
Hvorfor kan små input vokse mere end 33 %?
1 byte → 4 tegn er 300 % længdeøgning. 2 bytes → 4 er 100 %. 3 bytes → 4 er cirka 33,3 %. Når n vokser, betyder udfyldning mindre, og meromkostningen nærmer sig cirka 33 %. Base64 er ikke altid præcis 33 % større.
Hvorfor er en Base64 Data URL endnu større?
En Data URL tilføjer et præfiks som data:image/png;base64, før payloaden. På en lille fil kan præfikset dominere procenten. Kodér Base64 kan give rå Base64 eller en Data URL; Data URL-output bruger standardalfabetet.
Base64 vs binært: hvad er mindre?
Rå binære data er mere pladseffektive til transport og lagring. Base64 er større, men tekstssikkert i JSON, e-mail og andre tekststier. Det er binær-til-tekst-kodning, ikke komprimering.
Komprimerer Base64 filer?
Nej. Base64 er ikke et komprimeringsformat. Den kodede tekst er normalt større end originalbytes. Hvis du senere kører gzip eller Brotli på den tekst, kan noget redundans skrumpe—resultatet afhænger af data og kompressor. gzip fjerner ikke Base64-meromkostningen helt.
Hvad sker der, hvis Base64 gzippes?
HTTP-komprimering kan reducere visse gentagne mønstre i Base64-tekst. JPEG, PNG eller ZIP komprimeres ofte dårligt allerede som rå bytes, og Base64-derefter-gzip er stadig sagsafhængigt. Der er ingen universel ekstra-procent efter gzip.
Skal du gemme filer som Base64?
Base64 kan passe binære data ind i et JSON-felt, en lille inline-ressource, et tekst-API, kopier/sæt ind eller en Data URL. For store filer vokser lagring, hukommelse og payload. Det betyder ikke ”brug aldrig Base64 til filer”.
Hvorfor er Base64 almindeligt i JSON-API’er?
JSON har ingen indbygget råbinær type, så API’er lægger ofte bytes i en Base64-streng. For store filer kan multipart/form-data, objektlagring eller direkte binær upload passe bedre. Ingen af valgene er altid bedst.
Hvorfor bruges Base64 i e-mail?
MIME kan bruge Base64, så en binær vedhæftning rejser som tekstssikre tegn. Den samme størrelsesmeromkostning gælder. Det er en transportrepræsentation, ikke en mindre fil.
Hvornår er den ekstra størrelse det værd?
Den ekstra størrelse kan være det værd, når binære data skal ligge i tekst, payloaden er lille, et API kræver Base64, eller du har brug for en Data URL. For store medier, foretræk rå binære data når systemet tillader det.
Hvornår bør du undgå Base64?
Spring det over ved store filer, stram båndbredde, hyppige overførsler eller når en binær sti allerede findes—situationsbestemt, ikke ”Base64 er dårlig praksis”.
Udfyldte Base64-længder du kan tjekke
Oprindelige byteantal og standard Base64-tegnantal med udfyldning:
| Oprindelige bytes | Base64-tegn |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
Alle rækker følger 4 × ceil(n / 3). Dette er antal Base64-tegn.
Eksempel: Hvor stor bliver en fil på 1.000 bytes?
4 × ceil(1000 / 3). ceil(333.333…) = 334, og 4 × 334 = 1336. Så 1.000 bytes bliver 1.336 Base64-tegn. Gemt som UTF-8/ASCII er hvert tegn typisk 1 byte—behandl ikke 1.336 som et nøjagtigt hukommelsesbyteantal.
Kan Base64 bruge mere hukommelse end filstørrelsen antyder?
Nogle runtimes gemmer strenge med mere end 1 byte pr. tegn, og kodning/afkodning kan holde en buffer og en streng samtidig. Hukommelsesforbruget er ikke nøjagtigt tegnlængden.
En enkel størrelsesguide
Hvis systemet accepterer rå binære data, foretræk det for størrelse. Hvis kun tekst er tilladt, kan Base64 passe. Ved en stor payload, tjek efter en binær uploadsti. Ved URL-sikker tekst, overvej Base64URL—3-til-4-udvidelsen består.
- Skal sende binære data
- Rå binære data tilladt? Foretræk binært for størrelse
- Kun tekstfelt? Base64 kan være passende
- Stor payload? Tjek binær uploadsti
- Brug for URL-sikker tekst? Overvej Base64URL
- Regn med cirka 33 % mere tekst på store input
Base64 er ikke designet til at gøre data mindre. Det gør binære data nemmere at repræsentere i tekstbaserede systemer, og prisen er ekstra størrelse.
Kod eller afkod Base64 i browseren
NEXNARA Kodér Base64 koder og afkoder tekst, og kan gøre en fil til Base64 eller en Data URL og Base64 tilbage til en fil.
Tekst bruger UTF-8-bytes, derefter Base64—ikke kun ASCII. Vælg Standard eller Base64URL. Filoutput kan være rå Base64 eller en Data URL (standardalfabet). Ugyldigt input afvises. Bytes, der ikke er UTF-8, skal bruge filtilstand, ikke tekstafkodning.
Filer over 10 MB kan gøre fanen langsom (advarsel). Filer over 32 MB blokeres.
Kodning og afkodning sker i din browser. Filen sendes ikke til en NEXNARA-server for dette værktøj. Annoncer og andre site-funktioner bruger stadig netværket.
Indsæt tekst eller en fil i Kodér Base64 og sammenlign oprindelige bytes med den kodede længde.
FAQ
Hvorfor øger Base64 filstørrelsen?
Det mapper 3 bytes (24 bit) til 4 tegn (4 × 6 bit). Gemt som tekst er det cirka en tredjedel mere for store input.
Er Base64 altid 33 % større?
Nej. Store input nærmer sig cirka 33,3 %. Små input kan vokse mere på grund af udfyldning. Brug 4 × ceil(n / 3).
Hvor meget større er Base64 end binært?
Standardlængde med udfyldning er 4 × ceil(n / 3) tegn. Et Data URL-præfiks lægger mere til.
Reducerer Base64-komprimering filstørrelsen?
Base64 komprimerer ikke. gzip eller Brotli på den kodede tekst kan skrumpe noget af den; de sletter ikke meromkostningen i alle tilfælde.
Bruger Base64URL mindre plads?
Det kan droppe = -udfyldning, så strengen kan blive 0–2 tegn kortere. 3-til-4-kodningsstrukturen er den samme.
Skal jeg bruge Base64 til store filer?
Kun hvis du har brug for tekst. Ved store eller hyppige overførsler er en binær sti ofte mindre. Base64 er ikke altid forkert for API’er.