Por que Base64 fai os ficheiros máis grandes?

Este artigo explica por que a saída Base64 é máis grande que os bytes orixinais. Non é unha guía de seguridade. Se precisas codificación fronte a cifrado, usa Base64 non é cifrado: que fai de verdade.

Por que Base64 precisa máis espazo?

3 bytes son 24 bits. Base64 parte eses 24 bits en 4 grupos de 6 bits. Cada grupo asígnase a un carácter Base64, así que 3 bytes de entrada pasan a 4 caracteres de saída. Gardado como 1 byte por carácter ASCII, iso é 4 / 3 ≈ 1.333 — un aumento duns 33.3%.

• 3 bytes (24 bits)
• ↓
• Partir en 4 grupos de 6 bits
• Cada grupo → un carácter Base64
• ↓
• 4 caracteres (a miúdo 4 bytes de texto)

Un exemplo sinxelo e comprobábel

Estas codificacións coinciden co Base64 recheado estándar.

Man

Man

Base64

TWFu

Man son 3 bytes UTF-8/ASCII. TWFu son 4 caracteres: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello son 5 bytes. SGVsbG8= son 8 caracteres, incluído un =. En datos pequenos, o recheo fai que a porcentaxe pareza maior que 33%.

Como se calcula o tamaño de Base64?

Para Base64 recheado estándar, encodedLength = 4 × ceil(originalBytes / 3).

Bytes orixinais	Caracteres Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 ou 2 bytes seguen producindo 4 caracteres. Usa a fórmula, non un 33% fixo.

Que significa o recheo «=»?

A marca = indica que o último bloque de 3 bytes non estaba completo. 1 byte de entrada usa dous caracteres =; 2 bytes usan un; 3 bytes non usan ningún. O recheo non é cifrado nin unha función de seguridade.

Base64URL usa menos espazo?

Base64URL cambia + por - e / por _, e Codificar Base64 omite os = finais ao codificar. Iso pode acurtar a cadea neses caracteres =. A estrutura de 3 bytes → 4 caracteres mantense, así que Base64URL non é un formato binario máis eficiente en espazo.

Por que as entradas minúsculas poden medrar máis do 33%?

1 byte → 4 caracteres é un aumento do 300% en lonxitude. 2 bytes → 4 é 100%. 3 bytes → 4 é uns 33.3%. Conforme n medra, o recheo importa menos e o custo extra acércase a uns 33%. Base64 non é un 33% máis grande en todos os casos.

Por que unha Data URL Base64 é aínda máis grande?

Unha Data URL engade un prefixo como data:image/png;base64, diante da carga. Nun ficheiro minúsculo ese prefixo pode dominar a porcentaxe. Codificar Base64 pode emitir Base64 cru ou unha Data URL; a saída Data URL usa o alfabeto estándar.

Base64 fronte ao binario: cal é máis pequeno?

O binario cru é máis eficiente en espazo para transporte e almacenamento. Base64 é máis grande, mais seguro como texto en JSON, correo e outros camiños só texto. É codificación de binario a texto, non compresión.

Base64 comprime ficheiros?

Non. Base64 non é un formato de compresión. O texto codificado adoita ser máis grande que os bytes orixinais. Se despois aplicas gzip ou Brotli a ese texto, parte da redundancia pode encoller — o resultado depende dos datos e do compresor. gzip non elimina por completo o custo extra de Base64.

Que ocorre se se aplica gzip a Base64?

A compresión HTTP pode reducir algúns patróns repetidos en texto Base64. JPEG, PNG ou ZIP adoitan comprimir mal mesmo como bytes crus, e Base64-logo-gzip segue dependendo do caso. Non hai unha porcentaxe extra universal despois de gzip.

Deberías gardar ficheiros como Base64?

Base64 pode meter binario nun campo JSON, un recurso pequeno en liña, unha API só texto, copiar e pegar ou unha Data URL. En ficheiros grandes, almacenamento, memoria e tamaño de carga medran. Iso non é «nunca uses Base64 para ficheiros».

Por que Base64 é habitual nas API JSON?

JSON non ten un tipo nativo de binario cru, así que as API adoitan poñer bytes nunha cadea Base64. Para ficheiros grandes, multipart/form-data, almacenamento de obxectos ou unha subida binaria directa poden encaixar mellor. Ningunha opción é sempre a mellor.

Por que se usa Base64 no correo?

