Elija Codificar o Decodificar, seleccione un esquema y haga clic en su botón de acción. Todo el procesamiento se queda en su navegador.
¿Qué son Base32 y Base58?
Son dos respuestas a una misma pregunta: a un canal que transporta texto se le pide que transporte bytes. Base32 y Base58 no son cifrado ni hash — no ocultan nada ni acortan nada. Reescriben una cadena de bytes con un conjunto fijo de caracteres legibles, y cualquiera que sepa qué conjunto se usó puede deshacerlo directamente. La única razón para preferir uno u otro es lo que hace el extremo receptor con los caracteres.
Dos familias hacen esa reescritura de formas completamente distintas, y la diferencia explica casi todas las sorpresas de esta página:
- Empaquetado de bits — Base32, Base32 Hex, Base32 de Crockford, z-base-32. Los bytes se cortan en grupos fijos y cada cinco bits se convierten en un carácter. La longitud de la salida se puede predecir a partir de la longitud de la entrada, y el último grupo, parcialmente lleno, se marca con caracteres de relleno o se deja corto.
- Conversión de números grandes — todas las tablas de Base58. La cadena de bytes completa se lee como un único número enorme en base 256 y se vuelve a escribir en base 58. No hay grupos ni relleno; la longitud no se divide en nada, y cada byte cero inicial se convierte en un símbolo cero inicial.
Adónde van los seis bits que llevan datos: Base32 usa cinco bits por carácter, así que necesita ocho caracteres por cada cinco bytes de entrada — unos un 60% más. Base58 usa unos 5,86 bits por carácter, así que queda cerca de un 37% más. Base64 usa seis bits por carácter y queda en un 33%. Los alfabetos más grandes son más cortos y más difíciles de leer en voz alta, que es exactamente la compensación que hace cada uno.
Los siete alfabetos de esta página
Cada alfabeto se imprime completo en lugar de describirlo, porque dos herramientas que imprimen caracteres distintos bajo el mismo nombre no van a coincidir entre sí, por mucho que diga la etiqueta. Las filas de RFC 4648 son normativas; las de Crockford y z-base-32 siguen lo que publicó el autor del formato; las tres filas de Base58 son convenciones muy extendidas y no estándares, por eso se listan por separado.
Base32 de Crockford y el símbolo de verificación de módulo 37
El alfabeto elimina I, L, O y U para que ningún símbolo se pueda leer como otro. Lo que queda no distingue mayúsculas al leer: i y l se leen como el dígito 1, o se lee como el dígito 0, y los guiones solo sirven para que una cadena larga sea más fácil de leer. Además, el formato define un símbolo de verificación opcional, que es el valor de la cadena de símbolos leída como número en base 32, tomado en módulo 37, y escrito con cinco símbolos extra para los valores de 32 a 36.
El símbolo de verificación se calcula sobre la cadena de símbolos, no sobre los bytes: como el codificador rellena con ceros el último grupo, decodificar los mismos caracteres siempre vuelve al mismo valor. Por eso el valor de verificación de la tabla se puede reproducir a mano solo con la columna codificada. Los cinco símbolos extra son *, ~, $, = y U para los valores 32, 33, 34, 35 y 36, así que un símbolo de verificación no siempre es un dígito o una letra.
z-base-32
z-base-32 mantiene el empaquetado de cinco bits de Base32 de RFC 4648 y solo cambia el orden de los treinta y dos caracteres. El orden se elige para que los caracteres que más probablemente una persona tenga que escribir a mano sean los más fáciles de escribir y los más difíciles de confundir. No tiene relleno, así que quien lo lee tiene que saber cuántos símbolos se espera que tenga un valor; ese es el precio de un formato diseñado para leerse a mano antes que nada.
Base58Check: un byte de versión, la carga útil y cuatro bytes de suma de comprobación
Base58 por sí solo no tiene forma de distinguir una cadena mal escrita de una correcta, porque casi cualquier combinación de sus cincuenta y ocho caracteres es un número válido. Base58Check lo resuelve metiendo los datos dentro de un envoltorio: un byte de versión, luego la carga útil y después los cuatro primeros bytes de SHA-256 aplicado dos veces seguidas a las dos primeras partes. Un programa receptor recalcula esos cuatro bytes y rechaza la cadena si no coinciden. El byte de versión es lo que indica a una cartera si está viendo una dirección de pago, una dirección de script o una clave privada.
El generador que hay debajo del convertidor toma el byte de versión y la carga útil en hexadecimal y escribe la cadena Base58Check; el verificador lee una, separa los cuatro bytes de suma de comprobación, la recalcula e informa tanto de la que encontró como de la que esperaba. Una suma incorrecta aquí significa que la cadena se escribió mal o se alteró — nunca significa que la carga útil sea incorrecta, porque la carga útil nunca se interpreta.
Malentendidos habituales
- "Base64 es cifrado." No. No hay clave ni secreto; cualquiera puede revertir la salida. Base32 y Base58 están en la misma situación, y pasar un valor por los tres tampoco añade protección.
- "Una cadena Base58 es una dirección de Bitcoin." Solo cuando además pasa la suma de comprobación de Base58Check y lleva un byte de versión que el software receptor reconoce. Las cadenas Base58 aparecen en muchos otros lugares, incluidos identificadores sencillos sin ninguna suma de comprobación.
- "Los tres alfabetos Base58 son intercambiables." Usan los mismos cincuenta y ocho caracteres en tres órdenes distintos, así que los mismos bytes producen tres cadenas distintas. Una herramienta tiene que saber cuál usar, y esta página siempre indica cuál usó.
- "El relleno forma parte del valor." Los caracteres
= solo marcan el último grupo. Dos cadenas Base32 que solo se diferencian en el relleno describen los mismos bytes, por eso el decodificador acepta una cadena a la que se le ha quitado el relleno. - "Cualquier carácter sirve." Cada alfabeto es un conjunto fijo. Un carácter que no esté en él no tiene valor, así que el decodificador se detiene y nombra el carácter y su posición en lugar de adivinar.
Preguntas frecuentes
¿Por qué Base32 usa 2-7 y no 0-9? Porque RFC 4648 eligió el alfabeto para que se mantenga dentro de los caracteres que puede contener un nombre de dominio, y para que sea fácil de leer en voz alta. Base32 Hex usa 0-9 A-V cuando importa más la ordenación natural.
¿Por qué una cadena Base58 empieza tan a menudo por 1? Cada byte cero inicial de la entrada se convierte en un 1 inicial (el primer carácter de los alfabetos de Bitcoin y de Flickr). Un byte de versión 0x00 es un byte cero, así que la mayoría de las direcciones de Bitcoin de la red principal empiezan por exactamente un 1.
¿Qué carga el botón Ejemplo? El ejemplo que corresponde al esquema y a la dirección que están en pantalla en ese momento, nunca un texto fijo. Al codificador se le da el texto del ejemplo propio del esquema — los vectores de la sección 10 de RFC 4648 para Base32 y Base32 Hex, el 12345 de Crockford, las filas de z-base-32 que se imprimen arriba — y al decodificador se le da la cadena codificada del alfabeto seleccionado, que es lo que hace que el ejemplo sea útil en ambas direcciones. Las tres filas de Base58 llevan el mismo texto a propósito, así que al cambiar de esquema y pulsar Ejemplo de nuevo se ven lado a lado las tres ordenaciones de los mismos cincuenta y ocho caracteres. Con el símbolo de verificación de Crockford marcado, el decodificador recibe el valor con el símbolo al final, que es la única forma de ver cómo el verificador acepta uno.
¿Esta página envía mis datos a algún sitio? No. Cada conversión ocurre en esta pestaña del navegador, y la página no contiene ninguna llamada de red de ningún tipo. Por eso también funciona abriendo el archivo directamente desde el disco.
¿Cuál debo usar para un secreto? Los secretos de los autenticadores TOTP y HOTP suelen ser Base32 con el alfabeto de RFC 4648, porque el secreto hay que teclearlo a mano. Use el que le pida su software receptor, y nunca confíe en la codificación en sí para mantener el secreto.
