Base64 Bildedesoder | Dekoder og Forhåndsvis Bilder på Nettet

Hva er en base64-bildeavkoder?

En base64-bildeavkoder er et verktøy som gjør en base64-kodet tekststreng om til et bilde igjen. Base64 er en måte å skrive binærdata, for eksempel byte-ene i en bildefil, ved hjelp av bare 64 vanlige teksttegn (bokstaver, sifre, +, / og = som utfylling). Nettlesere, e-postsystemer og mange API-er lagrer bilder på denne måten, slik at et bilde kan sendes som vanlig tekst i stedet for som en separat fil. Avkoderen reverserer prosessen: Lim inn strengen, så vises originalbildet.

Data-URL-formatet

På nettet skrives et base64-bilde vanligvis som en data-URL. Mønsteret er:

For eksempel:

Hver del har en funksjon:

• data: markerer at dette er en data-URL, ikke en vanlig nettadresse.
• image/png er MIME-typen, som forteller nettleseren hva slags fil dette er.
• ;base64 angir at dataene etter kommaet er base64-kodet.
• Alt etter kommaet er selve det kodede bildet.

Slik fungerer avkoderen

Avkodingen skjer i fire trinn.

1. Verktøyet kontrollerer om strengen begynner med data:. En data-URL som angir en annen medietype enn et bilde, for eksempel data:text/plain, avvises med en gang, fordi den aldri kan vises som et bilde.
2. Det fjerner mellomrom, tabulatorer og linjeskift, siden lange base64-strenger noen ganger brytes over flere linjer. En nyttelast som bruker prosentkoding i stedet for base64, noe RFC 2397 også tillater, sendes videre uendret.
3. Den dekoder base64-teksten tilbake til rå byte.
4. Den undersøker de første byte-ene i resultatet. Alle vanlige bildeformater begynner med en fast byte-sekvens som kalles en signatur eller et «magisk tall». PNG-filer begynner med 89 50 4E 47, JPEG-filer begynner med FF D8 FF, og så videre. Avkoderen sammenligner disse signaturene og merker bildet med typen de identifiserer.

Byte-ene veier tyngre enn etiketten. Hvis en data-URL sier data:image/png, men byte-ene begynner med FF D8 FF, bygger avkoderen URL-en på nytt som data:image/jpeg, slik at strengen som tilbys av knappen «Kopier bilde-URL» aldri beskriver sitt eget innhold feil.

Hvis strengen ikke har prefikset data:, behandler avkoderen den som rå base64-data, dekoder den og leser signaturen på samme måte. Hvis byte-ene ikke samsvarer med noen kjent bildesignatur og heller ikke ser ut som SVG-tekst, melder avkoderen at strengen ikke ser ut til å være et bilde. Den gjetter ikke formatet og faller ikke tilbake på en standardtype.

SVG håndteres annerledes fordi SVG er et tekstformat (XML), ikke binærdata, og derfor ikke har en fast byte-signatur. Avkoderen undersøker de første 1024 byte-ene av den dekodede teksten etter en <svg-tagg, en XML-deklarasjon som <?xml version="1.0"?> etterfulgt av en slik tagg, eller en SVG-dokumenttypedefinisjon etterfulgt av en slik tagg. En byte-rekkefølgemarkør helt i starten, som enkelte redigeringsprogrammer legger til i UTF-8-filer, ignoreres. Siden SVG ikke kan identifiseres ut fra en bytesignatur, beholder en data-URL som angir image/svg+xml typen den selv angir.

Formel for bildestørrelse i base64

Base64 gjør hver 3 byte med binærdata om til 4 teksttegn. Formelen for den kodede lengden er:

Symbolene ⌈ ⌉ betyr «rund opp til nærmeste heltall», fordi base64 alltid arbeider i grupper på 4 tegn og fyller ut en ufullstendig gruppe med =-tegn.

For store filer gir dette omtrent en 33 % økning i størrelse, siden 4 ÷ 3 ≈ 1,33. Små filer kan vise en større prosentvis økning, fordi avrunding opp til neste gruppe på 4 tegn betyr mer når datamengden i utgangspunktet er liten.

Regneeksempel

PNG-eksempelet ovenfor dekodes til 85 byte bildedata. Med formelen:

Base64-strengen er faktisk 116 tegn lang, noe som stemmer. Det er en 36 % økning sammenlignet med de opprinnelige 85 byte-ene (116 ÷ 85 ≈ 1,36), litt over tallet 33 % fordi filen er så liten.

Støttede bildeformater

Avkoderen leser bytesignaturen til de dekodede dataene for å identifisere formatet. Den gjenkjenner disse typene:

Slik dekoder du et base64-bilde

