Wybierz Koduj lub Dekoduj, wybierz schemat i kliknij jego przycisk akcji. Całe przetwarzanie odbywa się w przeglądarce.
Czym są Base32 i Base58?
To dwie odpowiedzi na jedno pytanie: kanał przenoszący tekst ma przenosić bajty. Base32 i Base58 nie są szyfrowaniem ani haszowaniem — niczego nie ukrywają i niczego nie skracają. Przepisują ciąg bajtów przy użyciu ustalonego zestawu czytelnych znaków, a każdy, kto zna użyty zestaw, może to natychmiast odwrócić. Jedynym powodem, by wybrać jedno zamiast drugiego, jest to, co odbiorca robi ze znakami.
Dwie rodziny przepisują dane zupełnie różnymi sposobami, a ta różnica tłumaczy niemal każde zaskoczenie na tej stronie:
- Upakowanie bitów — Base32, Base32 Hex, Crockford Base32, z-base-32. Bajty są cięte na stałe grupy i każde pięć bitów staje się jednym znakiem. Długość wyniku jest przewidywalna na podstawie długości wejścia, a ostatnia, częściowo wypełniona grupa jest albo oznaczana znakami dopełnienia, albo pozostaje krótka.
- Konwersja liczby całkowitej — każdy alfabet Base58. Cały ciąg bajtów jest odczytywany jako jedna ogromna liczba w systemie o podstawie 256, a następnie zapisywany ponownie w podstawie 58. Nie ma grup ani dopełnienia; długość nie dzieli się na żadne części, a każdy wiodący bajt zerowy staje się jednym wiodącym znakiem zerowym.
Dokąd idzie sześć bitów danych: Base32 zużywa pięć bitów na znak, więc potrzebuje osiem znaków na każde pięć bajtów wejścia — czyli o około 60% więcej. Base58 zużywa około 5,86 bita na znak, więc wychodzi około 37% więcej. Base64 mieści sześć bitów na znak i daje 33%. Większe alfabety dają krótsze wyniki, ale są trudniejsze do odczytania na głos — i właśnie na to idzie każdy z nich.
Siedem alfabetów na tej stronie
Każdy alfabet jest wypisany w całości, a nie opisany, ponieważ dwa narzędzia, które pod tą samą nazwą drukują różne znaki, nie zgodzą się ze sobą bez względu na etykietę. Wiersze RFC 4648 są normatywne; wiersze Crockford i z-base-32 odpowiadają temu, co opublikował autor formatu; trzy wiersze Base58 to powszechne konwencje, a nie standardy, dlatego są wymienione osobno.
Crockford Base32 i symbol kontrolny modulo 37
Alfabet pomija I, L, O i U, aby żaden symbol nie mógł zostać odczytany jako inny. To, co zostało, nie rozróżnia wielkości liter przy wprowadzaniu: i i l odczytuje się jako cyfrę 1, o jako cyfrę 0, a myślniki istnieją tylko po to, by długi ciąg był czytelniejszy. Ponadto format definiuje opcjonalny symbol kontrolny, będący wartością ciągu symboli odczytanego jako liczba w systemie 32, wziętą modulo 37 i zapisaną z pięcioma dodatkowymi symbolami dla wartości 32–36.
Symbol kontrolny oblicza się z ciągu symboli, a nie z bajtów: ponieważ koder dopełnia ostatnią grupę zerami, dekodowanie tych samych znaków zawsze prowadzi do tej samej wartości. Dlatego wartość kontrolną z tabeli można odtworzyć ręcznie wyłącznie z kolumny zakodowanej. Pięć dodatkowych symboli to *, ~, $, = i U, odpowiadające wartościom 32, 33, 34, 35 i 36, więc symbol kontrolny nie zawsze jest cyfrą lub literą.
z-base-32
z-base-32 zachowuje pięciobitowe upakowanie RFC 4648 Base32 i zmienia tylko kolejność trzydziestu dwóch znaków. Kolejność dobrano tak, by znaki, które człowiek najczęściej musi zapisać, były najłatwiejsze do napisania i najtrudniejsze do pomylenia. Nie ma dopełnienia, więc czytelnik musi wiedzieć, ile symboli powinna mieć wartość; to cena formatu zaprojektowanego przede wszystkim do odczytu ręcznego.
Base58Check: bajt wersji, ładunek, cztery bajty sumy kontrolnej
Sam Base58 nie ma sposobu, by odróżnić ciąg z błędem od poprawnego, bo prawie każda kombinacja jego pięćdziesięciu ośmiu znaków jest prawidłową liczbą. Base58Check rozwiązuje to, umieszczając dane w opakowaniu: jeden bajt wersji, następnie ładunek, a potem pierwsze cztery bajty SHA-256 zastosowanego dwukrotnie do dwóch pierwszych części. Program odbierający ponownie oblicza te cztery bajty i odrzuca ciąg, jeśli się nie zgadzają. Bajt wersji mówi portfelowi, czy ma do czynienia z adresem płatności, adresem skryptu, czy kluczem prywatnym.
Generator stojący za konwerterem przyjmuje bajt wersji i ładunek w postaci szesnastkowej i zapisuje ciąg Base58Check; weryfikator odczytuje go z powrotem, odcina cztery bajty sumy kontrolnej, przelicza je i podaje zarówno znalezioną, jak i oczekiwaną wartość. Błędna suma kontrolna oznacza, że ciąg został przepisany z błędem lub zmieniony — nigdy nie oznacza, że sam ładunek jest błędny, ponieważ ładunku się nie interpretuje.
Częste nieporozumienia
- "Base64 to szyfrowanie." Nie. Nie ma klucza ani sekretu; wynik może odwrócić każdy. Base32 i Base58 są w tej samej sytuacji, a przepuszczenie wartości przez wszystkie trzy też nie daje ochrony.
- "Ciąg Base58 to adres Bitcoin." Tylko wtedy, gdy przechodzi też sumę kontrolną Base58Check i ma bajt wersji rozpoznawany przez oprogramowanie odbiorcy. Ciągi Base58 pojawiają się w wielu innych miejscach, w tym w zwykłych identyfikatorach bez żadnej sumy kontrolnej.
- "Trzy alfabety Base58 są wymienne." Używają tych samych pięćdziesięciu ośmiu znaków w trzech różnych kolejnościach, więc te same bajty dają trzy różne ciągi. Narzędzie musi wiedzieć, którego użyć, a ta strona zawsze podaje, którego użyła.
- "Dopełnienie jest częścią wartości." Znaki
= oznaczają tylko ostatnią grupę. Dwa ciągi Base32, różniące się wyłącznie dopełnieniem, opisują te same bajty, dlatego dekoder akceptuje ciąg z obciętym dopełnieniem. - "Działa każdy znak." Każdy alfabet to ustalony zestaw. Znak spoza niego nie ma wartości, więc dekoder zatrzymuje się i podaje ten znak wraz z jego pozycją zamiast zgadywać.
Najczęstsze pytania
Dlaczego Base32 używa 2-7, a nie 0-9? Ponieważ RFC 4648 dobrał alfabet tak, by mieścił się w znakach dozwolonych w nazwach domen i by łatwo było go odczytać na głos. Base32 Hex używa zamiast tego 0-9 A-V, gdy ważniejsze jest naturalne sortowanie.
Dlaczego ciąg Base58 tak często zaczyna się od 1? Każdy wiodący bajt zerowy wejścia staje się jednym wiodącym 1 (pierwszym znakiem alfabetów Bitcoin i Flickr). Bajt wersji 0x00 to jeden bajt zerowy, więc większość adresów mainnet Bitcoin zaczyna się od dokładnie jednej 1.
Co ładuje przycisk Przykład? Przykład należący do aktualnie wybranego schematu i kierunku, nigdy stały tekst. Koder dostaje tekst przykładu danego schematu — wektory z sekcji 10 RFC 4648 dla Base32 i Base32 Hex, 12345 Crockforda, wiersze z-base-32 podane powyżej — a dekoder dostaje zakodowany ciąg dla wybranego alfabetu, co sprawia, że przykład działa w obu kierunkach. Trzy wiersze Base58 celowo mają ten sam tekst, dzięki czemu przełączenie schematu i ponowne naciśnięcie Przykład pokazuje obok siebie trzy kolejności tych samych pięćdziesięciu ośmiu znaków. Gdy zaznaczony jest symbol kontrolny Crockford, dekoder dostaje wartość z symbolem na końcu — to jedyny sposób, by zobaczyć, jak weryfikator go akceptuje.
Czy ta strona wysyła moje dane gdziekolwiek? Nie. Każda konwersja odbywa się w tej karcie przeglądarki, a strona nie zawiera żadnych wywołań sieciowych. Dlatego działa też wtedy, gdy plik jest otwarty bezpośrednio z dysku.
Którego użyć dla sekretu? Sekrety uwierzytelniaczy TOTP i HOTP są zwykle w Base32 w alfabecie RFC 4648, ponieważ sekret trzeba wpisać ręcznie. Użyj tego, o co prosi oprogramowanie odbiorcy, i nigdy nie polegaj na samym kodowaniu, jeśli chodzi o tajność.