Base64-koder og -dekoder

Base64 koder vilkårlige bytes som 64 utskrivbare ASCII-tegn, slik at binær-usikre transporter (JSON-strenger, URL-er, e-postkropper, miljøvariabler, HTTP Basic-auth) kan bære dem uten å ødelegge dem. Dette verktøyet håndterer UTF-8-input korrekt — det koder først strengen din til UTF-8-bytes, deretter Base64-koder disse bytene, slik at ikke-ASCII-tegn går rent tur-retur. Utdataen er omtrent 33 % større enn inndataen (hver 3 bytes blir 4 tegn).

Eksempel

Koding av teksten "Hello, world!":

SGVsbG8sIHdvcmxkIQ==

Koding av samme tekst med URL-sikker på (utfylling fjernet):

SGVsbG8sIHdvcmxkIQ

Koding av emoji-teksten "café ☕":

Y2Fmw6kg4piV

Hvorfor dekodes ikke Base64-strengen min?

• Standard vs URL-sikker-mismatch. Strenger med - eller _ er base64url, ikke standard Base64. Veksle URL-sikker-avkryssingen for å matche.
• Manglende utfylling. En standard Base64-streng må ha en lengde som er delelig med 4. SGVsbG8 feiler; SGVsbG8= fungerer. Fyll ut med = til lengden er delelig med 4.
• Mellomrom og linjeskift inni verdien. Noen systemer bryter Base64 ved 76 tegn med \n. De fleste dekodere tolererer dette, men strengere gjør det ikke. Fjern mellomrom før dekoding.
• Dekodet ved et uhell to ganger. Dekoding av U0dWc2JHOA== gir SGVsbG8, som i seg selv er en Base64-streng. Hvis utdataen ser ut som mer Base64, dekod den igjen.
• Ikke-UTF-8 binære data. Hvis de dekodede bytene ikke er gyldig UTF-8 (f.eks. en PNG-header), vil dekoding som tekst mislykkes eller vise søppel. Bruk et filbevisst Base64-verktøy for binær data.
• Smarte anførselstegn eller synlig ellipse. Kopiering fra et tekstbehandlingsprogram kan erstatte " med krøllete anførselstegn eller kutte lange strenger med en ellipse. Lim først gjennom et rentekstredigeringsprogram.

Hva er forskjellen mellom standard Base64 og URL-sikker Base64?

Standard Base64 (RFC 4648) bruker + og / og fyller ut med =. URL-sikker Base64 (base64url) erstatter + med - og / med _ og utelater vanligvis utfylling slik at strengen overlever uendret som en URL-sti eller spørringsparameter. JWT-er bruker base64url. Velg URL-sikker-avkryssingen når utdataen skal inn i en URL.

Håndterer dette verktøyet emoji og ikke-ASCII-tekst korrekt?

Ja. Inndata kodes først som UTF-8-bytes, deretter Base64-kodes disse bytene. Dekoding reverserer begge trinnene. Det er derfor når du limer inn "café" og dekoder resultatet, får du "café" tilbake, ikke mojibake. Mange eldre Base64-verktøy antar Latin-1 og korrumperer alt utenfor ASCII.

Kan jeg kode en binærfil som et bilde eller en PDF?

Denne siden koder kun tekst. For å Base64-kode en fil, slipp filen inn i et verktøy som leser den som binær (eller bruk nettleserkonsollen med FileReader.readAsDataURL). Dette verktøyet er for å kode strenger — det typiske bruksmønsteret når du bygger inn legitimasjon, konfig eller JSON-felter.

Hvorfor ser den dekodede utdataen ut som søppel?

Som regel var inndata ikke Base64 til å begynne med, eller det var URL-sikker Base64 dekodet som standard (eller omvendt). Prøv å veksle URL-sikker-avkryssingen. En annen vanlig årsak er å dekode en streng som faktisk er Base64-kodet binær, ikke tekst — i så fall er bytene ikke gyldig UTF-8.

Betyr =-utfyllingen noe?

Standard Base64 fyller ut utdataen slik at lengden er delelig med 4. De fleste dekodere godtar input uten utfylling, men noen strenge avviser det. URL-sikker Base64 utelater vanligvis utfylling. Hvis en dekoder klager, legg til =-tegn til lengden er delelig med 4, eller fjern dem alle og prøv igjen.

Lagrer dere noe av teksten jeg koder eller dekoder?

Nei. Vi lagrer ikke noe av teksten du limer inn her. Inndataen din forkastes i det øyeblikket du lukker eller oppdaterer siden — ingenting beholdes, og det finnes ingen oppføring av hva du kodet eller dekodet. Hvis du vil ha et ekstra lag med trygghet, kan du sjekke nettleserens utviklerverktøy.