Bas 64

Inom datorprogrammering är Base64 en grupp binär-till-text-kodningsscheman som representerar binära data (mer specifikt en sekvens av 8-bitars byte ) i sekvenser om 24 bitar som kan representeras av fyra 6-bitars Base64-siffror .

Gemensamt för alla binär-till-text-kodningsscheman är Base64 utformad för att bära data lagrad i binära format över kanaler som endast på ett tillförlitligt sätt stöder textinnehåll. Base64 är särskilt utbredd på World Wide Web där en av dess användningsområden är möjligheten att bädda in bildfiler eller andra binära tillgångar i texttillgångar som HTML- och CSS -filer.

Base64 används också ofta för att skicka e- postbilagor. Detta krävs eftersom SMTP – i sin ursprungliga form – utformades för att endast transportera 7-bitars ASCII- tecken. Denna kodning orsakar en overhead på 33–37 % (33 % av själva kodningen; upp till 4 % mer av de infogade radbrytningarna).

Design

0 Varje Base64-siffra kan anta 64 olika värden, som kodar 6 bitar av data. Vilka tecken som väljs för att representera de 64 värdena varierar mellan implementeringarna. Den allmänna strategin är att välja 64 tecken som är gemensamma för de flesta kodningar och som också är utskrivbara . Denna kombination gör att det är osannolikt att data ändras under överföring genom informationssystem, som e-post, som traditionellt inte var 8-bitars rena . Till exempel MIME :s Base64-implementering A – Z , a – z och – 9 för de första 62 värdena. Andra varianter delar denna egenskap men skiljer sig i de symboler som valts för de två senaste värdena; ett exempel är UTF-7 .

De tidigaste instanserna av denna typ av kodning skapades för uppringd kommunikation mellan system som kör samma OS , till exempel uuencode för UNIX och BinHex för TRS-80 (senare anpassad för Macintosh ), och kunde därför göra fler antaganden om vilka tecken som var säkra att använda. Uuencode använder till exempel stora bokstäver, siffror och många skiljetecken, men inga gemener.

Base64 bord från RFC 4648

Detta är Base64-alfabetet som definieras i RFC 4648 §4 . Se även variantsammanfattning (nedan).

Index Binär Röding Index Binär Röding Index Binär Röding Index Binär Röding
0 000 000 A 16 010 000 F 32 100 000 g 48 110 000 w
1 000001 B 17 010001 R 33 100001 h 49 110001 x
2 000010 C 18 010010 S 34 100010 i 50 110010 y
3 000011 D 19 010011 T 35 100011 j 51 110011 z
4 000100 E 20 010100 U 36 100100 k 52 110100 0
5 000101 F 21 010101 V 37 100101 l 53 110101 1
6 000110 G 22 010110 W 38 100110 m 54 110110 2
7 000111 H 23 010111 X 39 100111 n 55 110111 3
8 001000 jag 24 011000 Y 40 101 000 o 56 111 000 4
9 001001 J 25 011001 Z 41 101001 sid 57 111001 5
10 001010 K 26 011010 a 42 101010 q 58 111010 6
11 001011 L 27 011011 b 43 101011 r 59 111011 7
12 001100 M 28 011100 c 44 101100 s 60 111100 8
13 001101 N 29 011101 d 45 101101 t 61 111101 9
14 001110 O 30 011110 e 46 101110 u 62 111110 +
15 001111 P 31 011111 f 47 101111 v 63 111111 /
Stoppning =

Exempel

Exemplet nedan använder ASCII- text för enkelhetens skull, men detta är inte ett typiskt användningsfall, eftersom det redan kan överföras säkert till alla system som kan hantera Base64. Den mer typiska användningen är att koda binära data (som en bild); den resulterande Base64-datan kommer bara att innehålla 64 olika ASCII-tecken, som alla på ett tillförlitligt sätt kan överföras mellan system som kan korrumpera de råa källbytena.

Här är ett välkänt idiom från distribuerad datoranvändning :

Många händer gör jobbet lätt.

När citatet (utan efterföljande blanksteg) är kodat i Base64, representeras det som en bytesekvens av 8-bitars vadderade ASCII- tecken kodade i MIME :s Base64-schema enligt följande (nylinjer och blanksteg kan finnas var som helst men ska finnas ignoreras vid avkodning):

TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

