Czym jest Base64?
Base64 zapisuje bajty za pomocą sześćdziesięciu czterech czytelnych znaków, aby dane przetrwały kanał zbudowany do tekstu: treść e-maila, ciąg JSON, atrybut XML, URL. Każde trzy bajty stają się czterema znakami, stąd nazwa — alfabet ma sześćdziesiąt cztery symbole, a każdy z nich niesie dokładnie sześć bitów.
To kodowanie transportowe, a nie zabezpieczenie i nie krok kompresji. Wynik jest mniej więcej o jedną trzecią większy od wejścia, a każdy, kto ma ciąg, może go od razu odwrócić. Gdy trzeba wiedzieć, czy dane zostały zmienione, służy do tego skrót (Generator skrótów); jeśli celem jest, by pozostały tajne, potrzebne jest szyfrowanie. Base64 nie robi żadnej z tych rzeczy.
Jedna liczba do zapamiętania: trzy bajty wejścia stają się czterema znakami wyjścia. Wszystko inne na tej stronie wynika z tego. Cztery znaki niosą dwadzieścia cztery bity, a dwadzieścia cztery bity to dokładnie trzy bajty, więc żadne dane nie giną ani nie powstają — z wyjątkiem końca, gdzie wejście może nie wypełnić ostatniej grupy po trzy.
Pięć alfabetów, których może używać ta strona
Pierwsze dwa wiersze to standardy, a ostatnie trzy to konwencje, które wyrosły wokół Uniksa. Wszystkie pięć niesie te same sześć bitów na znak i różni się jedynie tym, które sześćdziesiąt cztery znaki je niosą, więc te same bajty stają się pięcioma różnymi ciągami. Nic w ciągu nie mówi, który alfabet go wytworzył, dlatego selektor alfabetu domyślnie ustawia standardowy, a pole „bezpieczny dla URL” to skrót do drugiego wiersza.
Jak strona wybiera kandydata: selektor jest domyślny dla obu kierunków. Przy dekodowaniu panel po prawej odczytuje też sam ciąg — - i _ mogą pochodzić tylko z alfabetu bezpiecznego dla URL, + lub / tylko ze standardowego, a / lub . blisko początku wskazuje na dwa alfabety Unix. Tam wypisany jest każdy alfabet, który może odczytać bieżące wejście, wraz z powodem, dlaczego jest lub nie jest kandydatem.
Zawijanie wierszy: 76 i 64 znaki
MIME chciał Base64, który mieści się w e-mailu bez nadmiernie długich wierszy, i ustalił 76 znaków na wiersz rozdzielone CRLF. Pliki PEM, zawierające certyfikaty i klucze, używają 64. Podziały wierszy nie są częścią danych: dekoder usuwa je i łączy wiersze z powrotem przed czymkolwiek innym, więc ciąg zawinięty i niezawinięty dekodują się do dokładnie tych samych bajtów. Każdy wiersz oprócz ostatniego zawiera całkowitą liczbę czteroznakowych grup, co sprawia, że ich bezpieczne połączenie jest możliwe.
Ta strona zostawia wyjście w jednym wierszu, chyba że wybrano szerokość, a dekoder przyjmuje wejście z podziałami lub bez. Podziały, które zapisuje ta strona, to zwykłe znaki nowej linii, które mieści pole tekstowe; treści e-maili MIME tradycyjnie używają powrotu karetki przed każdym znakiem nowej linii, a każdy używany dekoder akceptuje oba.
Dopełnienie i dlaczego można je pominąć
Gdy wejście nie jest wielokrotnością trzech bajtów, ostatnia grupa czterech znaków jest niepełna i uzupełniają ją jeden lub dwa znaki =. Nie niosą one żadnych danych: tylko mówią, ile z czterech znaków jest prawdziwych. Dekoder może to wyliczyć z długości, dlatego Base64 bezpieczny dla URL tradycyjnie pomija dopełnienie — = jest niewygodne w URL lub nazwie pliku, a niektóre systemy kodują je procentowo.
Pole wyboru w wierszu opcji zachowuje dopełnienie, gdy wybrany jest alfabet bezpieczny dla URL. Nic innego się nie zmienia; znaki niosące dane są w obu przypadkach identyczne.
Częste nieporozumienia
- "Base64 ukrywa dane." Nie. To podstawienie bez klucza, a cała idea polega na tym, że każdy czytelnik może je odwrócić. Zawinięcie hasła lub tokena w Base64 nie zmienia tego, kto je odczyta.
- "Base64 kompresuje." Odwrotnie: każde trzy bajty wejścia stają się czterema znakami wyjścia, więc tekst jest o jedną trzecią większy niż niesione dane.
- "Podziały wierszy są częścią wartości." To kwestia prezentacji. Dodanie lub usunięcie ich nigdy nie zmienia bajtów, które wracają.
- "Bezpieczne dla URL oznacza inne kodowanie." To to samo kodowanie z dwoma zamienionymi znakami:
+ staje się -, a / staje się _, więc ciąg może siedzieć w ścieżce URL lub wartości zapytania bez escapowania. - "Ciąg, który się dekoduje, musi być poprawnym Base64." Każdy ciąg znaków alfabetu jest poprawnym Base64, bo każda kombinacja wartości sześciobitowych jest poprawnym ciągiem bajtów. Ciąg okazuje się błędny dopiero w następnym kroku, gdy te bajty zostaną sprawdzone względem formatu, który miały reprezentować.
- "Dopełnienie mówi, którego alfabetu użyto." Nie mówi, a w większości przypadków nie mówią tego także znaki: standardowy i bezpieczny dla URL alfabet zgadzają się co do sześćdziesięciu dwóch z sześćdziesięciu czterech symboli, więc krótki ciąg często czyta się tak samo w obu.
Najczęstsze pytania
Dlaczego ciąg Base64 czasem kończy się jednym znakiem =, a czasem dwoma? Jeden oznacza, że ostatnia grupa niesie trzy prawdziwe znaki, czyli dwa bajty wejścia; dwa oznaczają, że niesie dwa, czyli jeden bajt wejścia. Brak = oznacza, że długość wejścia była wielokrotnością trzech.
Czy Base64 może reprezentować dowolne pliki binarne? Tak, i to jego główne zastosowanie. Ta strona traktuje wejście jako tekst UTF-8; dedykowane narzędzie Plik do Base64 czyta surowe bajty, gdy trzeba zakodować coś, co nie jest tekstem.
Którego alfabetu użyć w API? Tego, który udokumentował odbiorca. Jeśli podaje bezpieczny dla URL, użyj go; jeśli nic nie podaje, a wartość trafia do URL, bezpieczny dla URL z pominiętym dopełnieniem jest bezpiecznym wyborem.
Czy wyjście rozróżnia wielkość liter? Całkowicie. a i A to różne wartości, dlatego Base64 znacznie gorzej znosi pomylony znak niż Base32 czy Crockford Base32.
