Se alege Codificare sau Decodificare, o schemă, apoi se apasă butonul de acțiune. Toată prelucrarea rămâne în browser.
Ce sunt Base32 și Base58?
Sunt două răspunsuri la aceeași întrebare: un canal care transportă text este rugat să transporte octeți. Base32 și Base58 nu sunt criptare și nu sunt hashing — nu ascund nimic și nu scurtează nimic. Rescriu un șir de octeți folosind un set fix de caractere lizibile, iar cine știe ce set a fost folosit îl poate transforma imediat înapoi. Singurul motiv pentru a prefera unul sau altul este ce face destinatarul cu caracterele.
Două familii fac această rescriere în moduri complet diferite, iar diferența explică aproape fiecare surpriză din această pagină:
- Împachetare pe biți — Base32, Base32 Hex, Crockford Base32, z-base-32. Octeții se împart în grupuri fixe, iar fiecare cinci biți devin un caracter. Lungimea ieșirii se poate prevedea din lungimea intrării, iar ultimul grup, parțial umplut, este fie marcat cu caractere de umplutură, fie lăsat scurt.
- Conversie cu numere mari — fiecare tabel Base58. Întregul șir de octeți se citește ca un singur număr enorm, în baza 256, și se scrie din nou în baza 58. Nu există grupuri și nicio umplutură; lungimea nu se împarte la nimic, iar fiecare octet zero de la început devine un simbol zero de la început.
Unde ajung cei șase biți care transportă date: Base32 folosește cinci biți pe caracter, deci are nevoie de opt caractere pentru fiecare cinci octeți de intrare — cu aproximativ 60% mai mult. Base58 folosește aproximativ 5,86 biți pe caracter, deci ajunge aproape de 37% mai mult. Base64 încape șase biți pe caracter și ajunge la 33%. Alfabetele mai mari sunt mai scurte și mai greu de citit cu voce tare, iar acesta este exact compromisul pe care îl face fiecare.
Cele șapte alfabete ale acestei pagini
Fiecare alfabet este tipărit integral, nu descris, pentru că două instrumente care tipăresc caractere diferite sub același nume nu vor fi de acord între ele, indiferent ce spune eticheta. Rândurile RFC 4648 sunt normative; rândurile Crockford și z-base-32 urmează ce a publicat autorul formatului; cele trei rânduri Base58 sunt convenții răspândite, nu standarde, de aceea sunt listate separat.
Crockford Base32 și simbolul de control modulo 37
Alfabetul elimină I, L, O și U, astfel încât niciun simbol să nu poată fi citit drept altul. Ce rămâne este insensibil la majuscule la intrare: i și l se citesc ca cifra 1, o se citește ca cifra 0, iar cratimele există doar pentru a face un șir lung mai ușor de citit. Peste asta, formatul definește un simbol de control opțional, care este valoarea șirului de simboluri citit ca număr în baza 32, luată modulo 37 și scrisă cu cinci simboluri suplimentare pentru valorile 32 până la 36.
Simbolul de control se calculează pe șirul de simboluri, nu pe octeți: pentru că encoderul completează cu zerouri ultimul grup, decodarea acelorași caractere revine mereu la aceeași valoare. De aceea valoarea de control din tabel poate fi reprodusă manual doar din coloana codificată. Cele cinci simboluri suplimentare sunt *, ~, $, = și U, pentru valorile 32, 33, 34, 35 și 36, deci un simbol de control nu este întotdeauna cifră sau literă.
z-base-32
z-base-32 păstrează împachetarea pe cinci biți din RFC 4648 Base32 și schimbă doar ordinea celor treizeci și două de caractere. Ordinea este aleasă astfel încât caracterele pe care o persoană este cel mai probabil să le noteze să fie cele mai ușor de scris și cele mai greu de confundat. Nu are umplutură, așa că cititorul trebuie să știe câte simboluri are o valoare așteptată; acesta este prețul unui format proiectat mai întâi pentru citire manuală.
Base58Check: un octet de versiune, datele utile, patru octeți de sumă de control
Base58 singur nu poate deosebi un șir tastat greșit de unul corect, pentru că aproape orice combinație a celor cincizeci și opt de caractere este un număr valid. Base58Check rezolvă asta punând datele într-un înveliș: un octet de versiune, apoi datele utile, apoi primii patru octeți din SHA-256 aplicat de două ori primelor două părți. Un program destinatar recalculează acești patru octeți și refuză șirul când nu se potrivesc. Octetul de versiune este cel care îi spune unui portofel dacă are în față o adresă de plată, o adresă de script sau o cheie privată.
Generatorul din spatele convertorului primește octetul de versiune și datele utile în hexazecimal și scrie șirul Base58Check; verificatorul citește un șir, desparte cei patru octeți de sumă de control, îi recalculează și raportează atât valoarea găsită, cât și pe cea așteptată. O sumă de control greșită înseamnă că șirul a fost tastat greșit sau modificat — niciodată că datele utile sunt greșite, pentru că datele utile nu sunt interpretate.
Neînțelegeri frecvente
- "Base64 este criptare." Nu. Nu există cheie și nici secret; rezultatul poate fi inversat de oricine. Base32 și Base58 se află în aceeași situație, iar trecerea unei valori prin toate trei nu adaugă nicio protecție.
- "Un șir Base58 este o adresă Bitcoin." Doar când trece și verificarea sumei Base58Check și poartă un octet de versiune recunoscut de software-ul destinatar. Șirurile Base58 apar în multe alte locuri, inclusiv în identificatori simpli, fără nicio sumă de control.
- "Cele trei alfabete Base58 sunt interschimbabile." Folosesc aceleași cincizeci și opt de caractere în trei ordini diferite, așa că aceiași octeți produc trei șiruri diferite. Un instrument trebuie să știe care să folosească, iar această pagină spune întotdeauna care a folosit.
- "Umplutura face parte din valoare." Caracterele
= marchează doar ultimul grup. Două șiruri Base32 care diferă doar prin umplutură descriu aceiași octeți, de aceea decodorul acceptă un șir cu umplutura tăiată.
- "Orice caractere funcționează." Fiecare alfabet este un set fix. Un caracter din afara lui nu are valoare, așa că decodorul se oprește și numește caracterul și poziția sa, în loc să ghicească.
Întrebări care apar des
De ce folosește Base32 2-7 și nu 0-9? Pentru că RFC 4648 a ales alfabetul astfel încât să rămână în caracterele pe care le poate conține un nume de domeniu și ca să fie ușor de citit cu voce tare. Base32 Hex folosește în schimb 0-9 A-V, atunci când contează mai mult sortarea naturală.
De ce începe deseori un șir Base58 cu 1? Fiecare octet zero de la începutul intrării devine un 1 de la început (primul caracter al alfabetelor Bitcoin și Flickr). Un octet de versiune 0x00 este un octet zero, așa că majoritatea adreselor Bitcoin din mainnet încep cu exact un 1.
Ce încarcă butonul Exemplu? Exemplul care aparține schemei și direcției afișate în momentul respectiv, niciodată un text fix. Codificatorului i se dă textul exemplului schemei — vectorii din secțiunea 10 a RFC 4648 pentru Base32 și Base32 Hex, 12345 din Crockford, rândurile z-base-32 tipărite mai sus — iar decodorului i se dă șirul codificat pentru alfabetul selectat, ceea ce face exemplul utilizabil în ambele direcții. Cele trei rânduri Base58 au intenționat același text, astfel încât schimbarea schemei și reapăsarea butonului Exemplu arată alături cele trei ordini ale aceleiași cincizeci și opt de caractere. Cu simbolul de control Crockford bifat, decodorului i se dă valoarea cu simbolul la capăt, singurul mod de a vedea verificatorul acceptând unul.
Sunt trimise datele undeva? Nu. Fiecare conversie se face în această filă a browserului, iar pagina nu conține niciun apel de rețea. De aceea funcționează și atunci când fișierul este deschis direct de pe disc.
Care dintre ele ar trebui folosită pentru un secret? Secretele aplicațiilor de autentificare TOTP și HOTP sunt de obicei Base32 în alfabetul RFC 4648, pentru că secretul trebuie tastat manual. Se folosește cel pe care îl cere software-ul destinatar și niciodată nu se bazează secretul pe codificare.