Зошто Base64 ги зголемува датотеките?

Оваа статија објаснува зошто излезот Base64 е поголем од оригиналните бајти. Не е водич за безбедност. Ако ви треба кодирање наспроти шифрирање, користете Base64 не е шифрирање: што навистина прави.

Зошто Base64 му треба повеќе простор?

3 бајти се 24 бита. Base64 ги дели тие 24 бита во 4 групи од 6 бита. Секоја група се мапира на еден знак Base64, па 3 влезни бајти стануваат 4 излезни знаци. Зачувано како 1 бајт по ASCII знак, тоа е 4 / 3 ≈ 1.333 — зголемување од околу 33.3%.

• 3 бајти (24 бита)
• ↓
• Поделба во 4 групи од 6 бита
• Секоја група → еден знак Base64
• ↓
• 4 знаци (често 4 бајти текст)

Едноставен, проверлив пример

Овие кодирања се совпаѓаат со стандарден Base64 со дополнување.

Man

Man

Base64

TWFu

Man е 3 бајти UTF-8/ASCII. TWFu е 4 знаци: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello е 5 бајти. SGVsbG8= е 8 знаци, вклучувајќи едно =. Кај мали податоци, дополнувањето прави процентот да изгледа поголем од 33%.

Како се пресметува големината на Base64?

За стандарден Base64 со дополнување, encodedLength = 4 × ceil(originalBytes / 3).

Оригинални бајти	Знаци Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 или 2 бајти сепак даваат 4 знаци. Користете ја формулата, не фиксни 33%.

Што значи дополнувањето «=»?

Ознаката = покажува дека последниот блок од 3 бајти не бил полн. 1 влезен бајт користи два знака =; 2 бајти користат еден; 3 бајти не користат ниеден. Дополнувањето не е шифрирање ниту безбедносна функција.

Дали Base64URL користи помалку простор?

Base64URL го менува + во - и / во _, а Кодирање Base64 ги изоставува завршните = при кодирање. Тоа може да го скрати низата за тие знаци =. Структурата 3 бајти → 4 знаци останува иста, па Base64URL не е бинарен формат поефикасен по простор.

Зошто ситните влезови можат да пораснат повеќе од 33%?

1 бајт → 4 знаци е зголемување на должината од 300%. 2 бајти → 4 е 100%. 3 бајти → 4 е околу 33.3%. Како n расте, дополнувањето помалку влијае и трошокот се приближува кон околу 33%. Base64 не е секогаш точно 33% поголем.

Зошто Base64 Data URL е уште поголем?

Data URL додава префикс како data:image/png;base64, пред товарот. Кај ситна датотека тој префикс може да го доминира процентот. Кодирање Base64 може да издаде суров Base64 или Data URL; излезот Data URL ја користи стандардната азбука.

Base64 наспроти бинарно: што е помало?

Суровите бинарни податоци се поефикасни по простор за пренос и чување. Base64 е поголем, но безбеден како текст во JSON, е-пошта и други патишта само за текст. Тоа е кодирање од бинарно во текст, не компресија.

Дали Base64 компресира датотеки?

Не. Base64 не е формат за компресија. Кодираниот текст обично е поголем од оригиналните бајти. Ако потоа примените gzip или Brotli на тој текст, дел од вишокот може да се намали — резултатот зависи од податоците и компресорот. gzip не го отстранува целосно трошокот на Base64.

Што се случува ако Base64 се компресира со gzip?

HTTP компресијата може да намали некои повторени обрасци во текстот Base64. JPEG, PNG или ZIP често се компресираат лошо дури и како сурови бајти, а Base64-потоа-gzip сè уште зависи од случајот. Нема универзален дополнителен процент после gzip.

Дали треба да чувате датотеки како Base64?

Base64 може да стави бинарно во JSON поле, мал вграден ресурс, API само за текст, копирање/лепење или Data URL. За големи датотеки растат складиштето, меморијата и големината на товарот. Тоа не е «никогаш не користете Base64 за датотеки».

Зошто Base64 е чест во JSON API?

JSON нема нативен тип на сурови бинарни податоци, па API често ги ставаат бајтите во Base64 низа. За големи датотеки подобро можат да одговараат multipart/form-data, складиште на објекти или директно бинарно поставување. Ниеден избор не е секогаш најдобар.

Зошто се користи Base64 во е-пошта?

