Dlaczego Base64 powiększa pliki?

Ten artykuł wyjaśnia, dlaczego wyjście Base64 jest większe niż oryginalne bajty. To nie jest przewodnik po bezpieczeństwie. Jeśli potrzebujesz kodowania kontra szyfrowania, użyj Base64 to nie szyfrowanie: co naprawdę robi i jak dekodować.

Dlaczego Base64 potrzebuje więcej miejsca?

3 bajty to 24 bity. Base64 dzieli te 24 bity na 4 grupy po 6 bitów. Każda grupa mapuje się na jeden znak Base64, więc 3 bajty wejścia stają się 4 znakami wyjścia. Zapisane jako 1 bajt na znak ASCII to 4 / 3 ≈ 1.333 — wzrost o około 33.3%.

• 3 bajty (24 bity)
• ↓
• Podział na 4 grupy po 6 bitów
• Każda grupa → jeden znak Base64
• ↓
• 4 znaki (często 4 bajty tekstu)

Prosty, sprawdzalny przykład

Te kodowania zgadzają się ze standardowym Base64 z dopełnieniem.

Man

Man

Base64

TWFu

Man to 3 bajty UTF-8/ASCII. TWFu to 4 znaki: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello to 5 bajtów. SGVsbG8= to 8 znaków, w tym jeden =. Przy małych danych dopełnienie sprawia, że odsetek wygląda na większy niż 33%.

Jak obliczyć rozmiar Base64?

Dla standardowego Base64 z dopełnieniem encodedLength = 4 × ceil(originalBytes / 3).

Oryginalne bajty	Znaki Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 lub 2 bajty i tak dają 4 znaki. Użyj wzoru, nie stałego 33%.

Co oznacza dopełnienie „=”?

Znak = pokazuje, że ostatni blok 3 bajtów nie był pełny. 1 bajt wejścia używa dwóch znaków =; 2 bajty jednego; 3 bajty żadnego. Dopełnienie to nie szyfrowanie ani funkcja bezpieczeństwa.

Czy Base64URL zajmuje mniej miejsca?

Base64URL zmienia + na - i / na _, a Koduj i dekoduj Base64 pomija końcowe = przy kodowaniu. To może skrócić łańcuch o te znaki =. Struktura 3 bajty → 4 znaki zostaje, więc Base64URL to nie bardziej oszczędny format binarny.

Dlaczego malutkie wejścia mogą urosnąć o więcej niż 33%?

1 bajt → 4 znaki to wzrost długości o 300%. 2 bajty → 4 to 100%. 3 bajty → 4 to około 33.3%. Gdy n rośnie, dopełnienie ma mniejsze znaczenie, a koszt extra zbliża się do około 33%. Base64 nie jest w każdym przypadku o 33% większe.

Dlaczego Data URL Base64 jest jeszcze większy?

Data URL dodaje prefiks taki jak data:image/png;base64, przed ładunkiem. Przy malutkim pliku ten prefiks może zdominować odsetek. Koduj i dekoduj Base64 może wydać surowe Base64 albo Data URL; wyjście Data URL używa standardowego alfabetu.

Base64 kontra dane binarne: co jest mniejsze?

Surowe dane binarne są oszczędniejsze miejscem przy transporcie i przechowywaniu. Base64 jest większe, ale bezpieczne jako tekst w JSON, e-mailu i innych ścieżkach tylko tekstowych. To kodowanie z binariów na tekst, nie kompresja.

Czy Base64 kompresuje pliki?

Nie. Base64 to nie format kompresji. Zakodowany tekst zwykle jest większy niż oryginalne bajty. Jeśli potem zastosujesz gzip lub Brotli na tym tekście, część nadmiaru może się skurczyć — wynik zależy od danych i kompresora. gzip nie usuwa całkowicie kosztu extra Base64.

Co się dzieje, gdy Base64 dostanie gzip?

Kompresja HTTP może zmniejszyć niektóre powtarzane wzorce w tekście Base64. JPEG, PNG lub ZIP często kompresują się słabo nawet jako surowe bajty, a Base64-potem-gzip nadal zależy od przypadku. Nie ma uniwersalnego dodatkowego odsetka po gzip.

Czy przechowywać pliki jako Base64?

Base64 może zmieścić dane binarne w polu JSON, małym zasobie w linii, API tylko tekstowym, kopiuj/wklej albo Data URL. Przy dużych plikach rosną przechowywanie, pamięć i rozmiar ładunku. To nie znaczy „nigdy nie używaj Base64 do plików”.

Dlaczego Base64 jest częste w API JSON?

JSON nie ma natywnego typu surowych binariów, więc API często kładą bajty w łańcuchu Base64. Dla dużych plików lepiej mogą pasować multipart/form-data, magazyn obiektów albo bezpośrednie wgranie binarne. Żaden wybór nie jest zawsze najlepszy.

Dlaczego Base64 jest używane w e-mailu?

