¿Qué es el Código ASCII?

ASCII son las siglas de American Standard Code for Information Interchange. El estándar se publicó en 1963 como ASA X3.4-1963, obra de un comité de la American Standards Association, precursora de la actual ANSI. Su propósito original no tenía nada que ver con las páginas web: servía para que teletipos, ordenadores y equipos de telecomunicación de distintos fabricantes intercambiaran texto sin perder ni un carácter por el camino.

La idea central es simple. Cada carácter recibe un número entre 0 y 127, representable con 7 bits. Los primeros 32 números, del 0 al 31, son caracteres de control: saltos de línea, retornos de carro y otras instrucciones dirigidas al equipo receptor, no símbolos pensados para aparecer en pantalla. Del 32 al 126 están las letras mayúsculas y minúsculas, los dígitos del 0 al 9 y la puntuación básica del inglés. El número 127 corresponde a DEL, un carácter de borrado heredado de la época de las cintas perforadas.

La versión de 1963 ni siquiera incluía minúsculas; se añadieron en la revisión de 1967. La última revisión con cambios de fondo llegó en 1986, con ANSI X3.4-1986, y desde entonces el conjunto de 128 caracteres se ha mantenido fijo. Esa estabilidad es la razón por la que sigue siendo relevante en SEO técnico sesenta años después: ninguno de esos 128 números ha cambiado de significado desde entonces.

Los tres términos se mezclan en la conversación técnica y no son intercambiables. ASCII es un juego cerrado de 128 caracteres. Unicode es un estándar mucho más amplio que asigna un número único a prácticamente cualquier carácter escrito por el ser humano, con más de 149.000 caracteres asignados en su versión de 2025. UTF-8 es una codificación: el método concreto que convierte esos números en bytes para guardarlos o transmitirlos.

El punto que casi nunca se explica bien es la compatibilidad hacia atrás. UTF-8 se diseñó para que los primeros 128 caracteres de Unicode, que son exactamente los de ASCII, ocupen un solo byte con el mismo valor que tendrían en ASCII puro. Un archivo de texto en ASCII es, sin ningún cambio, un archivo UTF-8 válido. Lo contrario no es cierto: un archivo UTF-8 con una eñe o un emoji deja de ser ASCII en el momento en que aparece ese carácter.

Un carácter ASCII ocupa 7 bits, pero casi ningún sistema moderno mueve datos en unidades de 7 bits: trabaja en bytes de 8. Ese octavo bit sobrante, libre en la especificación original, se convirtió en el origen de buena parte de los problemas de codificación de los años noventa. Distintos fabricantes lo usaron para meter 128 caracteres adicionales, casi siempre vocales acentuadas y letras propias de otros idiomas, pero cada uno con su propia tabla: ISO 8859-1 (Latin-1) en buena parte de Europa occidental, Windows-1252 en los PC con Windows, otras páginas de códigos en el resto del mundo.

El resultado, cuando un texto pasaba de un sistema a otro sin que ambos coincidieran en la tabla, era el llamado mojibake: una eñe convertida en un símbolo sin sentido, un acento que aparecía como un cuadrado, texto directamente ilegible. Unicode y UTF-8 nacieron precisamente para acabar con esa dependencia de qué tabla usaba cada máquina.

Cuando un carácter no ASCII tiene que viajar por un canal que solo admite ASCII, como ocurre todavía en una URL o en la cabecera de un correo electrónico, se recurre a la codificación en porcentaje: el carácter se convierte primero a bytes UTF-8 y cada byte se representa como %, seguido de dos dígitos hexadecimales, usando solo caracteres ASCII para escribir algo que en origen no lo era. Un archivo de configuración de texto plano, como el robots.txt de un sitio, se sigue recomendando en ASCII o UTF-8 sin marcas especiales, precisamente para que cualquier rastreador lo lea sin ambigüedad.

ASCII sigue importando en 2026 por un motivo concreto: varias piezas de la infraestructura web todavía esperan ese formato, o lo prefieren con claridad. Google es explícito al respecto en su documentación sobre estructura de URL: recomienda codificar en porcentaje cualquier carácter fuera del rango ASCII, y pone como ejemplo «no recomendado» una URL con caracteres árabes sin codificar frente a su versión ya codificada.

El caso más práctico es el slug de una URL. Uno con tildes o eñes no rompe la página, pero el navegador y muchos sistemas terminan mostrando la versión codificada en porcentaje, ilegible para un humano y menos clara en el resultado de búsqueda. Esa legibilidad también forma parte de la experiencia de usuario cuando alguien copia o comparte el enlace a mano. Si la URL con acentos y su versión codificada llegan a convivir, dos direcciones distintas apuntan a la misma página, y ahí conviene marcar cuál es la de referencia con una etiqueta canonical.

Fuera del navegador, las cabeceras de un correo electrónico y bastantes sistemas heredados siguen esperando ASCII puro, y un nombre de archivo con caracteres especiales puede comportarse de forma distinta según el sistema operativo o el servidor donde se suba.

• Usa solo letras sin tilde, números y guiones en el slug de cada URL; evita eñes, tildes y espacios aunque el contenido esté en español.
• Deja que el navegador o el servidor codifiquen en porcentaje cualquier carácter fuera de ASCII, en vez de escribirlo directamente en un enlace.
• Guarda los archivos de texto plano en UTF-8 sin BOM: sigue siendo compatible byte a byte con ASCII para los primeros 128 caracteres.
• Nombra los archivos que subes a un servidor (imágenes, PDF, hojas de estilo) sin acentos ni símbolos, para evitar comportamientos distintos según el sistema donde se alojen.
• Mantén el robots.txt y otros archivos de configuración en ASCII puro, sin caracteres especiales que un rastreador o un servidor puedan interpretar mal.
• Si una URL con acentos y su versión codificada llegan a coexistir, márcala como canonical en la versión que quieras que se indexe, en vez de dejar que lo decida el buscador.

• Escribir tildes o eñes directamente en un enlace en lugar de dejar que se codifiquen, lo que genera dos direcciones distintas para el mismo contenido.
• Tratar ASCII y Unicode como sinónimos: ASCII cubre 128 caracteres, Unicode supera los 149.000.
• Guardar un archivo con una codificación distinta de UTF-8, como Windows-1252, sin declararla, lo que produce mojibake al abrirlo en otro sistema.
• Enviar cabeceras de correo con caracteres no ASCII sin codificarlas según el estándar MIME, lo que hace que algunos clientes muestren texto ilegible.
• Insertar símbolos especiales, como marcas de verificación o flechas, directamente en el título o la meta description sin comprobar que el buscador los admite, lo que a veces produce un carácter roto en el fragmento de búsqueda en vez del símbolo esperado.