I ovanstående citat är det kodade värdet för Man TWFu . Kodade i ASCII lagras tecknen M , a och n som bytevärdena 77 , 97 och 110 , som är de 8-bitars binära värdena 01001101 , 01100001 och 01101110 . Dessa tre värden sammanfogas till en 24-bitars sträng som ger 010011010110000101101110 . Grupper om 6 bitar (6 bitar har maximalt 2 6 = 64 olika binära värden) omvandlas till individuella tal från början till slut (i detta fall finns det fyra nummer i en 24-bitars sträng), som sedan omvandlas till deras motsvarande Base64-teckenvärden.

Som detta exempel illustrerar, konverterar Base64-kodning tre oktetter till fyra kodade tecken.

Källa Text (ASCII) M a n
Oktetter 77 (0x4d) 97 (0x61) 110 (0x6e)
Bits 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0

Base64- kodad 		Sextetter 19 22 5 46
Karaktär T W F u
Oktetter 84 (0x54) 87 (0x57) 70 (0x46) 117 (0x75)

= utfyllnadstecken kan läggas till för att få det sista kodade blocket att innehålla fyra Base64-tecken.

Hexadecimal till oktal transformation är användbar för att konvertera mellan binär och Base64. Sådan konvertering är tillgänglig för både avancerade miniräknare och programmeringsspråk. Till exempel är den hexadecimala representationen av de 24 bitarna ovan 4d616e. Den oktala representationen är 23260556. Dessa 8 oktala siffror kan delas upp i par ( 23 26 05 56 ), och varje par kan konverteras till decimal för att ge 19 22 05 46 . Med de fyra decimaltalen som index för Base64-alfabetet är motsvarande ASCII-tecken TWFu .

Om det bara finns två signifikanta ingångsoktetter (t.ex. 'Ma'), eller när den sista ingångsgruppen endast innehåller två oktetter, kommer alla 16 bitar att fångas i de tre första Base64-siffrorna (18 bitar); de två minst signifikanta bitarna i det sista innehållsbärande 6-bitarsblocket kommer att visa sig vara noll och kasseras vid avkodning (tillsammans med det efterföljande = utfyllnadstecknet):

Källa Text (ASCII) M a
Oktetter 77 (0x4d) 97 (0x61)
Bits 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 0            

Base64- kodad 		Sextetter 19 22 4 Stoppning
Karaktär T W E =
Oktetter 84 (0x54) 87 (0x57) 69 (0x45) 61 (0x3D)

Om det bara finns en signifikant ingångsoktett (t.ex. 'M'), eller när den sista ingångsgruppen endast innehåller en oktett, kommer alla 8 bitar att fångas i de två första Base64-siffrorna (12 bitar); de fyra minst signifikanta bitarna i det sista innehållsbärande 6-bitarsblocket kommer att visa sig vara noll och kasseras vid avkodning (tillsammans med de efterföljande två = utfyllnadstecken ):

Källa Text (ASCII) M
Oktetter 77 (0x4d)
Bits 0 1 0 0 1 1 0 1 0 0 0 0                        

Base64- kodad 		Sextetter 19 16 Stoppning Stoppning
Karaktär T F = =
Oktetter 84 (0x54) 81 (0x51) 61 (0x3D) 61 (0x3D)

Output stoppning

Eftersom Base64 är en sexbitarskodning, och eftersom de avkodade värdena är uppdelade i 8-bitars oktetter, representerar vart fjärde tecken i Base64-kodad text (4 sextetter = 4 × 6 = 24 bitar) tre oktetter av okodad text eller data ( 3 oktetter = 3 × 8 = 24 bitar). Detta betyder att när längden på den okodade ingången inte är en multipel av tre, måste den kodade utmatningen ha utfyllnad tillagd så att dess längd är en multipel av fyra. Utfyllnadstecknet är = , vilket indikerar att inga ytterligare bitar behövs för att helt koda ingången. (Detta skiljer sig från A , vilket betyder att de återstående bitarna alla är nollor.) Exemplet nedan illustrerar hur trunkering av inmatningen av ovanstående citat ändrar utfyllnaden:

Inmatning Produktion Stoppning
Text Längd Text Längd
lätt arbete k. 11 bGlnaHQg d29y ay4= 16 1
lätt arbete k 10 bGlnaHQg d29y aw== 16 2
lätt wor 9 bGlnaHQg d29y 12 0
lätt wo 8 bGlnaHQg d28= 12 1
ljus w 7 bGlnaHQg dw== 12 2

Utfyllnadstecknet är inte nödvändigt för avkodning, eftersom antalet saknade byte kan härledas från längden på den kodade texten. I vissa implementeringar är utfyllnadstecknet obligatoriskt, medan det för andra inte används. Ett undantag där utfyllnadstecken krävs är när flera Base64-kodade filer har sammanfogats.

