Cheatsheet do kodowania i dekodowania Base64: przykłady poleceń na Windows, Linux i Mac

Ta ściągawka pokazuje, jak kodować i dekodować Base64 na Windows, Linux i macOS przy użyciu certutil, PowerShell i base64, w tym z opcjami, które różnią się w zależności od systemu.

Ten poradnik jest częścią Narzędzia dla deweloperów: Kompletny przewodnik po nowoczesnych workflowach developerskich. Base64 mapuje każdą trzy bajty wejściowe na cztery znaki z zakresu A–Z, a–z, 0–9, + oraz /. Dekodowanie nie wymaga klucza: alfabet oraz znak wypełnienia = wystarczają do odzyskania oryginalnych bajtów.

Linuxowy base64 zawija wiersz po 76 znakach, chyba że ustawiona jest opcja -w 0. macOS-owy base64 zapisuje jedną linię, chyba że -b ustawia miejsce łamania. Windowsowy certutil -encode dodaje banery certyfikatów wokół zawijanych linii. Poniższe polecenia Linuxowe zostały uruchomione z GNU coreutils 9.7, uutils coreutils 0.10.0, BusyBox 1.37.0 oraz OpenSSL 3.5.5. Polecenia macOS używają opcji -i, -D i -b, udokumentowanych dla tego binarystu od OS X 10.7.

Kodowanie i dekodowanie Base64 na Windows

Windows nie dostarcza polecenia base64. Certutil i PowerShell są wbudowane.

Użycie Wiersza poleceń z Certutil

1. Otwórz Wiersz poleceń.

2. Zakoduj plik do Base64:

   certutil -encode input.bin output.b64
   

   Zamień input.bin na ścieżkę do swojego pliku, a output.b64 na pożądaną nazwę pliku wyjściowego. Plik zaczyna się od -----BEGIN CERTIFICATE-----, następnie zawartość Base64 z zawiniętymi liniami, a kończy na -----END CERTIFICATE-----.

3. Usuń linie banerów i wyświetl treść:

   certutil -encode input.bin tmp.b64 && findstr /v /c:- tmp.b64 && del tmp.b64
   

   findstr /v /c:- odrzuca każdą linię zawierającą -, co usuwa dwa banery. Treść pozostaje zawinięta. PowerShell [Convert]::ToBase64String daje wynik w jednej linii.

Dekodowanie Base64 na Windows (Certutil)

certutil -decode encoded.b64 decoded.bin

certutil -decode akceptuje plik z banerami napisany przez -encode. Akceptuje również surowy plik Base64.

Użycie PowerShell do kodowania i dekodowania

PowerShell [Convert]::ToBase64String zapisuje jedną linię i nie dodaje banerów. W celu dalszej automatyzacji shellowej, zobacz Ściągawkę PowerShell.

Kodowanie pliku:

[Convert]::ToBase64String([System.IO.File]::ReadAllBytes("C:\path\to\file.bin"))

Kodowanie ciągu znaków (UTF-8):

[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("Hello, World!"))
# Output: SGVsbG8sIFdvcmxkIQ==

Encoding.Unicode to UTF-16LE. Te same znaki kodują się wtedy jako SABlAGwAbABvACwAIABXAG8AcgBsAGQAIQA=. Linuxowy base64 dla bajtów UTF-8 generuje SGVsbG8sIFdvcmxkIQ==.

Dekodowanie Base64 do ciągu znaków:

[System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("SGVsbG8sIFdvcmxkIQ=="))
# Output: Hello, World!

Dekodowanie Base64 do pliku:

[System.IO.File]::WriteAllBytes("decoded.bin", [Convert]::FromBase64String((Get-Content encoded.b64 -Raw)))

FromBase64String akceptuje spacje, tabulacje i znaki nowego wiersza. Rzuca wyjątek na banerze BEGIN CERTIFICATE, więc plik certutil musi przejść przez certutil -decode (lub banery muszą zostać wcześniej usunięte).

Kodowanie i dekodowanie Base64 na Linux

