Codificar en hexadecimal

El hexadecimal es una forma de escribir bytes, y un byte tiene exactamente 256 valores posibles, o sea dos dígitos hexadecimales. Por eso la salida siempre tiene un número par de dígitos — una longitud impar es señal segura de que algo se ha perdido por el camino.

Un carácter, en cambio, no es necesariamente un byte. Una `a` lo es, una `ñ` son dos, un carácter chino tres y un emoji cuatro. Quien quiera saber la longitud de un texto en bytes la ve aquí directamente, y con frecuencia es un tercio mayor que el número de caracteres con el que se calculó un límite de campo.

Un texto es una sucesión de caracteres; se convierte en bytes solo a través de una codificación. La pregunta «qué bytes tiene este texto» está por tanto incompleta mientras no se diga cuál. Aquí es UTF-8, porque la web, Linux, macOS, JSON y prácticamente cualquier protocolo moderno están fijados en ella.

Donde haya otra cosa de por medio — una página de códigos antigua de Windows, Latin-1 en una columna de base de datos — los bytes difieren, y difieren justo en los caracteres por encima de ASCII. Una `ñ` es `c3 b1` en UTF-8 y el único byte `f1` en Latin-1. Si tus valores no cuadran, ese es el primer sitio donde mirar.

Los dos puntos entre bytes son la forma en que OpenSSL imprime las huellas de certificado y en la que se leen las direcciones MAC. Los espacios son la forma de un volcado hexadecimal, como el que muestra `xxd` o una captura de red. Sin separador es lo que va en un campo de base de datos, en una línea de configuración o en una comparación de hashes.

En la práctica, la elección depende de a dónde va el valor y no de qué se ve mejor. Una comparación entre dos huellas falla sorprendentemente a menudo solo porque una está anotada con dos puntos y la otra sin ellos — los bytes son los mismos, las cadenas no.

Para el valor de un byte la caja de los dígitos da igual: `ff` y `FF` son el mismo número. Para una comparación de textos lo cambia todo, así que la pregunta deja de ser cosmética en cuanto el valor se compara, se hashea o se usa como clave.

Las convenciones no son uniformes: las herramientas de Unix y la mayoría de las bibliotecas escriben en minúsculas, las de Windows y muchas vistas de certificados en mayúsculas, y las direcciones MAC de las dos maneras según el fabricante. Quien compare, normaliza antes; y quien calcule una firma tiene que saber qué caja pide la especificación, porque si no el hash es otro.

El motivo serio más habitual para mirar un texto en hexadecimal es una comparación que falla aunque los dos valores parezcan idénticos. En la vista de bytes se ve al momento lo que la pantalla esconde: un `c2 a0` de un espacio duro, un `0d` delante del `0a` de una línea de Windows, un `09` de un tabulador donde se suponía un espacio.

Igual de frecuente es un `ef bb bf` al principio — la marca de orden de bytes que Excel y algunos editores de Windows ponen al comienzo del archivo. Es invisible, forma parte del contenido, y es la razón de que la primera columna de un CSV tenga a veces un nombre que ningún programa reconoce.

Windows termina una línea con `0d 0a`, Unix y macOS con `0a`. En pantalla se ven idénticos; en los bytes, no — y por eso difieren las sumas de verificación de dos archivos «iguales», los sistemas de versiones señalan cambios en líneas intactas y falla una comparación que se daba por trivial.

En esta página se ve directamente: pega texto con un salto de línea y mira si delante del `0a` hay un `0d`. Es la vía más rápida para resolver si alguna herramienta de la cadena ha reescrito los finales de línea — cosa que Git hace de forma explícita según la configuración.

Ambos escriben bytes como texto imprimible, y elegir entre ellos es elegir entre legibilidad y tamaño. El hexadecimal necesita dos caracteres por byte, o sea el doble de espacio; Base64 necesita alrededor de un tercio más que los datos en bruto y es por tanto bastante más económico.

A cambio, el hexadecimal se lee. Se puede mirar un byte concreto en una posición concreta, poner dos valores uno al lado del otro y encontrar la primera diferencia, y se ven los límites entre bytes. En Base64 nada de eso funciona, porque allí tres bytes se funden en cuatro caracteres. Por eso lo habitual en hashes y huellas es hexadecimal, y en datos útiles Base64.

El prefijo `0x` es una convención de los lenguajes de programación y le dice al compilador que los dígitos siguientes se leen en hexadecimal. Va delante de un número suelto en el código, no delante de cada byte de una secuencia: `0x48 0x61` es una lista de dos números, `4861` son dos bytes.

Por eso aquí no se genera prefijo. La dirección contraria es más generosa: el decodificador de esta web acepta `0x` delante de cada byte, porque esas listas copiadas de código fuente llegan de verdad. Generar y aceptar pueden diferir, y aquí lo hacen a propósito.

En este campo suele entrar el valor que uno preferiría no mover: un campo de un registro que se comporta raro, una clave, un candidato a contraseña que se quiere cotejar con una suma de verificación. Como la conversión ocurre en la página, no hay comunicación a nosotros.

Se comprueba en el panel de red: mientras la usas no sale ninguna petición que lleve tu entrada. Lo que queda está en la política de privacidad — la visita y las peticiones de publicidad y analítica. El contenido del campo no está entre ellas, y con esta clase de valor es lo único que cuenta.