Avkodning Base64 med stoppning

Vid avkodning av Base64-text konverteras normalt fyra tecken tillbaka till tre byte. De enda undantagen är när utfyllnadstecken finns. En enkel = indikerar att de fyra tecknen kommer att avkodas till endast två byte, medan == indikerar att de fyra tecknen kommer att avkoda till endast en enskild byte. Till exempel:

Kodad Stoppning Längd Avkodad
bGlnaHQg dw== == 1 ljus w
bGlnaHQg d28= = 2 lätt wo
bGlnaHQg d29y Ingen 3 lätt wor

Ett annat sätt att tolka utfyllnadstecknet är att betrakta det som en instruktion att kassera 2 efterföljande bitar från bitsträngen varje gång a = påträffas . Till exempel, när ` bGlnaHQg dw== ` avkodas, konverterar vi varje tecken (förutom de efterföljande förekomsterna av = ) till deras motsvarande 6-bitars representation och kasserar sedan 2 avslutande bitar för den första = och ytterligare 2 efterföljande bitar för annat = . I det här fallet skulle vi få 6 bitar från d och ytterligare 6 bitar från w för en bitsträng med längden 12, men eftersom vi tar bort 2 bitar för varje = (för totalt 4 bitar), dw == slutar med att producera 8 bitar (1 byte) när den avkodas.

Avkodning Base64 utan stoppning

Utan utfyllnad, efter normal avkodning av fyra tecken till tre byte om och om igen, kan färre än fyra kodade tecken finnas kvar. I den här situationen kan bara två eller tre karaktärer finnas kvar. Ett enda återstående kodat tecken är inte möjligt, eftersom ett enda Base64-tecken bara innehåller 6 bitar och 8 bitar krävs för att skapa en byte, så det krävs minst två Base64-tecken: Det första tecknet bidrar med 6 bitar och det andra tecknet bidrar med sina första 2 bitar. Till exempel:

Längd Kodad Längd Avkodad
2 bGlnaHQg dw 1 ljus w
3 bGlnaHQg d28 2 lätt wo
4 bGlnaHQg d29y 3 lätt wor

Implementeringar och historia

Sammanfattningstabell för varianter

Implementeringar kan ha vissa begränsningar för alfabetet som används för att representera vissa bitmönster. Detta gäller särskilt de två sista tecknen som används i alfabetet på positionerna 62 och 63, och tecknet som används för utfyllnad (vilket kan vara obligatoriskt i vissa protokoll eller tas bort i andra). Tabellen nedan sammanfattar dessa kända varianter och ger länkar till underavsnitten nedan.

Kodning Kodning av tecken Separat kodning av rader Avkodning av icke-kodande tecken
62:a 63:a vaddera Separatorer Längd Kontrollsumma
RFC 1421 : Base64 for Privacy-Enhanced Mail (utfasad) + / = obligatorisk CR+LF 64 eller lägre för sista raden Nej Nej
RFC 2045 : Base64-överföringskodning för MIME + / = obligatorisk CR+LF Som mest 76 Nej Kasserade
RFC 2152 : Base64 för UTF-7 + / Nej Nej Nej
RFC 3501 : Base64-kodning för IMAP-brevlådenamn + , Nej Nej Nej
RFC 4648 §4 : base64 (standard) + / = valfritt Nej Nej
RFC 4648 §5 : base64url (URL- och filnamnssäker standard) - _ = valfritt Nej Nej
RFC 4880 : Radix-64 för OpenPGP + / = obligatorisk CR+LF Som mest 76 Radix-64-kodad 24-bitars CRC Nej
Andra varianter se Applikationer som inte är kompatibla med RFC 4648 Base64 ( nedan)

Sekretessförbättrad e-post

  Den första kända standardiserade användningen av kodningen som nu kallas MIME Base64 var i PEM-protokollet (Privacy-enhanced Electronic Mail ), som föreslogs av RFC 989 1987. PEM definierar ett "utskrivbart kodningsschema" som använder Base64-kodning för att transformera en godtycklig sekvens av oktetter till ett format som kan uttryckas i korta rader med 6-bitars tecken, som krävs av överföringsprotokoll som SMTP .

 0  Den nuvarande versionen av PEM (specificerad i RFC 1421 ) använder ett 64-teckens alfabet som består av stora och små romerska bokstäver ( A – Z , a – z ), siffrorna ( -9 ) och symbolerna + och / . Symbolen = används också som utfyllnadssuffix. Den ursprungliga specifikationen, RFC 989 , använde dessutom * -symbolen för att avgränsa kodad men okrypterad data inom utdataströmmen.

