Размер Base64 данных: формула и онлайн-расчёт

Base64 — это способ кодирования бинарных данных (изображения, PDF, архивы) в строку ASCII. Алгоритм берёт 3 байта (24 бита) и делит их на четыре 6-битных блока, каждый отображается в один из 64 символов (A-Z, a-z, 0-9, +, /). Из-за этого длина закодированной строки всегда кратна 4, а в конце могут добавляться символы '=' для выравнивания.

Знание точного размера необходимо, чтобы:

• Оценить объём передаваемых данных через API или WebSocket;
• Не превысить лимит поля в базе данных (например, VARCHAR в MySQL);
• Рассчитать время загрузки;
• Оптимизировать место в хранилище, если храните строки Base64.

На практике размер строки Base64 можно быстро прикинуть через Калькулятор размера Base64 данных.

Пусть n — число исходных байт. Тогда длина Base64 строки (в символах) без учёта выравнивания равна ceil(n / 3) * 4. С учётом паддинга:

Упрощённая формула для прикидки: размер Base64 ≈ исходные_байты * 1.37 (коэффициент 137%). Точнее:

• Если n % 3 == 0: Длина = 4 * (n / 3)
• Если n % 3 == 1: Длина = 4 * (n / 3) + 4 (на самом деле ceil(n/3)*4 = 4*((n+2)/3) = 4 * (n/3 + 1) = 4n/3 + 4)
• Если n % 3 == 2: Длина = 4 * (n / 3) + 2

Пример 1: Исходное изображение 1024 байта (1 КБ). n=1024, 1024 % 3 = 1. Ceil(1024/3)=342 (целочисленно: 341 + 1). Длина = 342 * 4 = 1368 символов + 4 символа паддинга? Нет, разберём: ceil(1024/3) = 342 (так как 1024/3 = 341.333, округление вверх до 342). Длина без паддинга = 342 * 4 = 1368. Остаток 1 даёт 4 символа паддинга? Фактически паддинг добавляется одним знаком '=', но по правилам для остатка 1 требуется 2 знака '=' (на деле 1 символ '='). Следуя стандарту: если остаток 1, добавляется 2 символа '=', итого длина = 1368 + 2 = 1370. Но формула из RFC: длина кратна 4. 1368 уже кратно 4 (1368/4=342), но из-за остатка 1 кодирование добавит два символа '=', итого 1370. Перепроверим: для 1 байта (n=1) исходная строка 'AA==', длина 4. Для 1024 байт: количество групп по 3 байта = 341 (1023 байт) + 1 байт отдельно. Итог: 341*4 + 4 = 1364 + 4 = 1368? Нет, 341*4=1364, плюс ещё 4 символа для последнего неполного блока, итого 1368. Паддинг: для 1 оставшегося байта добавляется 2 символа '=', значит длина 1368+2=1370. Но обычно считают как ceil(n/3)*4. Для n=1 ceil(1/3)=1 => длина = 4. Для n=1024 ceil(1024/3)=342 => длина = 342*4=1368. Противоречие? На самом деле формула ceil(n/3)*4 выдаёт длину до паддинга? Нет, она выдаёт полную длину с паддингом, но для n=1024 остаток 1, и ceil=342, 342*4=1368, но у нас 4 байта на неполный блок, так что 1368 — это уже с паддингом? Не сходится. Следуйте RFC: длина кратна 4, и для остатка 1 паддинг составляет 2 символа. Итоговая длина = floor(n/3)*4 + (n%3==0?0:4). Для n=1: floor=0, n%3=1 => +4 = 4. Для n=1024: floor=341, n%3=1 => +4 = 1364+4=1368? 341*4=1364, +4=1368. Да, 1368. А паддинг? У нас уже включены 4 символа в неполный блок, из них 2 — данные, 2 — паддинг. Так что формула floor(n/3)*4 + (n%3==0?0:4) верна и даёт 1368. Зачем я ранее написал паддинг отдельно? Забудьте. Правильная простая формула: Длина = 4 * ceil(n/3). Для n=1024: ceil(341.333)=342, 342*4=1368. Так и есть. Для n=1: ceil(0.333)=1, 1*4=4. Для n=2: ceil(0.666)=1, 1*4=4 (фактически 'AA=='). Для n=3: ceil(1)=1, 1*4=4. Для n=4: ceil(1.333)=2, 2*4=8. Итог: Длина = 4 * ceil(исходные_байты/3). Никаких дополнительных паддингов. Так что не путайтесь.

Пример 2: PDF размером 5 МБ (5 242 880 байт). Длина = 4 * ceil(5242880/3) = 4 * 1747627 = 6 990 508 символов ≈ 6,99 МБ (если считать 1 символ = 1 байт). В памяти строка займёт ~6,99 МБ.

Для проверки используйте Калькулятор размера Base64 данных.

Python:

import base64, math

def base64_length(byte_size):
    return 4 * math.ceil(byte_size / 3)

# Пример: 1 КБ
print(base64_length(1024))  # 1368

JavaScript:

function base64Length(byteSize) {
  return 4 * Math.ceil(byteSize / 3);
}
console.log(base64Length(1024)); // 1368

PHP:

function base64Length($bytes) {
  return 4 * ceil($bytes / 3);
}
echo base64Length(1024); // 1368

Эти функции считают длину строки в символах; для перевода в байты (в памяти строка занимает столько же байт, сколько символов, если кодировка ASCII, но в Python 3 каждый символ — один Unicode code point, однако в памяти для ASCII может занимать 1 байт). На практике считайте, что размер строки в байтах равен длине строки, если она не содержит многобайтовые символы (Base64 использует только ASCII).

Ошибка 1: Путать размер строки с размером декодированных данных. При расчёте трафика нужно учитывать именно размер Base64 строки (если передаёте её по сети).
Ошибка 2: Считать, что размер строки равен размеру файла * 1.33. В реальности из-за паддинга может быть немного больше.
Ошибка 3: Забывать, что в URL-safe Base64 символы '+' и '/' заменяются на '-' и '_', что не меняет длину.
Ошибка 4: Использовать strlen на бинарных данных в PHP, что даёт неверный размер. Всегда используйте strlen(base64_encode($binary)) для проверки.

Чтобы избежать ошибок, используйте Base64 в PDF или PDF в Base64 для прямого конвертирования с автоматическим расчётом размера.

Если известна длина Base64 строки (без пробелов), то исходный размер вычисляется обратно: floor(длина * 3/4). Но нужно учитывать паддинг: на каждый символ '=' (их 0, 1 или 2) вычитается один байт из результата.

Например, строка длиной 1368 символов, из них 2 символа '=': исходный размер = floor(1368*3/4) - 2 = floor(1026) - 2 = 1024 байта.

Для обратной конвертации удобны инструменты: Конвертер PNG в Base64 и Конвертер JPG в Base64.

Base64 неэффективен для хранения: занимает на 33% больше места, чем исходный файл. Если нужно часто передавать файлы, лучше передавать их бинарно. Однако для встраивания в HTML/CSS (data URI) Base64 удобен. Чтобы сэкономить, можно:

• Сжимать файлы до кодирования (например, используйте gzip для текста или оптимизацию изображений);
• Если строка будет часто использоваться, кешировать её;
• Для больших файлов (>10 МБ) избегать Base64, использовать загрузку бинарными данными.