MIME може да користи Base64 за бинарниот прилог да патува како знаци безбедни за текст. Истиот трошок на големина сè уште важи. Тоа е транспортна претстава, не помала датотека.

Кога дополнителната големина вреди?

Дополнителната големина може да вреди кога бинарното мора да седи внатре во текст, товарот е мал, API бара Base64 или ви треба Data URL. За големи медиуми претпочитајте сурови бинарни податоци кога системот тоа дозволува.

Кога треба да го избегнувате Base64?

Прескокнете го за големи датотеки, тесен опсег, чести преноси или кога веќе постои бинарен пат — ситуациски, не «Base64 е лоша практика».

Должини на Base64 со дополнување што можете да ги проверите

Број на оригинални бајти и број на знаци на стандарден Base64 со дополнување:

Оригинални бајти	Знаци Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Сите редови следат 4 × ceil(n / 3). Тоа се броеви на знаци Base64.

Пример: колку ќе порасне датотека од 1,000 бајти?

4 × ceil(1000 / 3). ceil(333.333…) = 334, и 4 × 334 = 1336. Значи 1,000 бајти стануваат 1,336 знаци Base64. Зачувано како UTF-8/ASCII, секој знак обично е 1 бајт — не третирајте 1,336 како точен број бајти во меморија.

Може ли Base64 да користи повеќе меморија отколку што сугерира големината на датотеката?

Некои околини ги чуваат низите со повеќе од 1 бајт по знак, а кодирањето/декодирањето може да држи бафер и низа заедно. Употребата на меморија не е точно должината во знаци.

Едноставен водич за одлука за големина

Ако системот прима сурови бинарни податоци, претпочитајте ги поради големина. Ако е дозволен само текст, Base64 може да одговара. За голем товар побарајте пат за бинарно поставување. За текст безбеден во URL, разгледајте Base64URL — проширувањето 3-на-4 останува.

• Треба да се испратат бинарни податоци
• ↓
• Сурови бинарни податоци дозволени? Претпочитај бинарно поради големина
• Поле само за текст? Base64 може да одговара
• Голем товар? Побарај пат за бинарно поставување
• Треба текст безбеден за URL? Разгледај Base64URL
• ↓
• Кај големи влезови очекувајте околу 33% повеќе текст

Кодирајте или декодирајте Base64 во прелистувачот

NEXNARA Кодирање Base64 кодира и декодира текст, и може да претвори датотека во Base64 или Data URL и да го врати Base64 назад во датотека.

Текстот оди со бајти UTF-8, потоа Base64 — не само ASCII. Изберете Standard или Base64URL. Излезот на датотека може да биде суров Base64 или Data URL (стандардна азбука). Невалиден влез се одбива. Бајти што не се UTF-8 треба во датотека, не во текстуално декодирање.

Датотеки над 10 MB можат да го забават јазичето (предупредување). Датотеки над 32 MB се блокираат.

Кодирањето и декодирањето се случуваат во вашиот прелистувач. Датотеката не се испраќа на сервер на NEXNARA за оваа алатка. Рекламите и другите функции на сајтот сè уште ја користат мрежата.

Залепете текст или датотека во Кодирање Base64 и споредете ги оригиналните бајти со кодираната должина.

FAQ

Зошто Base64 ја зголемува големината на датотеката?

Мапира 3 бајти (24 бита) на 4 знаци (4 × 6 бита). Зачувано како текст, тоа е околу една третина повеќе за големи влезови.

Дали Base64 е секогаш 33% поголем?

Не. Големите влезови се приближуваат кон околу 33.3%. Ситните влезови можат да пораснат повеќе поради дополнувањето. Користете 4 × ceil(n / 3).

Колку е Base64 поголем од бинарното?

Стандардната должина со дополнување е 4 × ceil(n / 3) знаци. Префиксот Data URL додава уште.

Дали компресијата Base64 ја намалува големината на датотеката?

Base64 не компресира. gzip или Brotli на кодираниот текст можат да намалат дел; не го бришат трошокот во секој случај.

Дали Base64URL користи помалку простор?

Може да го изостави дополнувањето =, па низата може да биде пократка за 0–2 знака. Структурата на кодирање 3-на-4 е иста.

Дали треба да користам Base64 за големи датотеки?

Само ако ви треба текст. За големи или чести преноси бинарниот пат често е помал. Base64 не е секогаш погрешен за API.