Herramientas de desarrollo · Codificador y decodificador Base64
Por qué Base64 pegado no se decodifica: cambios de línea, nuevas líneas y comillas tipográficas
· Por qué es importante
base64 codificación
Base64 rara vez se rompe en tránsito; se rompe en el portapapeles. Esta publicación cataloga los errores de copiar y pegar que producen errores de longitud y caracteres no válidos y cómo detectar cada uno de ellos rápidamente.
La clave que funcionó en la terminal y falló en el navegador: un carácter invisible y una búsqueda de dos horas
Un ingeniero copió una clave API de una terminal para probarla en un script. La clave funcionó bien en la terminal pero falló con un carácter no válido cuando se pegó en la herramienta del navegador. Dos horas más tarde, después de buscar en el código, la configuración y la documentación, descubrieron un personaje invisible. Una nueva línea al final de la clave, agregada por eco o copiada de una línea de terminal, se convirtió en un carácter adicional que rompió el decodificador Base64. La clave era correcta; el portapapeles no lo era. Los datos Base64 son confiables cuando se transmiten electrónicamente, se suman y se verifican. Se rompe casi exclusivamente al copiar y pegar manualmente.
El ajuste de líneas en terminales, el seguimiento de nuevas líneas desde la salida del comando, la sustitución de comillas tipográficas en editores de texto enriquecido y los caracteres Unicode ocultos al copiar y pegar entre diferentes aplicaciones introducen errores que parecen como si Base64 estuviera roto cuando el problema real está en cómo se copió. Esta publicación cataloga las fallas más comunes y muestra cómo detectar y solucionar cada una rápidamente. El alfabeto Base64 consta de letras mayúsculas y minúsculas, dígitos, signos más, barras y el carácter de relleno (signo igual). RFC 4648 es específico: una cadena Base64 estándar contiene solo esos caracteres más espacios en blanco opcionales si las líneas están ajustadas.
Ajuste de línea desde terminales, clientes de correo electrónico y formato PEM: por qué un salto de columna 76 está bien para algunos decodificadores y fatal para otros
Muchas herramientas toleran desviaciones: aceptan variantes seguras para URL que utilizan guiones y guiones bajos en lugar de signos más y barras, o ignoran las nuevas líneas. Un decodificador estricto que sigue el RFC rechaza cualquier cosa fuera del conjunto de caracteres esperado y falla con un error de carácter no válido. El mensaje de error generalmente nombra el carácter infractor o indica que la cadena no se puede decodificar en absoluto. Al pegar Base64 desde un correo electrónico, una terminal, un historial de chat o un documento formateado, a menudo se introducen caracteres invisibles o sustituciones de caracteres que provocan que la decodificación falle. Los datos en sí están bien; la transferencia del portapapeles lo corrompió.
El ajuste de línea es la fuente más común de fallas de Base64 pegadas y también la que se soluciona más fácilmente. Las herramientas de terminal ajustan la salida en 76 caracteres por línea o, a veces, 80, insertando una nueva línea y continuando en la siguiente línea. Muchos codificadores, incluidas algunas bibliotecas de codificación Base64, envuelven su salida en el mismo límite de caracteres 76 para compatibilidad con el correo electrónico MIME. Cuando copia una cadena Base64 envuelta desde una terminal, aparecen las nuevas líneas.
Nuevas líneas finales de las herramientas de eco y portapapeles: el byte adicional que se convierte en un carácter adicional
Algunos decodificadores aceptan e ignoran las nuevas líneas automáticamente. Otros los rechazan como personajes no válidos. La solución es eliminar todas las nuevas líneas y espacios en blanco. Si una cadena Base64 ocupa varias líneas en el terminal, seleccione todas las líneas, cópielas en un editor y elimine todas las nuevas líneas.
Copie la cadena de una sola línea resultante y péguela en el decodificador. Esto es lo primero que se debe intentar cuando falla una pasta. Las nuevas líneas de las utilidades de eco y portapapeles son otro culpable común. El comando echo $API_KEY imprime la clave seguida de una nueva línea, que es el comportamiento estándar del comando. Si copia esa salida directamente, la nueva línea se incluye en la copia. Algunas terminales agregan una nueva línea adicional cuando copia, y algunos administradores de portapapeles conservan o duplican nuevas líneas. El síntoma es el mismo que el ajuste de línea: un carácter adicional al final de la cadena que no pertenece a Base64.
Comillas tipográficas, espacios sin separación y caracteres de ancho cero: cómo los editores de texto enriquecido reescriben texto sin formato
La solución es igualmente simple: recorte los extremos de la cadena pegada en su editor antes de intentar decodificar. Elimine los espacios en blanco iniciales y finales y cualquier carácter que parezca nueva línea. Si la cadena es lo suficientemente corta, puede volver a escribirla manualmente, pero para claves largas, un recorte manual cuidadoso es más rápido. Las comillas tipográficas, los espacios que no se separan y otras sustituciones de Unicode son trampas sutiles. Los editores de texto enriquecido como Word convierten automáticamente comillas rectas en comillas rizadas, convierten tres guiones en un guión largo y convierten ciertas secuencias de espacios en espacios sin separación. Si alguien pega una cadena Base64 en un documento y luego la copia del documento formateado a una herramienta, aparecen esas sustituciones.
Una comilla doble recta (") se convierte en un par rizado de izquierda y derecha, ninguno de los cuales es Base64 válido. Un espacio sin separación (U+00A0) parece idéntico a un espacio normal pero tiene un código de carácter diferente y no todos los analizadores lo reconocen como espacio en blanco. La solución es pegar primero en un editor de texto sin formato, lo que descarta todo el formato. Si pega desde un documento de Word o un chat formateado, primero péguelo en un editor de texto sin formato o en un área de texto HTML y verifique si hay caracteres impares. Luego copie desde la versión de texto sin formato para usar en su herramienta.
Truncamiento y pérdida de relleno: la comprobación de módulo de longitud 4 que indica que faltan caracteres
El truncamiento ocurre cuando una cadena se corta durante la copia o el pegado. Una cadena Base64 muy larga puede exceder los límites del portapapeles en algunos sistemas o no se puede copiar debido a errores de la aplicación. El resultado es una cadena más corta que está incompleta. Una cadena Base64 debe tener una longitud múltiplo de cuatro después de aplicar el relleno. Si una longitud no es múltiplo de cuatro, se trunca o se daña. El mensaje de error normalmente indica que la longitud de la cadena no es válida o que falta un carácter. La solución requiere saber qué se copió originalmente.
Si puedes verificar la fuente nuevamente, cópiala nuevamente con cuidado. De lo contrario, el truncamiento es irrecuperable. La pérdida de relleno es un problema relacionado: el relleno Base64 con signos iguales a veces se elimina para ahorrar unos pocos bytes. Algunas aplicaciones omiten el relleno y otras lo requieren. Si originalmente se rellenó una cadena y se perdió el relleno, agréguela nuevamente. Una cadena Base64 debe tener 0, 1 o 2 al final de signos iguales de modo que la longitud total sea múltiplo de cuatro. Si no tiene ninguno y la longitud no es múltiplo de cuatro, es posible que se haya perdido el relleno.
Ejemplo resuelto: reparar una cadena envuelta y truncada: limpiarla paso a paso hasta que se decodifique
Un ejemplo resuelto muestra estas reparaciones paso a paso. Supongamos que una clave API copiada aparece así en su editor: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==. Empiece por identificar los problemas. El Cg== final es impar; Cg es base64 para un carácter de nueva línea (hexadecimal 0A), y el == adicional sugiere que se agregó algo. Elimine el Cg== final y pruebe solo con VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0. Eso todavía no está bien; la longitud es 37 caracteres, no un múltiplo de cuatro. Recortar de nuevo: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (caracteres 35, todavía incorrecto). Consulta la fuente original. La cadena correcta es VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (32 caracteres) con el relleno adecuado: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0. Agréguelo: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=.
Prueba en el decodificador. Esto se decodifica como Esto no es realmente un secreto. En cada paso, utilice el codificador y decodificador Base64 para probar la cadena actual, solucionar el problema identificado y probar nuevamente hasta que se decodifique. El decodificador no puede reparar la corrupción dentro de los bytes Base64. Si los bytes están realmente dañados durante el tránsito, la transmisión o el almacenamiento, Base64 no puede detectarlo. El RFC especifica caracteres válidos; cualquier carácter fuera de ese conjunto es el trabajo del decodificador a capturar. Cualquier byte dañado, como un 0 que se convierte en 1 en medio de un carácter Base64, produce un código de carácter completamente diferente y no es detectable solo por Base64.
Lo que esto no cubre: corrupción dentro de los bytes codificados, que Base64 no puede detectar
Se utilizan sumas de verificación o firmas digitales para detectar este tipo de corrupción y deben calcularse en los datos binarios originales antes de la codificación Base64. Si decodifica una cadena Base64 y el resultado es basura o difiere de lo esperado, la corrupción ocurrió antes de la codificación o durante la transmisión, no durante el paso de copiar y pegar. Esto es raro en la práctica. La mayoría de las fallas son problemas de copiar y pegar como los anteriores. Un enfoque sistemático para depurar errores de copiar y pegar de Base64 es probar cada problema potencial en orden. Primero, elimine todos los espacios en blanco y nuevas líneas. Luego, recorte los espacios iniciales y finales y los caracteres extraviados.
Luego verifique la longitud del módulo cuatro y agregue relleno si es necesario. Pegue cada versión en el codificador y decodificador Base64 y vea si se decodifica. Si la verificación de longitud falla, pregunte si la cadena fue truncada y recupérela de la fuente original. Si la verificación del alfabeto falla y ve caracteres inusuales, busque comillas tipográficas o sustituciones Unicode y reemplácelas con equivalentes ASCII. Utilice una herramienta en línea que le muestre caracteres no válidos por nombre para que pueda identificarlos y eliminarlos. El codificador y decodificador Base64 hace esto para cada carácter no válido, indicando exactamente qué carácter no está en el alfabeto.
Conclusión: verifique la longitud y el alfabeto antes de culpar a los datos: cómo el codificador y descodificador Base64 le brinda un lugar local rápido para probar cada reparación
Utilice esa retroalimentación para corregir cada carácter y continúe hasta que la cadena se decodifique. Prevenir es más fácil que depurar. Cuando sepa que necesitará nuevamente una cadena Base64, cópiela de manera que conserve el formato. No lo pegue en un documento de texto enriquecido. Guárdelo en un archivo de texto sin formato o en un área de texto designada que no realice sustituciones. Si alguien le envía una cadena Base64 en un mensaje formateado, pídale que la reenvíe en formato de código o texto sin formato. Si debe copiar desde una fuente formateada, péguelo primero en un editor de texto sin formato y verifique la cadena antes de usarla.
Pruebe la cadena en el codificador y decodificador Base64 tan pronto como la tenga, antes de confiar en ella. Si falla, puede solicitar una copia nueva mientras aún se pueda acceder a la fuente. Si espera hasta que la cadena sea vieja o la fuente desaparezca, corregir el truncamiento o la corrupción se vuelve imposible. El codificador y decodificador Base64 le brinda un lugar local rápido para probar cualquier cadena antes de comprometerse a usarla. Pruebe temprano y con frecuencia para que los errores de copiar y pegar se detecten de inmediato.