Защо 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.