Estos tres nombres describen esquemas relacionados de binario a texto, pero cumplen con diferentes restricciones. Base64 y Base64URL utilizan grupos de seis bits. El estándar Base32 utiliza grupos de cinco bits y un alfabeto más pequeño. La elección correcta es aquella que su aplicación de transporte, almacenamiento y recepción puede conservar exactamente.
Comparar alfabetos antes que longitudes
El estándar Base64 utiliza letras mayúsculas y minúsculas, dígitos, más y barra. Base64URL sustituye el guión y el guión bajo por los dos últimos caracteres. Ambos distinguen entre mayúsculas y minúsculas. El RFC estándar Base32 utiliza mayúsculas de la A a la Z y dígitos del 2 al 7. Un decodificador puede aceptar minúsculas por conveniencia, pero un protocolo debe indicar si eso está permitido y definir su salida canónica.
Un canal que no distingue entre mayúsculas y minúsculas puede destruir un valor Base64 mientras conserva uno Base32 especificado correctamente. Un token URL tiene restricciones diferentes a las de un código leído en voz alta por teléfono. No elijas únicamente por lo corta que parece una muestra.
Comprender la compensación del tamaño
Haciendo caso omiso del grupo parcial final, Base64 necesita aproximadamente 1,33 caracteres por byte y Base32 necesita 1,6. El relleno estándar Base32 emite grupos de ocho caracteres para cinco bytes. Para un byte que contiene la letra f, los vectores comunes son Zg== en Base64 y MY====== en Base32. Las entradas pequeñas exageran la sobrecarga de relleno, así que compare longitudes de carga útiles realistas.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======No mezcle variantes Base32
Crockford Base32 está diseñado en torno a identificadores legibles por humanos y utiliza un alfabeto y reglas de ambigüedad diferentes a las del RFC Base32. Base32hex también difiere. Un valor producido por una variante no puede entregarse ciegamente a otro decodificador. Nombra la variante, el alfabeto, la política de relleno y cualquier comportamiento de suma de verificación en tu documentación.
La codificación tampoco proporciona autenticación. Un valor mal escrito aún puede ser sintácticamente válido y decodificarse en bytes diferentes. Si los usuarios transcriben un código, considere una suma de verificación definida por el protocolo o un paso de verificación en lugar de asumir que el alfabeto detecta todos los errores.
Anota el contrato completo
Especifique el orden de los bytes de entrada cuando sea relevante, el comportamiento de entrada vacía, la preservación del cero inicial, la longitud máxima, la aceptación de espacios en blanco y el manejo de caracteres no válidos. Incluya vectores de prueba con bytes de alto valor y grupos parciales. Utilice el codificador y decodificador elegido de forma independiente contra esos vectores, no sólo entre sí; De lo contrario, puede parecer que los errores coincidentes pasan de ida y vuelta. Las formas estándar y los vectores de referencia están en RFC 4648.