base64 --version podaje nazwę binarystu w PATH. Linia zaczynająca się od base64 (GNU coreutils) oznacza GNU. Na Ubuntu 25.10 i 26.04 /usr/bin/base64 to uutils z rust-coreutils; pakiet 26.04 sprawdzony tutaj to uutils coreutils 0.10.0. GNU coreutils 9.7 to gnubase64 z pakietu gnu-coreutils.

Oba akceptują argument pozycyjny pliku, -d / --decode, -i / --ignore-garbage oraz -w / --wrap. Domyślne zawijanie to 76 znaków. -w 0 je wyłącza. uutils 0.10.0 traktuje również -D jako alias -d. GNU coreutils 9.7 kończy działanie z komunikatem invalid option -- 'D' na -D.

Pipe’y i cytowanie dla tych jednowierszowców są omówione w Ściągawce Bash.

Kodowanie pliku do Base64

base64 input_file > output_file

Przykład:

base64 myfile.txt > encoded.txt

Aby wyświetlić zakodowaną zawartość na terminalu:

base64 myfile.txt

Kodowanie ciągu znaków do Base64

printf '%s' 'Hello, World!' | base64 -w 0
# Output: SGVsbG8sIFdvcmxkIQ==

printf '%s' zapisuje podane bajty i się zatrzymuje. echo bez -n dołącza znak nowego wiersza, więc ten sam tekst koduje się jako SGVsbG8sIFdvcmxkIQo=. W bash, echo -n "Hello, World!" | base64 -w 0 odpowiada linii z printf. echo -n nie jest przenośne na każdy sh.

Wyłączanie zawijania linii (-w 0)

GNU i uutils zawijają po 76 znakach, również gdy stdout to plik lub pipe. JSON, zmienne środowiskowe, URL-e oraz wartość data w Kubernetes wymagają jednej linii. base64encode() Terraform zwraca jedną linię standardowego Base64, więc wyjście CLI porównywane z nim musi być generowane z wyłączonym zawijaniem:

base64 -w 0 input_file > output_file

Dekodowanie Base64 na Linux

base64 -d encoded_file > decoded_file
# lub
base64 --decode encoded_file > decoded_file

Przykład:

printf '%s' 'SGVsbG8sIFdvcmxkIQ==' | base64 -d
# Output: Hello, World!

GNU coreutils od 9.5 oraz uutils 0.10.0 dekodują standardowy Base64 bez znaku wypełnienia =. printf '%s' 'SGVsbG8' | base64 -d wypisuje Hello. Kodery nadal emitują wypełnienie. Starsze GNU base64 odrzucały wejście bez wypełnienia.

-i / --ignore-garbage pomija znaki spoza alfabetu podczas dekodowania. Znaki nowego wiersza są już dozwolone. Spacje nie są, chyba że ustawione jest -i:

printf '%s' 'SGVs bG8=' | base64 -di
# Output: Hello

Na GNU i uutils, -i nie przyjmuje nazwy pliku. base64 -i input_file koduje input_file, ponieważ nazwa jest argumentem pozycyjnym, a -i zmienia tylko dekodowanie. Na macOS -i to opcja pliku wejściowego.

OpenSSL

OpenSSL 3.5.5 zawija po 64 znakach. -A trzyma wyjście w jednej linii:

printf '%s' 'data' | openssl base64 -e -A
# Output: ZGF0YQ==
printf '%s' 'ZGF0YQ==' | openssl base64 -d -A
# Output: data

Bez -A, długi bufor jest łamany co 64 znaki, co to inna szerokość niż w GNU base64.

BusyBox

BusyBox 1.37.0 akceptuje -d i -w COL (domyślnie 76, 0 wyłącza zawijanie). --decode zawodzi z komunikatem unrecognized option '--decode', a -D zawodzi z invalid option -- 'D'. Dekodowanie już pomija znaki spoza alfabetu: printf '%s' 'SGVs!bG8=' | busybox base64 -d wypisuje Hello. -i jest akceptowane, ale nie pojawia się w linii pomocy.

Kodowanie i dekodowanie Base64 na macOS

macOS dostarcza BSD base64. Nazwa pliku jest przekazywana z -i. Redystrybucja stdin działa bez -i: base64 < input_file.

Kodowanie pliku do Base64

base64 -i input_file > output_file

Przykład:

