...
Ofte sendes binærdata av ulikt format, og man vil unngå risikoen for at ulike protokoller tolker dataene ulikt. Dersom man streamer bits og bytes over nettverket i råformat, vil man risikere at noen protokoller tror det overføres spesialtegn i bitmønsteret. Dette betyr at når man sender meldinger i "klartekst" rene bits uten å kode dem, vil man ikke ha noen garanti for at ulike protokoller tolker tegnene likt. Ved hjelp av Base64 omformer man binærdata til tekst slik at det blir enklere å sende både epost og html-skjemaer.
...
Nå har vi 8 ulike 6-bits mønster, og vi kan da bruke oversettelsestabellen fra forrige seksjon for å få den endelige Base64-strengen:
Bits | 010001 | 000110 | 000101 | 110100 | 011000 | 010000 | 000000 | 000000 |
Tallverdi | 17 | 6 | 5 | 52 | 24 | 16 | 0 | 0 |
Tegn | R | G | F | 0 | Y | Q | = | = |
...
Når man skal dekode fra Base64, følger man egentlig bare prosessen for å kode, bare baklengs. For enkelhets skyld, kan vi dekode RGF0YQ==, som ble brukt over. Det første man gjør, er å se på hvert enkelt tegn i strengen, for å så finne den korresponderende tallverdien i oppslagstabellen:
Tegn | R | G | F | 0 | Y | Q | = | = |
Tallverdi | 17 | 6 | 5 | 52 | 24 | 16 | 0 | 0 |
Bits | 010001 | 000110 | 000101 | 110100 | 011000 | 010000 | 000000 | 000000 |
...
De 2 padding-tegnene (==) i slutten, sier at de 4 siste tegn kun vil bli gjort om til ett tegn, og vi kan derfor ignorere de 2 siste gruppene. Hadde det vært ett padding-tegn, ville dette betydd at de 4 siste tegnene ville blitt gjort om til 2 tegn. Resten av gruppene kan vi bruke til å oversette til de dekodede tegnene, igjen via en ASCII-/UTF-8-tabell:
Bitmønster | 01000100 | 01100001 | 01110100 | 01100001 |
Tegn | D | a | t | a |
...