För att konvertera data till PEM-utskrivbar kodning placeras den första byten i de mest signifikanta åtta bitarna i en 24-bitars buffert , nästa i mitten åtta och den tredje i de minst signifikanta åtta bitarna. Om det finns färre än tre byte kvar att koda (eller totalt), kommer de återstående buffertbitarna att vara noll. Bufferten används sedan, sex bitar åt gången, mest signifikant först, som index i strängen: " ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ ", och det angivna tecknet matas ut.

Processen upprepas på återstående data tills färre än fyra oktetter återstår. Om tre oktetter återstår bearbetas de normalt. Om färre än tre oktetter (24 bitar) återstår att koda, utfylls indata till höger med noll bitar för att bilda en integrerad multipel av sex bitar.

Efter kodning av icke-utfyllda data, om två oktetter av 24-bitars bufferten är utfyllda-nollor, läggs två = tecken till utmatningen; om en oktett av 24-bitarsbufferten är fylld med vadderade nollor, läggs ett = tecken till. Detta signalerar avkodaren att de nollbitar som lagts till på grund av utfyllnad bör uteslutas från den rekonstruerade datan. Detta garanterar också att den kodade utdatalängden är en multipel av 4 byte.

PEM kräver att alla kodade rader består av exakt 64 utskrivbara tecken, med undantag för den sista raden, som kan innehålla färre utskrivbara tecken. Rader avgränsas av blanksteg enligt lokala (plattformsspecifika) konventioner.

MIMA

Huvudartikel: MIME

   MIME - specifikationen (Multipurpose Internet Mail Extensions) listar Base64 som en av två binär-till-text-kodningsscheman (den andra är citerad-utskrivbar) . MIMEs Base64-kodning är baserad på RFC 1421 -versionen av PEM: den använder samma 64-teckens alfabet och kodningsmekanism som PEM och använder = -symbolen för utfyllnad på samma sätt, som beskrivs i RFC 2045 .

MIME anger inte en fast längd för Base64-kodade rader, men den anger en maximal radlängd på 76 tecken. Dessutom specificerar den att alla tecken utanför standarduppsättningen med 64 kodningstecken (till exempel CRLF-sekvenser), måste ignoreras av en kompatibel avkodare, även om de flesta implementeringar använder ett CR/LF-nyradspar för att avgränsa kodade linjer .

Således är den faktiska längden på MIME-kompatibel Base64-kodad binär data vanligtvis cirka 137 % av den ursprungliga datalängden ( 4 ⁄ 3 × 78 ⁄ 76 ), även om omkostnaderna för mycket korta meddelanden kan vara mycket högre på grund av overheaden av rubrikerna. Mycket grovt sett är den slutliga storleken på Base64-kodad binär data lika med 1,37 gånger den ursprungliga datastorleken + 814 byte (för rubriker). Storleken på den avkodade datan kan uppskattas med denna formel: 

bytes = (sträng_längd(kodad_sträng) − 814) / 1,37

UTF-7

Huvudartikel: UTF-7

   UTF-7 , som först beskrevs i RFC 1642 , som senare ersattes av RFC 2152 , introducerade ett system som kallas modifierad Base64 . Detta datakodningsschema används för att koda UTF-16 som ASCII- tecken för användning i 7-bitars transporter som SMTP . Det är en variant av Base64-kodningen som används i MIME.

  Alfabetet "Modified Base64" består av MIME Base64-alfabetet, men använder inte utfyllnadstecknet " = ". UTF-7 är avsedd för användning i e-postrubriker (definierad i RFC 2047 ), och tecknet " = " är reserverat i det sammanhanget som escape-tecknet för "citerad-utskrivbar" kodning. Modifierad Base64 utelämnar helt enkelt utfyllnaden och slutar omedelbart efter den sista Base64-siffran som innehåller användbara bitar och lämnar upp till tre oanvända bitar i den sista Base64-siffran.

ÖppnaPGP

Ytterligare information: Pretty Good Privacy § OpenPGP

  OpenPGP , som beskrivs i RFC 4880 , beskriver Radix-64- kodning, även känd som " ASCII-rustning ". Radix-64 är identisk med "Base64"-kodningen som beskrivs av MIME, med tillägg av en valfri 24-bitars CRC . Kontrollsumman beräknas på ingångsdata före kodning ; kontrollsumman kodas sedan med samma Base64-algoritm och, prefixerad av symbolen " = " som separator, läggs till den kodade utdatan.

