Herramientas de desarrollo · Codificador y decodificador Base64
¿Cuánto más grande hace Base64 sus datos? La sobrecarga 4/3 funcionó
· Cómo funciona
base64 codificación rendimiento
La salida de Base64 es aproximadamente un tercio más grande que su entrada, además de relleno y posiblemente saltos de línea. Esta publicación deriva la fórmula exacta y la aplica a tamaños realistas para que puedas juzgar el costo.
El ícono 30 KB que se convirtió en 40 KB en el paquete: un salto de tamaño concreto que sorprendió en una revisión de compilación
Un ícono 30 KB insertado como Base64 en un archivo CSS se convierte en 40 KB, y surge la pregunta de revisión de la compilación: ¿de dónde vino el 10 KB adicional? El factor de expansión para Base64 es siempre 4/3: cada tres bytes de entrada producen cuatro bytes de salida (cuatro caracteres). Para la entrada 30 KB (30,000 bytes), divida por tres para obtener 10,000 grupos, multiplique por cuatro para obtener 40,000 bytes de salida.
Las matemáticas son deterministas e inevitables: Base64 no es un formato de compresión. Si incorporar activos cuesta un 33% más de ancho de banda y la página se carga más rápido debido a una solicitud HTTP menos, esa es una compensación que vale la pena medir. Si cuesta un 33% más y se carga más lento, no valía la pena insertarlo. La relación 4/3 proviene del diseño de bits. Tres bytes son 24 bits; cuatro caracteres Base64 llevan 24 bits (cada uno lleva seis bits).
Por qué 4/3 es el mínimo: seis bits por carácter frente a ocho por byte, y de dónde proviene la sobrecarga restante
Hasta ahora, la proporción es 1:1. Pero los caracteres Base64 son texto (ASCII 0–127), y el carácter ASCII promedio en codificación UTF-8 o Latin-1 es de un byte. Entonces, cuatro caracteres Base64 son cuatro bytes de salida para tres bytes de entrada, proporción de 4/3.. Esto no es universal: si Base64 se emitiera en formato binario (un byte por carácter, empaquetado en seis bits), la proporción sería 3/4 (compresión).
Debido a que Base64 está diseñado para el transporte de texto, utiliza caracteres de texto y el costo es un 33% de aumento de tamaño. El relleno añade un pequeño margen al final. Si la longitud de entrada es múltiplo de tres, no se necesita relleno. Si la longitud de entrada es 1 mod 3 (un byte menos que múltiple), se agregan dos caracteres de relleno, lo que aumenta la salida en 2. Si 2 mod 3, se agrega un carácter de relleno =, aumentando en 1.
La fórmula exacta con relleno: ceil(n/3) × 4 caracteres y el efecto para entradas de 1, 2 y 3 bytes
Para entradas grandes, el margen es insignificante: la entrada de 300-byte necesita 400 caracteres más como máximo dos caracteres de relleno, una diferencia inferior al 0.5%. Para entradas pequeñas (1–3 bytes), domina el relleno: un byte produce YQ== (cuatro caracteres), expansión 4x. Pero el promedio entre archivos está dominado por los más grandes. La fórmula exacta es ceil(n / 3) × 4 caracteres, donde n es el recuento de bytes de entrada.
Para n = 1, ceil(1/3) × 4 = 1 × 4 = 4. Para n = 2, techo(2/3) × 4 = 1 × 4 = 4. Para n = 3, techo(3/3) × 4 = 1 × 4 = 4 Para n = 4, techo(4/3) × 4 = 2 × 4 = 8 Para n = 30000, ceil(30000/3) × 4 = 10000 × 4 = 40000. Los casos de entrada pequeña explique por qué “alrededor de un tercio” no es exacto para cada valor. Un byte todavía ocupa un bloque de cuatro caracteres, al igual que dos bytes. La proporción se acerca a los cuatro tercios sólo porque muchos grupos completos de tres bytes dominan el bloque relleno final.
Ejemplo resuelto: medir una cadena 20 de caracteres UTF-8: contar bytes en lugar de caracteres, luego la longitud Base64
La función de techo tiene en cuenta que el grupo final no es múltiplo completo de tres. A medida que n crece, ceil(n/3) se acerca a n/3,, por lo que la salida se acerca a (n/3) × 4 = 4n/3, la relación 4/3.
Medir cadena concreta: 20 caracteres mixtos ASCII, acentos y emoji. El recuento de caracteres es 15 en JavaScript (el emoji cuenta uno). El recuento de UTF-8 bytes difiere: letras ASCII 1 bytes cada una, letra acentuada 2 bytes (0xC3 0xA9 para é), emoji 4 bytes (0xF0 0x9F 0x98 0x80). La herramienta informa caracteres UTF-16, puntos de código Unicode y UTF-8 bytes por separado. Esa distinción evita que una frase de veinte caracteres que contenga símbolos multibyte tenga un precio de veinte bytes. La longitud codificada sigue el recuento de bytes, no lo que cuenta un humano en la pantalla.
Saltos de línea y ajuste MIME: cómo el formato de columna 76 agrega un pequeño porcentaje adicional
Total alrededor de 18 bytes. Base64 codifica estos: ceil(18/3) × 4 = 6 × 4 = 24 caracteres. Dado que 18 es múltiplo de tres, no se necesita relleno. La salida de Base64 es 24 caracteres. La codificación agrega 24 - 18 = 6 bytes, o 33%, lo que confirma la fórmula 4/3 de MIME Base64 introduce una sobrecarga adicional de MIME clásico en 76 caracteres por línea.
Una salida Base64 de 400 caracteres se convierte en aproximadamente 405 bytes con nuevas líneas insertadas. Por cada 76 caracteres de salida Base64, se inserta un byte de nueva línea. Para archivos grandes, agrega menos del 2%. Para los archivos adjuntos de correo electrónico, la convención de nueva línea es estándar y la esperan los analizadores; La herramienta acepta Base64 envuelto y decodifica correctamente. Las interacciones de compresión complican el análisis de tamaño. Los datos binarios sin procesar (imagen, video) se comprimen de manera diferente que el texto Base64. ToolAcre inserta una nueva línea después de cada segmento de 76 caracteres configurado y excluye esas nuevas líneas de la medida de caracteres codificados que se muestra. Un presupuesto en formato cable debe volver a agregar los separadores; una comparación de la medición visible por sí sola describe los símbolos Base64, no todos los bytes de final de línea transmitidos.
Interacciones de compresión: por qué el texto Base64 tiende a comprimirse peor que los bytes sin formato que representa
La cadena Base64 puede comprimirse al 60% de su tamaño con gzip, y la imagen puede comprimirse al 25%. Debido a que gzip busca patrones de bytes repetidos, la representación de texto (letras A–Z más + / o - _) tiene menos repetición que los datos binarios. Insertar una imagen con compresión a menudo cuesta más en código que incrustarla por separado. Para fuentes, particularmente complejas con muchos glifos, la inserción de Base64 puede resultar ineficiente.
El análisis de compensaciones depende del contexto específico. Puede valer la pena incluir un URI de datos pequeños (10–50 bytes) para evitar solicitudes HTTP. Es posible que no sea posible incluir un activo grande (100 KB). La compresión depende de patrones tanto en la fuente como en su representación Base64, por lo que un porcentaje universal de sobrecarga comprimida sería deshonesto. Mida el activo real antes y después de la compresión de la respuesta circundante. El costo seguro es el recuento de caracteres sin comprimir dado por la fórmula del bloque.
Lo que esto no cubre: medición del rendimiento de renderizado o decodificación y optimizaciones específicas del formato como WebP
Si el activo en CDN está cerca del usuario, se evita la solicitud y no se beneficia. Si el activo en el mismo servidor y la carga requieren un viaje de ida y vuelta adicional, la inserción podría estar justificada. La medición es esencial: use fórmulas para calcular el tamaño en línea, agregue el número de caracteres al archivo CSS o HTML, mida el tamaño total del paquete y el tiempo de carga.
33% de gastos generales es seguro; el beneficio de rendimiento no lo es. URL-safe Base64 (base64url) tiene la misma proporción 4/3, solo caracteres diferentes. Quitar el relleno guarda dos caracteres en el peor de los casos. Para archivos grandes, insignificante. Para los tokens JWT (tres segmentos de base64url unidos por puntos), eliminar el relleno es convencional pero ahorra muy poco espacio; El tamaño real es el contenido simbólico, no la sobrecarga de codificación. La velocidad de renderizado, la decodificación de imágenes y los formatos alternativos como WebP requieren medidas diferentes. Una cadena Base64 más corta no implica pintar más rápido y esta herramienta de solo texto no acepta un archivo de imagen. Su contribución confiable es la aritmética para el texto UTF-8 ingresado en el panel.
Conclusión: presupuesta un tercio adicional: cómo el codificador y descodificador Base64 te proporciona la longitud codificada real de cualquier texto para que puedas medir en lugar de adivinar
La compresión también codifica el texto de manera similar; si los dos últimos caracteres son == o una cadena más corta, casi no hace ninguna diferencia en la salida de gzip. El codificador y decodificador Base64 informa inmediatamente tanto el recuento de bytes de entrada como el recuento de caracteres de salida. Para cualquier codificación de texto, puede ver el aumento de tamaño exacto. Para cadenas UTF-8 con caracteres de varios bytes, la herramienta muestra que el recuento de caracteres (lo que se ve) difiere del recuento de bytes (lo que codifica Base64).
Una cadena de caracteres 10 puede tener 15 bytes si contiene acentos y emoji, lo que produce 20 caracteres de salida Base64 en lugar de una proporción de 4/3 basada en el recuento de caracteres. Comprender la distinción aclara por qué incluir íconos con muchos emojis es más costoso que el arte ASCII: no los emoji cuestan más, UTF-8 bytes que representan. Para un valor en línea candidato, registre el recuento de UTF-8 bytes y el recuento de caracteres codificados de la herramienta uno al lado del otro. Luego incluya el prefijo URI, la sintaxis CSS y cualquier ajuste requerido por el destino. Esa medición completa es más útil que repetir un porcentaje redondeado sin sus costos de encuadre.