1. Kopier base64-strengen, med eller uten prefikset data:image/..., fra HTML, CSS, et API-svar eller en e-post.
2. Lim den inn i inndatafeltet.
3. Bildet dekodes automatisk et øyeblikk etter at du slutter å skrive, eller når du trykker på avkodingsknappen.
4. Det dekodede bildet vises i forhåndsvisningsområdet. Data-URL-en kan kopieres med knappen «Kopier bilde-URL», og selve bildet kan lagres ved å høyreklikke på det i forhåndsvisningen og velge å lagre bildet, siden det gjengis som et vanlig bildeelement i nettleseren.

Vanlige bruksområder for base64-bilder

• Innebygging i HTML, CSS eller JavaScript: Når bildedataene legges direkte i koden, unngår man en separat forespørsel etter filen.
• E-postmaler: Enkelte e-postklienter blokkerer som standard bilder som er lenket eksternt, men et innebygd base64-bilde vises fortsatt.
• HTML-verktøy i én fil: En hel side, inkludert bildene, kan distribueres som én selvstendig fil.
• API-svar: Et bilde kan sendes i en JSON-nyttelast i stedet for å trenge sitt eget endepunkt.
• CSS-bakgrunner og ikoner: Små ikoner skrives noen ganger direkte inn i et stilark som en data-URL.

Ulemper ved base64-bilder

Base64-koding er praktisk, men har en kostnad:

• Den kodede teksten er omtrent en tredel større enn originalfilen.
• Nettlesere kan ikke hurtigbufre et innebygd bilde på samme måte som en lenket fil, så det lastes ned på nytt hver gang den omkringliggende siden eller stilarket lastes inn.
• Nettleseren må dekode base64-teksten før den kan vise bildet, noe som krever litt ekstra prosessering.
• På grunn av den økte størrelsen og manglende hurtigbufring egner base64-innbygging seg for små bilder som ikoner og enkle logoer. Større fotografier leveres vanligvis bedre som vanlige bildefiler.

Ofte stilte spørsmål

Hva er en base64-bildeavkoder?

Det er et verktøy som gjør en base64-kodet tekststreng om til et visbart bilde, for eksempel en PNG-, JPEG-, GIF-, WebP-, BMP- eller SVG-fil.

Hvordan dekoder jeg et base64-bilde?

Lim inn base64-strengen, med eller uten prefikset data:image/..., i avkoderen. Den leser strengen, dekoder den og viser bildet som resultat.

Kan en base64-streng dekodes uten data-URL-prefikset?

Ja. Avkoderen behandler den som rå base64-data, dekoder byte-ene og leser de første byte-ene for å identifisere formatet ut fra signaturen, for eksempel PNG, JPEG, GIF, WebP, BMP eller ICO. SVG identifiseres ved å lete etter en <svg-tagg i den dekodede teksten. Hvis ingen av disse samsvarer, melder avkoderen at strengen ikke ser ut til å være et bilde, i stedet for å gjette formatet.

Hvorfor dekodes ikke base64-bildet mitt?

Tre årsaker forklarer de fleste tilfellene. Strengen kan inneholde tegn utenfor standardalfabetet for base64, som er A–Z, a–z, 0–9, +, / og =; base64url-varianten som brukes i enkelte nett-token, skriver i stedet - og _, og godtas ikke. Strengen kan ha blitt avkortet underveis, slik at lengden er én mer enn et multiplum av fire, noe ingen gyldig base64-streng har. Eller byte-dataene er ganske enkelt ikke i et av de støttede bildeformatene. Manglende utfylling med = er ikke i seg selv et problem, og mellomrom eller linjeskift fjernes før avkodingen.

Er base64-koding en form for sikkerhet eller kryptering?

Nei. Base64 er bare en måte å representere byte som tekst på; den skjuler ingenting. Alle kan dekode en base64-streng på sekunder med et gratis verktøy, så den må aldri brukes til å beskytte private bilder eller andre data.

Hvor mye større er en base64-streng enn originalbildet?

Omtrent en tredel større for større filer, siden hver 3 byte med originaldata blir til 4 teksttegn. Et bilde på 100 KB blir omtrent 133 KB når det er kodet. Små bilder kan vise en noe større prosentvis økning på grunn av avrunding.

Historikk

Base64 utviklet seg fra kodingsmetoder som ble laget på 1970-tallet og 1980-tallet for å sende binærdata gjennom postsystemer som bare håndterte vanlig tekst. Metoden ble formalisert for e-post i RFC 989 (1987) og senere RFC 1421. Bruken av den til å bygge inn bilder på nettsider ble mulig da data:-URL-skjemaet ble definert i RFC 2397 (1998), og den ble vanligere på midten av 2000-tallet da utviklere lette etter måter å redusere antallet separate HTTP-forespørsler på, særlig ved langsomme mobilforbindelser.

Referanser

1. RFC 4648: Base16-, Base32- og Base64-datakodinger
2. RFC 2397: «data»-URL-skjemaet
3. MDN Web Docs: data-URL-er
4. WHATWG-standarden for MIME-gjenkjenning