RFC 3548

    RFC 3548 , med titeln The Base16, Base32, and Base64 Data Encodings , är ett informativt (icke-normativt) memo som försöker förena RFC 1421- och RFC 2045 -specifikationerna för Base64-kodningar, alternativa alfabetskodningar, och Base32 är sällan används) och Base16-kodningar.

  Om inte implementeringar är skrivna till en specifikation som hänvisar till RFC 3548 och specifikt kräver annat, förbjuder RFC 3548 implementeringar att generera meddelanden som innehåller tecken utanför kodningsalfabetet eller utan utfyllnad, och den förklarar också att avkodarimplementationer måste avvisa data som innehåller tecken utanför kodningen alfabet.

RFC 4648

Denna RFC föråldrar RFC 3548 och fokuserar på Base64/32/16:

Det här dokumentet beskriver de vanligaste kodningsschemana Base64, Base32 och Base16. Den diskuterar också användningen av radmatningar i kodad data, användningen av utfyllnad i kodad data, användningen av icke-alfabetiska tecken i kodad data, användningen av olika kodningsalfabet och kanoniska kodningar.

URL-applikationer

Base64-kodning kan vara till hjälp när ganska lång identifieringsinformation används i en HTTP-miljö. Till exempel kan ett databasbeständighetsramverk för Java -objekt använda Base64-kodning för att koda ett relativt stort unikt id (vanligtvis 128-bitars UUID ) till en sträng för användning som en HTTP-parameter i HTTP-formulär eller HTTP GET- URL :er . Dessutom behöver många applikationer koda binär data på ett sätt som är bekvämt att inkludera i URL:er, inklusive i dolda webbformulärfält, och Base64 är en bekväm kodning för att rendera dem på ett kompakt sätt.

Att använda standard Base64 i URL kräver kodning av ' + ', ' / ' och ' = ' tecken till speciella procentkodade hexadecimala sekvenser (' + ' blir ' %2B ', ' / ' blir ' %2F ' och ' = ' blir ' %3D '), vilket gör strängen onödigt längre.

  Av denna anledning finns modifierade Base64 för URL- varianter (som base64url i RFC 4648 ), där tecknen ' + ' och ' / ' i standard Base64 respektive ersätts med ' - ' och ' _ ', så att användning av URL-kodare/ avkodare är inte längre nödvändiga och har ingen effekt på längden på det kodade värdet, vilket lämnar samma kodade form intakt för användning i relationsdatabaser, webbformulär och objektidentifierare i allmänhet. En populär sida att använda sig av är YouTube . Vissa varianter tillåter eller kräver att utfyllnaden ' = ' utelämnas för att undvika att de förväxlas med fältavgränsare, eller kräver att sådan utfyllnad är procentkodad. Vissa bibliotek [ vilka? ] kommer att koda ' = ' till ' . ', potentiellt exponerar applikationer för relativa sökvägsattacker när ett mappnamn kodas från användardata. [ citat behövs ]

HTML

atob () och btoa() , definierade i HTML5-utkastspecifikationen, tillhandahåller Base64-kodnings- och avkodningsfunktioner till webbsidor. Metoden btoa () matar ut utfyllnadstecken, men dessa är valfria i inmatningen av metoden atob() .

Andra applikationer

