1. Qué ocurre cuando «ñ» sale como «Ã±»: dos números leídos como si fueran dos letras
Un equipo no guarda letras, guarda números (bytes). Para escribir o leer texto, necesita una tabla que diga qué número corresponde a qué carácter. El W3C lo explica así: una codificación es un conjunto de correspondencias entre los bytes del equipo y los caracteres de un repertorio [2].
La «ñ» tiene un caso muy claro. En UTF-8, la codificación más usada hoy, la «ñ» ocupa dos bytes: C3 B1 (en notación hexadecimal). Si un programa cree que el texto está en Latin-1 o en Windows-1252, que guardan una letra por byte, lee esos dos bytes por separado: C3 es «Ã» y B1 es «±». Resultado: «Ã±». Los números no cambiaron; solo se leyeron con la tabla equivocada [2] [1].
Estos ejemplos, calculados con las codificaciones estándar de Python, muestran el patrón: las letras con tilde y la eñe empiezan con «Ã», y los signos de apertura empiezan con «Â».
- «ñ» (C3 B1) se lee «Ã±», así que «año» sale como «año».
- «á» (C3 A1) se lee «Ã¡», «ó» (C3 B3) se lee «Ã³», «é» (C3 A9) se lee «Ã©».
- «¿» (C2 BF) se lee «Â¿», y «¡» (C2 A1) se lee «Â¡».
- «í» (C3 AD) se lee como «Ã» y un guion blando (U+00AD), que algunos programas no muestran; por eso a veces parece que solo sobra una «Ã».
Así, «¿Cómo estás?» puede aparecer como «Â¿Cómo estás?». Un detalle útil: el problema no es la fuente tipográfica. Cuando a una fuente le falta un carácter, lo normal es ver un cuadrado o un signo de interrogación; las secuencias con «Ã» vienen de leer los bytes con otra tabla [2].
La pregunta que queda es por qué hay más de una tabla. Empezamos por la primera.
2. Por qué la primera tabla, ASCII, no tenía «ñ»: 128 caracteres pensados para el inglés
La Asociación Estadounidense de Normas (ASA) publicó la primera edición del estándar ASCII en 1963. Define 128 caracteres con números de 7 bits: 33 son caracteres de control y 95 se pueden imprimir, entre ellos las letras de la a a la z en minúscula y mayúscula, los dígitos y los signos básicos [3].
Esas 26 letras son las del alfabeto inglés. No hay «ñ», «á» ni «¿». De sus 95 posiciones imprimibles, la mayoría eran para letras inglesas, dígitos y signos básicos, así que cada idioma tuvo que inventar su propia ampliación. Para escribir en español, hace falta una tabla más grande.
3. Cómo Latin-1 y Windows-1252 añadieron la «ñ», y por qué dos tablas parecidas ya bastan para confundirse
Una solución fue usar un byte completo, con 256 posiciones, por cada letra. La norma ISO 8859-1, conocida como Latin-1, parte de la norma ECMA-94 (marzo de 1985); la primera edición de ISO es de 1987. Cubre completamente las letras del español, incluidas «ñ» (posición F1) y «á» (posición E1) [4].
Windows-1252 es una variante que usa las posiciones 80 a 9F, que Latin-1 reserva para códigos de control, para añadir signos tipográficos como las comillas curvas, las rayas y el símbolo del euro [4]. En la interpretación web que define el WHATWG, la etiqueta ISO-8859-1 se trata como Windows-1252 [4] [5].
Había, pues, tablas distintas para escribir en español, en ruso, en griego... y el mismo byte significaba cosas distintas en cada una. El W3C da un ejemplo: el número 233 es «é» en ISO 8859-1 y «щ» en ISO 8859-5 (la tabla para escritura cirílica) [2]. Si el texto no dice con qué tabla se escribió, quien lo lee tiene que adivinar.
4. Cómo Unicode y UTF-8 resolvieron el problema de las tablas: una sola lista de caracteres del mundo
Una salida fue crear un repertorio común de caracteres, en lugar de una tabla por idioma. Unicode 1.0 empezó a publicarse en octubre de 1991 (el primer volumen) y completó su primera edición en junio de 1992 (el segundo) [6]. La idea es dar a cada carácter de cualquier escritura un número único. Falta una forma de guardar ese número como bytes, y una de ellas es UTF-8.
Rob Pike cuenta que él y Ken Thompson, en Bell Labs, diseñaron UTF-8 en septiembre de 1992. Recuerda que Thompson escribió el esquema sobre un mantel individual en un restaurante de Nueva Jersey (según Pike, ojalá lo hubieran guardado). No les gustaba la codificación de ISO 10646 que usaba su sistema, Plan 9. Entre otras cosas, no protegía los bytes nulos ni la barra del ASCII, que los sistemas de archivos de tipo Unix necesitan, y la propuesta de X/Open no permitía retomar la lectura a mitad de un flujo de bytes [7]. Es el relato de uno de sus autores; la fecha exacta de cada paso la dan sus mensajes, y yo me limito a «septiembre de 1992».
El estándar de UTF-8 (RFC 3629) muestra el resultado:
- Los caracteres de U+0000 a U+007F, es decir, ASCII, ocupan un solo byte con el mismo valor. Por eso un texto en ASCII puro ya es UTF-8 válido [8].
- Los bytes del rango ASCII no aparecen dentro de los caracteres de varios bytes [8].
- El primer byte indica la longitud; si se empieza a leer en medio de un carácter, se puede avanzar hasta encontrar el siguiente límite [8].
- La «ñ» (U+00F1) cae en el tramo de dos bytes, con patrón 110xxxxx 10xxxxxx. Por eso es C3 B1 y no un solo byte [8].
Esa última línea explica por qué un texto en UTF-8 leído como Latin-1 se rompe justo en las letras con tilde, mientras que las letras sin tilde se ven bien.
5. Por qué todavía vemos «Ã±» si casi todos usan UTF-8: archivos antiguos y declaraciones que no coinciden
Hoy UTF-8 domina. El estándar de codificación del WHATWG, que define cómo leen texto los navegadores, exige que los protocolos y formatos nuevos usen únicamente UTF-8 [5]. Según W3Techs, en octubre de 2026 UTF-8 lo usa el 99,1 % de los sitios web cuya codificación se conoce [9]. Es un porcentaje sobre los sitios que declaran o permiten detectar su codificación, no sobre todos los que existen.
Aun así, «Ã±» sigue apareciendo. Hay datos guardados desde hace décadas en tablas antiguas, y programas que, en lugar de leer lo que dice el archivo, suponen una codificación por defecto. El W3C añade un matiz: declarar otra codificación en una página no cambia los bytes; el archivo tiene que estar guardado de verdad con esa codificación [2]. Y la enciclopedia Wikipedia llama a UTF-8 leído como Windows-1252 «el error más común hoy», porque muchas aplicaciones usan ISO 8859-1 o Windows-1252 por defecto [1]. Esta última es una fuente secundaria, así que es una descripción general y no una medición.
Si aparece una secuencia así, la pista es útil: casi siempre es UTF-8 leído con una tabla de un byte por letra, no texto realmente dañado.
6. Prueba tú mismo cómo una tabla desplazada rompe un texto
Con lápiz y papel puedes ver el mismo efecto. Escribe tu nombre sin tildes y numera el alfabeto: A=1, B=2, C=3... hasta Z=26. «GATO» queda como 7, 1, 20, 15. Ahora cambia la tabla: si A=0, cada número se lee con esa regla: 7 es H, 1 es B, 20 es U y 15 es P, y sale «HBUP». Los números son los mismos; solo cambió la tabla.
En Python puedes ver el caso real con "ñ".encode("utf-8").decode("latin-1"), que da «Ã±». Si quieres leer las fuentes originales, el relato de Rob Pike es corto [7] y el artículo del W3C sobre codificaciones es muy claro [2]; los dos están en inglés. Si programas, prueba también con tu nombre o con una palabra con «ñ» para ver cuántos bytes ocupa en UTF-8.