MIME pode usar Base64 para que un anexo binario viaxe como caracteres seguros para texto. O mesmo custo extra de tamaño segue a aplicar. É unha representación de transporte, non un ficheiro máis pequeno.

Cando paga a pena o tamaño extra?

O tamaño extra pode pagar a pena cando o binario debe ir dentro de texto, a carga é pequena, unha API esixe Base64 ou precisas unha Data URL. Para medios grandes, prefire binario cru cando o sistema o permite.

Cando deberías evitar Base64?

Sáltao en ficheiros grandes, ancho de banda axustado, transferencias frecuentes ou cando xa existe un camiño binario — situacional, non «Base64 é mala práctica».

Lonxitudes de Base64 recheado que podes comprobar

Contas de bytes orixinais e contas de caracteres Base64 recheado estándar:

Bytes orixinais	Caracteres Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Todas as filas seguen 4 × ceil(n / 3). Son contas de caracteres Base64.

Exemplo: de que tamaño será un ficheiro de 1,000 bytes?

4 × ceil(1000 / 3). ceil(333.333…) = 334, e 4 × 334 = 1336. Así que 1,000 bytes pasan a 1,336 caracteres Base64. Gardados como UTF-8/ASCII, cada carácter adoita ser 1 byte — non trates 1,336 como unha conta exacta de bytes en memoria.

Pode Base64 usar máis memoria da que suxire o tamaño do ficheiro?

Algúns contornos gardan cadeas con máis de 1 byte por carácter, e codificar/descodificar pode manter un búfer e unha cadea á vez. O uso de memoria non é exactamente a lonxitude en caracteres.

Unha guía sinxela para decidir polo tamaño

Se o sistema acepta binario cru, prefireo por tamaño. Se só se permite texto, Base64 pode encaixar. Para unha carga grande, busca un camiño de subida binaria. Para texto seguro en URL, considera Base64URL — a expansión de 3 a 4 mantense.

• Hai que enviar datos binarios
• ↓
• Permítese binario cru? Prefire binario por tamaño
• Campo só texto? Base64 pode ser axeitado
• Carga grande? Busca un camiño de subida binaria
• Precisas texto seguro para URL? Considera Base64URL
• ↓
• Agarda uns 33% máis de texto en entradas grandes

Codifica ou descodifica Base64 no navegador

NEXNARA Codificar Base64 codifica e descodifica texto, e pode converter un ficheiro en Base64 ou unha Data URL e devolver Base64 a un ficheiro.

O texto usa bytes UTF-8 e despois Base64 — non só ASCII. Escolle Standard ou Base64URL. A saída de ficheiro pode ser Base64 cru ou unha Data URL (alfabeto estándar). A entrada inválida rexeítase. Os bytes que non son UTF-8 precisan ir a ficheiro, non descodificarse como texto.

Os ficheiros de máis de 10 MB poden ralentizar a lapela (aviso). Os ficheiros de máis de 32 MB bloquéanse.

A codificación e a descodificación ocorren no teu navegador. O ficheiro non se envía a un servidor de NEXNARA para esta ferramenta. Os anuncios e outras funcións do sitio seguen usando a rede.

Pega texto ou un ficheiro en Codificar Base64 e compara os bytes orixinais coa lonxitude codificada.

FAQ

Por que Base64 aumenta o tamaño do ficheiro?

Mapea 3 bytes (24 bits) a 4 caracteres (4 × 6 bits). Gardado como texto, iso é arredor dun terzo máis en entradas grandes.

Base64 é sempre un 33% máis grande?

Non. As entradas grandes acércanse a uns 33.3%. As entradas minúsculas poden medrar máis polo recheo. Usa 4 × ceil(n / 3).

Canto máis grande é Base64 que o binario?

A lonxitude recheada estándar é 4 × ceil(n / 3) caracteres. Un prefixo de Data URL engade máis.

A compresión Base64 reduce o tamaño do ficheiro?

Base64 non comprime. gzip ou Brotli sobre o texto codificado poden encoller unha parte; non borra o custo extra en todos os casos.

Base64URL usa menos espazo?

Pode omitir o recheo =, así que a cadea pode ser 0–2 caracteres máis curta. A estrutura de codificación de 3 a 4 é a mesma.

Debo usar Base64 para ficheiros grandes?

Só se precisas texto. Para transferencias grandes ou frecuentes, un camiño binario adoita ser máis pequeno. Base64 non é sempre incorrecto nas API.