Base64 kan användas i en mängd olika sammanhang:

  • Base64 kan användas för att överföra och lagra text som annars skulle kunna orsaka avgränsningskollision
  • Base64 används för att koda teckensträngar i LDAP Data Interchange Format- filer
  • Base64 används ofta för att bädda in binär data i en XML- fil, med en syntax som liknar <data encoding="base64">...</data>, t.ex. favoritikoner i Firefoxs exporterade bookmarks.html .
  • Base64 används för att koda binära filer såsom bilder i skript, för att undvika beroende av externa filer.
  • Data -URI-schemat kan använda Base64 för att representera filinnehåll. Till exempel kan bakgrundsbilder och teckensnitt specificeras i en CSS- formatmallsfil som data: URI:er, istället för att tillhandahållas i separata filer.
  • Även om det inte ingår i den officiella specifikationen för SVG , kan vissa tittare tolka Base64 när de används för inbäddade element, till exempel bilder i SVG.
  • Base64 kan användas för att lagra/sända relativt små mängder binär data via en dators texturklippsfunktion, särskilt i fall där informationen inte garanterar att den sparas permanent eller när information snabbt måste skickas mellan en mängd olika, potentiellt inkompatibla program. Ett exempel är representationen av kryptovalutamottagares publika nycklar som Base64-kodade textsträngar, som enkelt kan kopieras och klistras in i användarnas plånboksprogram .
  • Binära data som snabbt måste verifieras av människor som en säkerhetsmekanism, såsom filkontrollsummor eller nyckelfingeravtryck , finns ofta representerade i Base64 för enkel kontroll, ibland med ytterligare formatering, som att separera varje grupp om fyra tecken i representationen av en PGP nyckelfingeravtryck med ett mellanslag.
  • QR-koder som innehåller binär data kommer ibland att lagra den kodad i Base64 istället för att bara lagra den råa binära datan, eftersom det finns en starkare garanti för att alla QR-kodläsare kommer att avkoda text korrekt, liksom det faktum att vissa enheter lättare sparar text från en QR-kod än potentiellt skadlig binär data.

Applikationer som inte är kompatibla med RFC 4648 Base64

Vissa applikationer använder ett Base64-alfabet som skiljer sig markant från alfabeten som används i de vanligaste Base64-varianterna (se variantöversiktstabellen ovan).

  •   Uuencoding - alfabetet innehåller inga gemener, utan använder istället ASCII-koder 32 (" " (mellanslag)) till 95 (" _ "), i följd. Uuencoding använder alfabetet " !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ " . Att undvika alla små bokstäver var till hjälp, eftersom många äldre skrivare bara utskrivna versaler. Användning av på varandra följande ASCII-tecken sparade datorkraft, eftersom det bara var nödvändigt att lägga till 32, utan att kräva en uppslagstabell. Användningen av de flesta skiljetecken och mellanslagstecken kan begränsa dess användbarhet i vissa applikationer, till exempel de som använder dessa tecken som syntax. [ citat behövs ]
  • BinHex 4 (HQX), som användes i det klassiska Mac OS , utesluter vissa visuellt förvirrbara tecken som " 7 ", " O ", " g " och " o ". Dess alfabet innehåller ytterligare skiljetecken. Den använder alfabetet " !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr " .
  • En UTF-8- miljö kan använda icke-synkroniserade fortsättningsbytes som base64: 0b10 xxxxxx . Se UTF-8#Självsynkronisering .
  • Flera andra applikationer använder alfabet som liknar de vanliga varianterna, men i en annan ordning:
    • Unix lagrar lösenords-hashar beräknade med krypt i filen /etc/passwd med en kodning som kallas B64 . kryptens alfabet sätter skiljetecken . och / före de alfanumeriska tecknen. krypten använder alfabetet " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ". Stoppning används inte.
    • GEDCOM 5.5 - standarden för genealogiskt datautbyte kodar multimediafiler i dess textradshierarkiska filformat. GEDCOM använder samma alfabet som krypt, vilket är " ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz " .
    • bcrypt- hashar är designade för att användas på samma sätt som traditionella crypt(3)-hashar, men bcrypts alfabet är i en annan ordning än crypts. bcrypt använder alfabetet " ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 " .
    • Xxencoding använder en mestadels alfanumerisk teckenuppsättning som liknar krypt, men använder + och - istället för . och / . Xxencoding använder alfabetet " +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz " .
    • 6PACK , som används med vissa terminalnodkontroller , använder ett alfabet från 0x00 till 0x3f.
    • Bash stöder numeriska bokstaver i Base64. Bash använder alfabetet " 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_ " .

Ett problem med RFC 4648-alfabetet är att när en sorterad lista med ASCII-kodade strängar Base64-transformeras och sorteras igen, ändras ordningen på elementen. Detta beror på att utfyllnadstecknet och tecknen i substitutionsalfabetet inte är ordnade efter ASCII-teckenvärde (vilket kan ses med hjälp av följande exempeltabells sorteringsknappar). Alfabet som (ostoppad) B64 adresserar detta.

ASCII Bas 64 Base64, ingen stoppning B64
ljus w bGlnaHQgdw== bGlnaHQgdw P4ZbO5EURk
lätt wo bGlnaHQgd28= bGlnaHQgd28 P4ZbO5EURqw
lätt wor bGlnaHQgd29y bGlnaHQgd29y P4ZbO5EURqxm

Se även


Hämtad från " https://en.wikipedia.org/w/index.php?title=Base64&oldid=1139396450 "