Síntomas frecuentes
Un decodificador puede mostrar “carácter no válido”, “longitud incorrecta”, “firma desconocida” o simplemente crear un archivo que no abre. Cada mensaje apunta a una etapa distinta: la sintaxis Base64, la decodificación o la estructura interna del archivo. Una cadena sintácticamente válida también puede estar incompleta y producir bytes insuficientes.
1. Comprueba cómo se copió
Campos de base de datos, terminales, hojas de cálculo y visores suelen recortar valores extensos. Compara la longitud del origen y el destino. Busca puntos suspensivos añadidos por la interfaz, comillas tipográficas, espacios invisibles o saltos insertados dentro de una respuesta. Si el sistema muestra solo una vista abreviada, exporta el valor completo en lugar de copiar lo visible.
Guarda el original y trabaja sobre una copia. Así podrás distinguir una normalización legítima de una modificación destructiva.
2. Retira solamente la envoltura
Una Data URL incluye un prefijo hasta la primera coma. Una respuesta JSON puede incluir secuencias escapadas como \/ o saltos representados mediante \n. Primero analiza el JSON con un parser; no elimines barras de forma global porque podrían formar parte de otra representación.
data:image/png;base64,iVBORw0... se conserva lo posterior a la coma. No se debe borrar texto similar que aparezca dentro de los datos.3. Identifica la variante
Base64 estándar utiliza letras, números, +, / y, al final, uno o dos signos =. Base64 URL-safe sustituye los dos símbolos por - y _; algunos emisores además omiten el relleno. Ambas variantes son válidas en su contexto, pero el decodificador debe saber cuál recibe.
El signo = solo puede aparecer al final. Añadir relleno puede resolver una variante que lo omitió deliberadamente, pero no recupera datos cortados. Si faltan muchos caracteres, ninguna cantidad de relleno reconstruirá los bytes perdidos.
4. Usa la longitud como pista
Después de quitar espacios permitidos, una cadena estándar completa suele tener longitud múltiplo de cuatro. Un resto de uno es una señal especialmente sospechosa: no puede resolverse únicamente con relleno válido. Los restos de dos o tres pueden corresponder a Base64 sin padding, siempre que el emisor use esa variante.
El tamaño decodificado aproximado se calcula como tres cuartos de la longitud Base64, descontando el relleno final. Si esperabas un PDF de varios megabytes y recuperas unos pocos kilobytes, probablemente el valor fue truncado.
5. Valida el archivo recuperado
Decodificar sin error solo demuestra que el alfabeto era interpretable. Comprueba la firma, el tamaño y la apertura. Un PDF debe contener una estructura coherente, no únicamente el encabezado; una imagen debe ofrecer dimensiones legibles. Si la firma indica un tipo distinto al esperado, vuelve al sistema de origen.
6. Revisa el transporte
En formularios codificados como URL, el signo + puede interpretarse como espacio si el valor no se escapó correctamente. En CSV, comas, comillas y saltos pueden alterar una columna mal delimitada. En una API, revisa límites de cuerpo, serialización y si el campo fue registrado o recortado antes de llegar al cliente.
Qué no hacer
- No pegues repetidamente datos confidenciales en decodificadores remotos.
- No elimines todos los caracteres que “parecen extraños” sin conocer la variante.
- No renombres el resultado para forzar su apertura.
- No confíes en un mensaje de éxito sin verificar el archivo.
- No intentes reparar información truncada; vuelve a obtenerla desde el origen.
Ruta rápida de diagnóstico
- Obtén el valor completo otra vez.
- Analiza primero su contenedor, como JSON o Data URL.
- Detecta estándar o URL-safe.
- Normaliza solo espacios permitidos y padding omitido.
- Decodifica con límite de tamaño.
- Comprueba firma y abre el resultado.
Si el problema persiste, registra de forma segura la longitud, la variante y el mensaje exacto; evita compartir la cadena real en un reporte público.