base64 -i myfile.txt > encoded.txt

Aby wyświetlić na terminalu:

base64 -i myfile.txt

Domyślny interwał łamania to 0, więc zakodowany tekst to jedna linia. -b count wstawia znak nowego wiersza co count znaków. base64 -w 0 to opcja Linux; binaryst macOS jej nie używa. base64 -b 0 -i input_file to jawna forma jednej linii.

Kodowanie i kopiowanie do schowka

base64 -i input_file | pbcopy

Dekodowanie Base64 na Mac

base64 -D -i encoded_file > decoded_file

-D to dekodowanie. Te opcje -i i -D są interfejsem macOS od OS X 10.7. Skrypt Linuxowy wywołujący base64 -d powinien wywoływać base64 -D na macOS.

Opcje wg implementacji

RFC 4648 unieważnia RFC 3548. Standardowy alfabet w obu dokumentach to A–Z, a–z, 0–9, +, /.

base64 -i file koduje na Linux, ponieważ -i jest tam booleanem, a file to operand pozycyjny. To samo polecenie na macOS też koduje, ponieważ -i konsumuje file jako ścieżkę wejściową. base64 -D -i file dekoduje na macOS i na uutils 0.10.0.

Base64url dla JWT

Segmnty nagłówka i payloadu JWT używają base64url (sekcja 5 RFC 4648): - i _ zastępują + i /, a wypełnienie = jest zazwyczaj pomijane. Standardowe base64 -d wtedy zawodzi. Na uutils 0.10.0 błędem jest invalid input.

GNU basenc (oraz gnubasenc na Ubuntu 26.04) akceptuje formę bez wypełnienia:

printf '%s' 'aGVsbG8_Ky93b3JsZA' | gnubasenc --base64url -d
# Output: hello?+/world

uutils 0.10.0 basenc --base64url -d wymaga przywrócenia wypełnienia do wielokrotności 4. Ten sam segment z dodanym == dekoduje się poprawnie. Koduj i usuń wypełnienie dla tokena w stylu JWT:

printf '%s' 'hello?+/world' | basenc --base64url -w 0 | tr -d '='
# Output: aGVsbG8_Ky93b3JsZA

jq dekoduje segmenty JWT przez @base64d, co jest ścieżką w Dekodowanie i wyświetlanie tokena JWT.

PowerShell może zbudować ten sam alfabet:

$b = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello?+/world"))
$b.TrimEnd("=").Replace("+","-").Replace("/","_")

Częste przypadki użycia

kubectl create secret sam koduje do Base64 wartości z --from-literal i --from-file. Prefiksowanie wartości base64 -w 0, jak w --from-literal=key=$(base64 -w 0 file.bin), przechowuje drugie kodowanie, a późniejsze base64 -d zwraca nadal Base64. Ściągawka Kubernetes używa formy jawnej, --from-literal=username=admin.

W manifeście każda wartość data jest już jedną linią standardowego Base64, a stringData przechowuje surowy ciąg znaków. Serwer API scala stringData z data. Kubernetes dokumentuje, że stringData nie działa dobrze z server-side apply. Obiekt to zakodowany tekst; etcd przechowuje go nieszyfrowany, chyba że włączona jest szyfrowanie danych w spoczynku.

curl -u zapisuje nagłówek Authorization: Basic. Budowanie tego nagłówka z user:pass jest omówione w Ściągawce cURL.

Kiedy dekodowanie zawodzi

base64 --version to sprawdzian, gdy -D lub -w zachowują się niepoprawnie. Linia GNU i linia uutils są różne, a -D na Linux odpowiada linii uutils.

Zdekodowana wartość kończąca się pustą linią zawiera znak nowego wiersza z echo. Zakoduj ponownie to wejście z printf '%s'.

base64 file | wc -l wypisuje, ile zawiniętych linii wyemitował koder. Liczba powyżej 1 na Linux oznacza, że polecenie zostało uruchomione bez -w 0.

invalid input na tekście zawierającym - lub _ to alfabet base64url, typowy dla segmentu JWT. Zdekoduj go przez basenc --base64url, a na uutils 0.10.0 dołącz = aż długość będzie wielokrotnością 4.