Ce este Base64?
Base64 rescrie octeții folosind șaizeci și patru de caractere citibile, astfel încât datele să supraviețuiască unui canal construit pentru text: corpul unui e-mail, un șir JSON, un atribut XML, un URL. Fiecare trei octeți devin patru caractere, de aici vine numele — alfabetul conține șaizeci și patru de simboluri, iar fiecare transportă exact șase biți.
Este o codificare de transport, nu o măsură de securitate și nici un pas de compresie. Ieșirea este cu aproximativ o treime mai mare decât intrarea, iar oricine are șirul îl poate transforma imediat înapoi. Dacă se dorește să se știe dacă datele au fost modificate, se folosește un hash (Generatorul hash); dacă se dorește să rămână secrete, se folosește criptarea. Base64 nu face niciuna dintre acestea.
Singurul număr de reținut: trei octeți de intrare devin patru caractere de ieșire. Tot restul paginii decurge din asta. Patru caractere transportă douăzeci și patru de biți, iar douăzeci și patru de biți înseamnă exact trei octeți, deci nicio dată nu se pierde și nu se inventează nimic — cu excepția capătului, unde intrarea poate să nu umple ultimul grup de trei.
Cele cinci alfabete pe care le poate folosi această pagină
Primele două rânduri sunt standarde, iar ultimele trei sunt convenții care s-au format în jurul Unix. Toate cinci transportă aceiași șase biți pe caracter și diferă doar prin cele șaizeci și patru de caractere care îi transportă, deci aceiași octeți devin cinci șiruri diferite. Niciun element din șir nu arată ce alfabet l-a produs, de aceea selectorul de alfabet este implicit standard, iar caseta Sigur pentru URL este o scurtătură pentru al doilea rând.
Cum alege pagina un candidat: selectorul este implicit pentru ambele direcții. La decodare, panoul din dreapta citește și șirul în sine — - și _ pot veni doar din alfabetul sigur pentru URL, iar + sau / pot veni doar din cel standard, iar un / sau un . aproape de început indică cele două alfabete Unix. Fiecare alfabet care poate citi intrarea curentă este listat acolo, cu motivul pentru care este sau nu candidat.
Împărțirea pe rânduri: 76 și 64 de caractere
MIME a cerut Base64 care să încapă într-un e-mail fără ca vreun rând să devină nerezonabil de lung, și a stabilit 76 de caractere pe rând, separate prin CRLF. Fișierele PEM, care înfășoară certificate și chei, folosesc 64. Întreruperile de rând nu fac parte din date: un decodor le elimină și reunește rândurile înainte de orice altceva, deci un șir înfășurat și unul neînfășurat se decodează în exact aceiași octeți. Fiecare rând, cu excepția ultimului, conține un număr întreg de grupuri de patru caractere, ceea ce face reunirea sigură.
Pagina lasă ieșirea pe un singur rând, dacă nu se alege o lățime, iar decodorul acceptă intrarea cu sau fără întreruperi de rând. Întreruperile scrise de pagină sunt simple caractere de linie nouă, ceea ce poate păstra o casetă de text; corpurile e-mailurilor MIME folosesc tradițional un retur de car înaintea fiecărei linii noi, iar orice decodor utilizat acceptă ambele.
Umplutura și motivul pentru care poate fi eliminată
Când intrarea nu este multiplu de trei octeți, ultimul grup de patru caractere este incomplet, iar unul sau două caractere = îl completează. Ele nu transportă deloc date: spun doar câte dintre cele patru caractere sunt reale. Un decodor poate afla asta din lungime, de aceea Base64 sigur pentru URL renunță tradițional la umplutură — un = este incomod într-un URL sau într-un nume de fișier, iar unele sisteme îl codifică procentual.
Caseta de selectare din rândul de opțiuni păstrează umplutura atunci când este selectat alfabetul sigur pentru URL. Nimic altceva nu se schimbă; caracterele care transportă date sunt identice în ambele cazuri.
Neînțelegeri frecvente
- "Base64 ascunde datele." Nu. Este o substituție fără cheie, iar ideea întreagă este că oricine poate să o desfacă. Învelirea unei parole sau a unui token în Base64 nu schimbă nimic din cine îl poate citi.
- "Base64 comprimă." Dimpotrivă: fiecare trei octeți de intrare devin patru caractere de ieșire, deci textul este cu o treime mai mare decât datele pe care le transportă.
- "Întreruperile de rând fac parte din valoare." Sunt aspect. Adăugarea sau eliminarea lor nu schimbă niciodată octeții care ies la capăt.
- "Sigur pentru URL înseamnă o altă codificare." Este aceeași codificare cu două caractere schimbate:
+ devine -, iar / devine _, astfel încât șirul poate sta într-o cale de URL sau într-o valoare de interogare fără escapare.
- "Un șir care se decodează trebuie să fie Base64 valid." Orice șir de caractere din alfabet este Base64 valid, pentru că orice combinație de valori de șase biți este o secvență validă de octeți. Un șir se dovedește greșit abia la pasul următor, când se constată dacă acei octeți respectă formatul pe care trebuiau să îl aibă.
- "Umplutura arată ce alfabet a fost folosit." Nu, iar în majoritatea cazurilor nici caracterele nu o arată: alfabetele standard și cel sigur pentru URL coincid la șaizeci și doi din cele șaizeci și patru de simboluri, deci un șir scurt se citește adesea la fel în ambele.
Întrebări care apar des
De ce are uneori un șir Base64 un singur =, iar alteori doi? Unul înseamnă că ultimul grup transportă trei caractere reale, adică doi octeți de intrare; doi înseamnă că transportă două caractere, adică un octet de intrare. Fără niciun = înseamnă că lungimea intrării a fost multiplu de trei.
Poate Base64 să reprezinte fișiere binare arbitrare? Da, și aceasta este principala sa utilizare. Această pagină tratează intrarea ca text UTF-8; instrumentul dedicat Fișier în Base64 citește octeți brute, atunci când se dorește codificarea a ceva care nu este text.
Ce alfabet ar trebui folosit într-un API? Cel documentat de destinatar. Dacă documentația spune sigur pentru URL, se folosește acela; dacă nu spune nimic și valoarea circulă într-un URL, varianta sigură pentru URL, fără umplutură, este alegerea sigură.
Ieșirea este sensibilă la majuscule? Complet. a și A sunt valori diferite, de aceea Base64 suportă mult mai prost un caracter greșit decât Base32 sau Crockford Base32.
