Kodowanie i dekodowanie Base64
Koduj tekst lub pliki do Base64 i dekoduj ciągi z powrotem do bajtów w przeglądarce. Przykłady dopełniania, alfabet RFC 4648 i wariant bezpieczny dla URL.
Wszystkie obliczenia są wykonywane w przeglądarce. Nic z tego, co wprowadzisz, nie jest wysyłane na serwer.
Wyniki aktualizują się podczas wpisywania. Ctrl/Cmd+Enter kopiuje główny wynik.
Wynik
—
Widok bitów
Pokaż rozwiązanie
Kodowanie i dekodowanie Base64 zamienia dowolne bajty na ciąg ASCII według alfabetu RFC 4648 i odwraca ten ciąg do oryginalnych bajtów. Tryb tekstowy przyjmuje kodowanie znaków, na przykład UTF-8; tryb pliku odczytuje przesłany plik przez FileReader przeglądarki i może wyemitować URI data: do osadzenia. Kodowanie to nie szyfrowanie. Każdy, kto otrzyma ciąg, może go zdekodować.
Całe kodowanie i dekodowanie działa w przeglądarce. Wklejone dane nie trafiają na serwer.
Kodować tekst lub plik do Base64
Kodowanie bierze surowe bajty i zapisuje ciąg z liter A do Z, a do z, cyfr 0 do 9, plusa, ukośnika i dopełnienia =. Wklej tekst lub wybierz plik, ustaw kodowanie znaków, gdy źródło to tekst, i odczytaj wynik.
Tryb pliku nadaje się do małych obrazów i dokumentów, które muszą przejść przez JSON, XML lub e-mail bez kanału binarnego.
Wynik jest bezpieczny w systemach, które psują dowolne dane binarne, na przykład starsze bramki pocztowe lub wklejanie do XML. Z założenia jest dłuższy od wejścia. Nieprawidłowe puste wejście nie daje ciągu; narzędzie czeka na bajty przed emisją znaków.
Dekodować ciąg Base64 z powrotem do danych
Dekodowanie odwraca wyszukiwanie w alfabecie, odbudowuje oryginalny strumień bitów i zwraca tekst lub plik do pobrania. Znaki dopełnienia = na końcu mają znaczenie: oznaczają, ile bajtów było w ostatniej niepełnej grupie. Znaki spoza alfabetu powodują czytelny błąd zamiast cichego częściowego dekodowania.
Białe znaki są często ignorowane, więc ciągi skopiowane z certyfikatów PEM lub treści MIME nadal działają. Ciąg wyglądający jak Base64, ale używający alfabetu bezpiecznego dla URL, wymaga trybu dekodowania URL-safe, inaczej myślnik i podkreślenie zostaną odrzucone jako nielegalne w standardowym alfabecie.
Zrozumieć, jak działa kodowanie Base64
Base64 przetwarza wejście w blokach po trzy bajty (24 bity). Te 24 bity dzieli na cztery grupy po 6 bitów. Każda wartość 6-bitowa to indeks od 0 do 63 w 64-znakowym alfabecie. Trzy bajty wejściowe stają się więc czterema znakami wyjściowymi.
Bytes: [ byte1 ][ byte2 ][ byte3 ]
Bits: aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars: Char1 Char2 Char3 Char4Gdy pozostaje mniej niż trzy bajty, enkoder nadal emituje cztery znaki, ale dodaje dopełnienie, aby dekoder znał oryginalną długość. Przegrupowanie bitów to cały algorytm; nie ma sumy kontrolnej ani klucza.
Kodować słowo Dog krok po kroku
Słowo Dog to trzy bajty ASCII, więc wypełnia jedną grupę Base64 i koduje się bez znaków dopełnienia. Stały wynik to RG9n. Przejście bajtów przez bity, przegrupowanie na indeksy 6-bitowe i odczyt alfabetu RFC 4648 pokazuje, skąd biorą się te cztery znaki i jak każdy blok trzech bajtów idzie tą samą drogą.
1. Zapisz bajty. D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111
2. Połącz 24 bity. 01000100 01101111 01100111
3. Podziel na grupy 6-bitowe. 010001 000110 111101 100111
4. Zamień każdą grupę na indeks dziesiętny. 17, 6, 61, 39
5. Odczytaj alfabet. Indeks 17 = R, 6 = G, 61 = 9, 39 = n
Wynik: RG9n. Dekodowanie RG9n zwraca trzy oryginalne bajty i tekst Dog w UTF-8 lub ASCII.
Zrozumieć dopełnianie znakiem równości
Dopełnienie pojawia się, gdy liczba bajtów nie jest wielokrotnością trzech. Jeden pozostały bajt daje dwa znaki alfabetu i dwa znaki =. Dwa pozostałe bajty dają trzy znaki i jeden =. Stałe przykłady Do → RG8= i Dogs → RG9ncw== pokazują oba przypadki reszty obok niedopełnionego słowa trzybajtowego Dog.
| Input | Bytes | Encoded | Padding |
|---|---|---|---|
| Dog | 3 | RG9n | none |
| Do | 2 | RG8= | one = |
| Dogs | 4 | RG9ncw== | two = |
Do to dwa bajty: 01000100 01101111. Po grupowaniu 6-bitowym wystarcza bitów tylko na trzy znaczące znaki (RG8), a jeden znak dopełnienia = wypełnia czwarte miejsce. Dogs to cztery bajty: pełna grupa trzech bajtów koduje się jako RG9n, a reszta jednego bajta jako cw==. Usunięcie dopełnienia ręcznie bez dostosowania długości bitowej psuje dekodowanie; zostaw znaki = przy wklejaniu.
Odczytać alfabet Base64
RFC 4648 definiuje 64 znaki plus znak dopełnienia =. Indeksy 0 do 25 to A do Z, 26 do 51 to a do z, 52 do 61 to 0 do 9, indeks 62 to +, a indeks 63 to /.
Indeks 0 to A, a nie 0, co myli tych, którzy oczekują cyfr na początku alfabetu.
| Index range | Characters |
|---|---|
| 0 to 25 | A to Z |
| 26 to 51 | a to z |
| 52 to 61 | 0 to 9 |
| 62 | + |
| 63 | / |
| padding | = |
Panel alfabetu kalkulatora pokazuje tę samą tabelę, której używa enkoder, więc podejrzany znak można sprawdzić ze standardowym zestawem. Pełny ciąg to ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/.
Używać wariantu Base64 bezpiecznego dla URL
Alfabet bezpieczny dla URL (base64url) zamienia + na - i / na _. W niektórych protokołach dopełnienie może być pominięte. Tokeny JSON Web używają tego wariantu, aby segmenty tokena mogły siedzieć w URL i nagłówkach HTTP bez kodowania procentowego plusa i ukośnika.
Ciągi standardowe i bezpieczne dla URL nie są zamienne. Dekodowanie ładunku JWT standardowym alfabetem kończy się błędem na myślnikach. Narzędzie oferuje jawny tryb URL-safe do kodowania i dekodowania. Kodowanie procentowe URL to inny problem; użyj strony Kodowanie i dekodowanie URL, gdy celem jest ucieczka RFC 3986, a nie Base64.
Uwzględnić wzrost rozmiaru
Co trzy bajty stają się czterema znakami, więc długość zakodowana to około 4/3 wejścia, wzrost o 33 procent przed łamaniem linii. Dopełnienie może dodać jeden lub dwa znaki w ostatniej grupie. URI danych i załączniki e-mail szybko odczuwają ten koszt: obraz 300 KB staje się około 400 KB tekstu.
encoded_length ≈ 4 × ceil(byte_length / 3)Zawijanie linii co 76 znaków, powszechne w MIME, dodaje bajty nowej linii na wierzchu. Gdy rozmiar ma znaczenie, preferuj załączniki binarne lub formaty skompresowane; używaj Base64, gdy kanał naprawdę nie może nieść surowych bajtów.
Wybrać kodowanie znaków
Base64 koduje bajty, a nie abstrakcyjne znaki. Te same litery dają różne bajty w UTF-8, UTF-16, Shift JIS lub Big5. Dekodowanie z błędnym zestawem znaków daje śmieci nawet przy idealnej warstwie Base64, więc charset trybu tekstowego musi pasować do producenta przy kodowaniu i odbiorcy przy dekodowaniu.
| Charset | Typical use |
|---|---|
| UTF-8 | Default for modern text and APIs |
| Windows-1252 | Legacy Western European text |
| UTF-16 LE / BE | Some Windows and Java payloads |
| Shift JIS | Older Japanese text |
| Big5 | Older Traditional Chinese text |
Dla słowa Dog ASCII i UTF-8 dają te same trzy bajty, więc RG9n jest identyczne. Tekst spoza ASCII rozchodzi się. Wybierz charset zgodny z producentem przed kodowaniem i ten sam po dekodowaniu, inaczej pełna ścieżka wygląda jak błąd Base64, gdy pomyłka jest wyżej.
Często zadawane pytania
Czy Base64 to szyfrowanie?
Nie. Base64 to kodowanie, które każdy może odwrócić publicznym alfabetem. Nic nie ukrywa. Użyj prawdziwego algorytmu kryptograficznego, gdy potrzebna jest poufność; używaj Base64, gdy kanał potrzebuje bajtów bezpiecznych dla ASCII.
Dlaczego wynik Base64 kończy się znakami równości?
Znaki = to dopełnienie. Oznaczają, że ostatnia grupa wejściowa miała jeden lub dwa bajty zamiast trzech. Do koduje się do RG8=, a Dogs do RG9ncw==. Zachowaj dopełnienie przy dekodowaniu, chyba że protokół dokumentuje jego usunięcie.
Do czego koduje się Dog?
Dog koduje się do RG9n bez dopełnienia, bo trzy bajty dokładnie wypełniają jedną grupę Base64. Krok po kroku przegrupowanie bitów pokazano w przykładzie na tej stronie.
Jaka jest różnica między standardowym a bezpiecznym dla URL Base64?
Base64 bezpieczny dla URL używa - i _ zamiast + i /. JWT i niektóre osadzenia nazw plików używają alfabetu URL-safe. Dekodowanie złym alfabetem kończy się błędem na tych zastąpionych znakach.
O ile Base64 jest większe od oryginału?
O około jedną trzecią. Trzy bajty stają się czterema znakami, więc stosunek to 4/3 przed dopełnieniem i łamaniem linii. Ładunek 3000 bajtów staje się 4000 znakami Base64.
Czy Base64 może kodować plik, nie tylko tekst?
Tak. Tryb pliku odczytuje przesłany plik w przeglądarce i koduje jego surowe bajty. Odwrotna ścieżka dekoduje do pobieralnego bloba. Duże pliki zwiększają użycie pamięci w karcie; trzymaj przesyłki skromne.
Dlaczego zdekodowany tekst wygląda źle po poprawnym dekodowaniu?
Warstwa Base64 przywróciła bajty, ale kodowanie znaków użyte do ich interpretacji nie pasuje do producenta. Spróbuj najpierw UTF-8, potem charset faktycznie używany przez system źródłowy.
Czy to narzędzie wysyła wklejone sekrety?
Nie. Kodowanie i dekodowanie działają lokalnie. Klucze API, tokeny i fragmenty certyfikatów wklejone do pola nie trafiają na serwer. Ta obietnica jest zgodna z regułą projektową wszystkich stron kodowania w Quick Calculators.
Czy Base64 to to samo co kodowanie URL?
Nie. Base64 mapuje dane binarne na 64-znakowy alfabet do transportu. Kodowanie URL (procentowe) ucieka zarezerwowane znaki w URI według RFC 3986. Rozwiązują różne problemy i nie zastępują się nawzajem.
Które RFC definiuje alfabet?
RFC 4648 definiuje standardowe i bezpieczne dla URL alfabety Base64 oraz reguły dopełniania używane tutaj. Starsze dokumenty, takie jak RFC 2045, opisują Base64 w kontekście MIME z podobną mechaniką.
Podsumowanie
Kodowanie i dekodowanie Base64 mapuje bajty na alfabet RFC 4648 w grupach 6-bitowych i odwraca proces lokalnie w przeglądarce. Dog staje się RG9n, Do staje się RG8=, a Dogs staje się RG9ncw==, ilustrując dopełnienie dla reszty jedno- i dwubajtowej.
Alfabet bezpieczny dla URL zamienia +// na -/_, wynik rośnie o około jedną trzecią, a wybór zestawu znaków decyduje, jakie bajty tryb tekstowy podaje enkoderowi. Wklejone dane nie są przesyłane.