Velg Kod eller Dekod, velg en ordning og klikk på handlingsknappen. All behandling skjer i nettleseren.
Hva er Base32 og Base58?
Dette er to svar på ett spørsmål: en kanal som bærer tekst blir bedt om å bære bytes. Base32 og Base58 er verken kryptering eller hashing — de skjuler ikke noe og de forkorter ikke noe. De skriver om en bytesekvens med et fast sett lesbare tegn, og hvem som helst som kjenner settet som ble brukt, kan snu den rett tilbake. Den eneste grunnen til å foretrekke den ene framfor den andre er hva mottakerenden gjør med tegnene.
To familier gjør den omskrivingen på helt ulike måter, og forskjellen forklarer nesten alle overraskelsene på denne siden:
- Bitpakking — Base32, Base32 Hex, Crockford Base32, z-base-32. Bytene deles i faste grupper, og hver fem bit blir ett tegn. Utdatalengden kan forutsies ut fra inndatalengden, og den siste, delvis fylte gruppen merkes enten med utfyllingstegn eller lar være kort.
- Konvertering av store tall — alle Base58-tabeller. Hele bytesekvensen leses som ett enormt tall i base 256 og skrives ut igjen i base 58. Det finnes ingen grupper og ingen utfylling; lengden deler seg ikke på noe, og hver ledende nullbyte blir ett ledende nulltegn.
Hvor de seks databærende bitene havner: Base32 bruker fem bit per tegn, så det trenger åtte tegn for hver fem inndatabyte — omtrent 60% større. Base58 bruker omtrent 5,86 bit per tegn, så det havner nær 37% større. Base64 passer seks bit per tegn og havner på 33%. Større alfabeter er kortere, men vanskeligere å lese høyt, og det er nettopp den avveiningen hvert av dem gjør.
De syv alfabetene på denne siden
Hvert alfabet er skrevet ut i sin helhet i stedet for å beskrives, fordi to verktøy som skriver ut ulike tegn under samme navn ikke vil være enige, uansett hva etiketten sier. RFC 4648-radene er normative; Crockford- og z-base-32-radene følger det formatets forfatter har publisert; de tre Base58-radene er utbredte konvensjoner snarere enn standarder, og det er grunnen til at de er listet hver for seg.
Crockford Base32 og kontrollsymbolet modulo 37
Alfabetet dropper I, L, O og U, slik at ingen symbol kan leses som et annet. Det som er igjen, er ufølsomt for store og små bokstaver ved inndata: i og l leses som sifferet 1, o leses som sifferet 0, og bindestreker finnes bare for å gjøre en lang streng lettere å lese. Dessuten definerer formatet et valgfritt kontrollsymbol, som er verdien av symbolstrengen lest som et base 32-tall, tatt modulo 37, og skrevet med fem ekstra symboler for verdiene 32 til 36.
Kontrollsymbolet beregnes over symbolstrengen, ikke over bytene: fordi koderen fyller ut den siste gruppen med nuller, gir dekoding av de samme tegnene alltid tilbake den samme verdien. Derfor kan kontrollverdien i tabellen reproduseres for hånd fra den kodede kolonnen alene. De fem ekstra symbolene er *, ~, $, = og U for verdiene 32, 33, 34, 35 og 36, så et kontrollsymbol er ikke alltid et siffer eller en bokstav.
z-base-32
z-base-32 beholder femsbitspakkingen fra RFC 4648 Base32 og endrer bare rekkefølgen på de trettito tegnene. Rekkefølgen er valgt slik at tegnene en person mest sannsynlig må skrive ned, er de lettest å skrive og vanskeligst å forveksle. Den har ingen utfylling, så leseren må vite hvor mange symboler en verdi forventes å ha; det er prisen for et format som er laget for å leses for hånd først.
Base58Check: én versjonsbyte, nyttelasten, fire byte kontrollsum
Base58 alene har ingen måte å skille en feilskrevet streng fra en korrekt en, fordi nesten enhver kombinasjon av de femtiåtte tegnene er et gyldig tall. Base58Check løser det ved å pakke dataene inn i en ramme: én versjonsbyte, deretter nyttelasten, og så de fire første bytene av SHA-256 brukt to ganger på de to første delene. Et mottakerprogram beregner de fire bytene på nytt og avviser strengen når de ikke stemmer. Versjonsbyten er det som forteller en lommebok om den ser på en betalingsadresse, en skriptadresse eller en privat nøkkel.
Generatoren under konverteren tar versjonsbyten og nyttelasten som heksadesimal og skriver Base58Check-strengen; verifisereren leser en inn igjen, deler av de fire kontrollsumbytene, beregner dem på nytt og oppgir både den den fant og den den forventet. En feil kontrollsum betyr at strengen er skrevet feil eller endret — den betyr aldri at nyttelasten i seg selv er feil, siden nyttelasten aldri tolkes.
Vanlige misforståelser
- «Base64 er kryptering.» Nei. Det finnes ingen nøkkel og ingen hemmelighet; utdataene kan reverseres av hvem som helst. Base32 og Base58 står i samme stilling, og å dra en verdi gjennom alle tre gir heller ingen beskyttelse.
- «En Base58-streng er en Bitcoin-adresse.» Bare når den også består Base58Check-kontrollsummen og bærer en versjonsbyte som mottakerprogrammet kjenner igjen. Base58-strenger dukker opp mange andre steder, også som enkle identifikatorer uten noen kontrollsum i det hele tatt.
- «De tre Base58-alfabetene kan byttes om.» De bruker de samme femtiåtte tegnene i tre ulike rekkefølger, så de samme bytene gir tre ulike strenger. Et verktøy må få vite hvilket alfabet som skal brukes, og denne siden sier alltid hvilket den brukte.
- «Utfylling er en del av verdien.» Tegnene
= markerer bare den siste gruppen. To Base32-strenger som bare skiller seg i utfylling beskriver de samme bytene, og derfor godtar dekoderen en streng der utfyllingen er kuttet av. - «Alle tegn fungerer.» Hvert alfabet er et fast sett. Et tegn utenfor det har ingen verdi, så dekoderen stopper og oppgir tegnet og posisjonen i stedet for å gjette.
Spørsmål som ofte dukker opp
Hvorfor bruker Base32 2-7 og ikke 0-9? Fordi RFC 4648 valgte alfabetet slik at det holder seg innenfor tegnene et domenenavn kan inneholde, og slik at det er lett å lese høyt. Base32 Hex bruker 0-9 A-V i stedet når naturlig sortering betyr mer.
Hvorfor begynner en Base58-streng så ofte med 1? Hver ledende nullbyte i inndataene blir ett ledende 1 (det første tegnet i Bitcoin- og Flickr-alfabetene). En versjonsbyte på 0x00 er én nullbyte, så de fleste Bitcoin-adresser på hovednettet begynner med nøyaktig én 1.
Hva laster Eksempel-knappen? Eksempelet som hører til ordningen og retningen som vises på skjermen, aldri en fast tekst. Koderen får teksten i ordningens eget eksempel — RFC 4648 seksjon 10-vektorene for Base32 og Base32 Hex, Crockfords 12345, z-base-32-radene skrevet ut over — og dekoderen får den kodede strengen for det valgte alfabetet. Det er det som gjør eksempelet brukbart i begge retninger. De tre Base58-radene har bevisst samme tekst, slik at man ved å bytte ordning og trykke Eksempel på nytt ser de tre rekkefølgene av de samme femtiåtte tegnene side om side. Med Crockford-kontrollsymbolet avkrysset får dekoderen verdien med symbolet på slutten, som er den eneste måten å se verifisereren godta ett.
Sender denne siden data noe sted? Nei. Alle konverteringer skjer i denne nettleserfanen, og siden inneholder ingen nettverkskall av noe slag. Det er også derfor den fungerer når filen åpnes direkte fra disken.
Hvilken bør man bruke for en hemmelighet? TOTP- og HOTP-hemmeligheter for autentiserings-apper er vanligvis Base32 i RFC 4648-alfabetet, fordi hemmeligheten må skrives inn for hånd. Bruk den som mottakerprogrammet ber om, og stol aldri på kodingen selv for hemmelighold.
