La codificación UTF-8

La codificación UTF-8 (en inglés, UTF-8 encoding) es la regla con la que casi todos los ordenadores del mundo convierten las letras en bytes y los bytes en letras. Un ordenador no guarda una «a»: guarda un número, y para que otro ordenador lea una «a» donde el primero la escribió, los dos tienen que estar de acuerdo en qué número es cada letra y en cómo se escribe ese número en la memoria. UTF-8 es ese acuerdo para más de ciento cincuenta mil caracteres, desde la ñ hasta los ideogramas chinos y los emojis, y es el que usa el 99 % de las páginas web.

El problema empezó siendo pequeño. El código ASCII, aprobado en Estados Unidos en 1963, asignaba un número del 0 al 127 a cada letra inglesa, cada cifra y cada signo de puntuación, y cabía en siete bits. La «A» era el 65 y la «a», el 97. No había sitio para la ñ ni para las tildes, así que cada país rellenó a su manera los 128 números que quedaban libres en un byte de ocho bits. La norma europea ISO 8859-1, conocida como Latin-1, ponía la ñ en el 241; la rusa ponía ahí una letra cirílica, y un texto escrito en Moscú se leía en Madrid como una ristra de símbolos sin sentido.

Unicode, publicado en 1991, resolvió la primera mitad: dar a cada carácter de cada escritura un número propio y único, su punto de código (code point), que se escribe con una U y cuatro o más cifras hexadecimales. La ñ es U+00F1, el euro es U+20AC y el pulgar hacia arriba es U+1F44D. Pero un número no es todavía una manera de guardarlo. El espacio de Unicode llega hasta U+10FFFF, más de un millón de posiciones, y guardar cada letra en cuatro bytes multiplicaba por cuatro el tamaño de cualquier texto en inglés y rompía todos los programas escritos para ASCII.

La figura de esta página hace la segunda mitad. Cada casilla es un carácter del texto que escribas, con su punto de código debajo y, más abajo, los bytes en los que UTF-8 lo guarda, en hexadecimal y en bits. Las letras inglesas ocupan un solo byte, idéntico al de ASCII. La ñ y las vocales con tilde ocupan dos, el euro y los caracteres japoneses tres, y los emojis cuatro.

La regla está en los bits naranjas. Si un byte empieza por 0, es un carácter ASCII completo. Si empieza por 110, anuncia un carácter de dos bytes; por 1110, de tres, y por 11110, de cuatro. Los bytes que siguen empiezan siempre por 10, y los bits que quedan libres, los negros, se rellenan con el punto de código escrito en binario. De esa regla salen tres propiedades que explican por qué ganó. Cualquier texto ASCII ya es UTF-8 válido sin cambiar un solo byte. Ningún byte de una letra larga puede confundirse con un carácter ASCII, porque todos empiezan por 1, así que un programa antiguo que busca una barra o un salto de línea nunca los encuentra por error en mitad de una ñ. Y si se empieza a leer por la mitad de un fichero, basta con saltar los bytes que empiezan por 10 para encontrar el principio de la letra siguiente.

El diseño tiene autor, fecha y hasta mantel. Rob Pike contó en 2003 que Ken Thompson lo dibujó delante de él una noche de septiembre de 1992, en el mantel de papel de una cafetería de Nueva Jersey, después de que les llegara una propuesta de un comité que les parecía torpe. Volvieron a los laboratorios Bell, y ese viernes el sistema operativo Plan 9, en el que trabajaban, ya funcionaba solo con la nueva codificación. La presentaron en enero de 1993 en la conferencia USENIX con un título que era a la vez la demostración: «Hello World or Καλημέρα κόσμε or こんにちは 世界». En 2003, la norma RFC 3629 la fijó como se usa hoy, con un máximo de cuatro bytes.

El fallo más común con UTF-8 tiene nombre japonés, mojibake (texto transformado), y se reconoce enseguida. Un programa guarda «Año» en UTF-8, con la ñ en dos bytes, C3 y B1, y otro lo abre creyendo que está en Latin-1, donde cada byte es una letra. El C3 se lee como à y el B1 como ±, y el correo llega con «Año». El euro, con tres bytes, se convierte en «â‚¬». El botón de la figura hace esa misma lectura equivocada. Cuando aparecen estos símbolos, el texto no está estropeado: está bien guardado y mal leído, y se arregla diciéndole al programa que lo abre la codificación correcta. En una página web eso es la línea <meta charset="utf-8">, y en una hoja de cálculo, elegir UTF-8 al importar un fichero CSV en lugar de aceptar la opción por defecto.

Hay un segundo malentendido que la figura también enseña. Lo que una persona ve como una letra no siempre es un solo punto de código. El pulgar con tono de piel es el pulgar amarillo, U+1F44D, seguido de un modificador de color, U+1F3FD, y ocupa ocho bytes aunque se vea como un único dibujo. Muchas letras con tilde pueden escribirse también como la letra sin tilde más un acento que se combina con ella. Por eso contar «caracteres» es menos simple de lo que parece, y por eso un límite de 160 caracteres en un mensaje de móvil se queda en 70 en cuanto aparece un emoji. JavaScript, además, cuenta en unidades de dos bytes de otra codificación, UTF-16, que usan por dentro Windows y Java: para él, el pulgar mide dos.

UTF-8 no es la más compacta para todas las lenguas. Un texto en japonés ocupa más en UTF-8, tres bytes por carácter, que en UTF-16, dos. Pero la mayoría de lo que circula por internet es marcado HTML, direcciones y código, que es ASCII, y la compatibilidad pesó más que el ahorro. Según W3Techs, en 2026 la usaba el 99,1 % de los sitios web cuya codificación se conoce, y el 0,8 % que queda en Latin-1 son sobre todo páginas antiguas que nadie ha vuelto a tocar. Para quien escribe en español, la regla práctica es breve: guardar siempre en UTF-8 y, cuando aparezca un Ã, sospechar primero de quien lee y no de quien escribió.

El sistema binario y el bit – La coma flotante – La codificación de Huffman – Marcado de texto – El color RGB y el código hexadecimal – Formato digital