MIME może użyć Base64, żeby załącznik binarny podróżował jako znaki bezpieczne dla tekstu. Ten sam koszt extra rozmiaru nadal obowiązuje. To reprezentacja transportowa, nie mniejszy plik.

Kiedy dodatkowy rozmiar ma sens?

Dodatkowy rozmiar może mieć sens, gdy dane binarne muszą siedzieć w tekście, ładunek jest mały, API wymaga Base64 albo potrzebujesz Data URL. Przy dużych mediach preferuj surowe dane binarne, gdy system na to pozwala.

Kiedy unikać Base64?

Pomiń je przy dużych plikach, ciasnym paśmie, częstych transferach albo gdy ścieżka binarna już istnieje — sytuacyjnie, nie „Base64 to zła praktyka”.

Długości Base64 z dopełnieniem do sprawdzenia

Liczby oryginalnych bajtów i liczby znaków standardowego Base64 z dopełnieniem:

Oryginalne bajty	Znaki Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Wszystkie wiersze idą według 4 × ceil(n / 3). To liczby znaków Base64.

Przykład: jak duży będzie plik 1,000 bajtów?

4 × ceil(1000 / 3). ceil(333.333…) = 334, a 4 × 334 = 1336. Zatem 1,000 bajtów staje się 1,336 znakami Base64. Zapisane jako UTF-8/ASCII każdy znak to zwykle 1 bajt — nie traktuj 1,336 jako dokładnej liczby bajtów w pamięci.

Czy Base64 może używać więcej pamięci, niż sugeruje rozmiar pliku?

Niektóre środowiska trzymają łańcuchy z więcej niż 1 bajtem na znak, a kodowanie/dekodowanie może trzymać bufor i łańcuch naraz. Zużycie pamięci nie jest dokładnie długością w znakach.

Prosty przewodnik decyzji według rozmiaru

Jeśli system przyjmuje surowe dane binarne, preferuj je ze względu na rozmiar. Jeśli dozwolony jest tylko tekst, Base64 może pasować. Przy dużym ładunku sprawdź ścieżkę wgrania binarnego. Dla tekstu bezpiecznego w URL rozważ Base64URL — rozszerzenie 3 do 4 zostaje.

• Trzeba wysłać dane binarne
• ↓
• Surowe dane binarne dozwolone? Preferuj dane binarne ze względu na rozmiar
• Pole tylko tekstowe? Base64 może być odpowiednie
• Duży ładunek? Sprawdź ścieżkę wgrania binarnego
• Potrzebny tekst bezpieczny dla URL? Rozważ Base64URL
• ↓
• Przy dużych wejściach spodziewaj się około 33% więcej tekstu

Koduj lub dekoduj Base64 w przeglądarce

NEXNARA Koduj i dekoduj Base64 koduje i dekoduje tekst oraz może zamienić plik na Base64 albo Data URL i zwrócić Base64 z powrotem do pliku.

Tekst używa bajtów UTF-8, potem Base64 — nie tylko ASCII. Wybierz Standard albo Base64URL. Wyjście pliku może być surowym Base64 albo Data URL (standardowy alfabet). Nieprawidłowe wejście jest odrzucane. Bajty inne niż UTF-8 muszą iść do pliku, nie do dekodowania tekstu.

Pliki powyżej 10 MB mogą spowolnić kartę (ostrzeżenie). Pliki powyżej 32 MB są blokowane.

Kodowanie i dekodowanie dzieją się w Twojej przeglądarce. Plik nie jest wysyłany na serwer NEXNARA przy tym narzędziu. Reklamy i inne funkcje witryny nadal używają sieci.

Wklej tekst albo plik w Koduj i dekoduj Base64 i porównaj oryginalne bajty z długością po kodowaniu.

FAQ

Dlaczego Base64 zwiększa rozmiar pliku?

Mapuje 3 bajty (24 bity) na 4 znaki (4 × 6 bitów). Zapisane jako tekst to około jednej trzeciej więcej przy dużych wejściach.

Czy Base64 zawsze jest o 33% większe?

Nie. Duże wejścia zbliżają się do około 33.3%. Malutkie wejścia mogą urosnąć bardziej przez dopełnienie. Użyj 4 × ceil(n / 3).

O ile Base64 jest większe od binariów?

Standardowa długość z dopełnieniem to 4 × ceil(n / 3) znaków. Prefiks Data URL dodaje jeszcze więcej.

Czy kompresja Base64 zmniejsza rozmiar pliku?

Base64 nie kompresuje. gzip lub Brotli na zakodowanym tekście mogą skurczyć część; nie usuwają kosztu extra w każdym przypadku.

Czy Base64URL zajmuje mniej miejsca?

Może pominąć dopełnienie =, więc łańcuch może być krótszy o 0–2 znaki. Struktura kodowania 3 do 4 jest ta sama.

Czy używać Base64 do dużych plików?

Tylko jeśli potrzebujesz tekstu. Przy dużych lub częstych transferach ścieżka binarna bywa mniejsza. Base64 nie zawsze jest złe w API.