Codificación de Caracteres: ASCII, UTF-8 y Codificación URL

¿Alguna vez pegaste texto de una aplicación a otra y viste caracteres extraños como “–” aparecer donde debería haber un guion largo? Esa experiencia frustrante—conocida como mojibake—afecta a millones de usuarios cada día y es el resultado directo de desajustes de codificación. Entender cómo funciona la codificación no es solo un ejercicio académico; es una habilidad práctica que previene la corrupción de datos, errores de seguridad y experiencias de usuario rotas en toda la web.

¿Qué es la codificación y por qué existe?

A nivel más fundamental, las computadoras solo entienden números. Cada carácter que ves en pantalla—letras, dígitos, puntuación, emoji—se almacena internamente como una secuencia de dígitos binarios (bits). La codificación es el sistema que mapea caracteres legibles por humanos a valores numéricos específicos para que las computadoras puedan almacenar, transmitir y mostrar texto de forma consistente.

Sin un estándar de codificación compartido, el número 65 podría representar la letra “A” en una máquina y un carácter completamente diferente en otra. Los estándares de codificación resuelven esto proporcionando una tabla de consulta universalmente acordada que tanto el emisor como el receptor usan para traducir entre números y caracteres. La historia de la codificación es esencialmente la historia de construir tablas de consulta cada vez más grandes e inclusivas—desde los 128 caracteres de ASCII hasta los más de 150,000 caracteres de Unicode.

Para los desarrolladores y cualquiera que trabaje con datos de texto, entender la codificación es esencial para construir aplicaciones confiables, depurar misteriosos problemas de corrupción de caracteres y trabajar correctamente con contenido multilingüe. Nuestro conjunto de Herramientas de Texto proporciona varias utilidades de codificación y decodificación que pueden ayudarte a trabajar con diferentes formatos de codificación directamente en tu navegador.

ASCII: donde todo comenzó

El Código Estándar Americano para el Intercambio de Información (ASCII) fue publicado en 1963 y se convirtió en la base sobre la cual se construyen todos los sistemas de codificación modernos. ASCII define 128 caracteres usando 7 bits por carácter: 33 caracteres de control no imprimibles (como nueva línea, tabulación y retorno de carro) y 95 caracteres imprimibles (letras mayúsculas y minúsculas del inglés, dígitos del 0 al 9, puntuación y un puñado de símbolos).

Las limitaciones de ASCII se hicieron evidentes casi de inmediato. Con solo 128 puntos de código, no había espacio para caracteres acentuados usados en francés, alemán o español, y mucho menos para escrituras no latinas como chino, árabe o hindi. Varios esquemas de “ASCII extendido” intentaron usar el 8vo bit no utilizado para agregar otros 128 caracteres, pero diferentes regiones crearon diferentes extensiones (ISO 8859-1 para idiomas de Europa Occidental, ISO 8859-5 para cirílico, Windows-1252 para sistemas Microsoft, y muchos otros). Esta fragmentación fue una fuente importante de problemas de compatibilidad: un documento creado con una página de códigos mostraba texto ilegible en un sistema que usaba una página de códigos diferente.

A pesar de su edad, ASCII sigue siendo relevante hoy. Cada carácter ASCII ocupa la misma posición en UTF-8, lo que significa que el texto ASCII puro es automáticamente UTF-8 válido. Los encabezados HTTP, los protocolos de correo electrónico, la sintaxis de lenguajes de programación y la mayoría de los formatos de archivos de configuración están construidos sobre ASCII como línea base común.

Unicode y UTF-8: la solución universal

Unicode fue creado a finales de los años 1980 con un objetivo ambicioso: asignar un identificador numérico único (llamado “punto de código”) a cada carácter en cada sistema de escritura del mundo. A partir de Unicode 16.0 (lanzado en 2024), el estándar define más de 154,000 caracteres que cubren 168 escrituras, así como miles de emoji, símbolos matemáticos, notación musical y escrituras históricas.

Un punto de código Unicode se escribe como U+ seguido de un número hexadecimal. Por ejemplo, U+0041 es la letra latina mayúscula “A,” U+00E9 es la “e” con acento agudo, y U+1F600 es el emoji de cara sonriente. Unicode en sí es un conjunto de caracteres— asigna números a caracteres pero no especifica cómo esos números deben almacenarse como bytes. Ese trabajo recae en las formas de codificación, la más importante de las cuales es UTF-8.

UTF-8 (Formato de Transformación Unicode, 8 bits) es una codificación de longitud variable que usa de uno a cuatro bytes por carácter:

• 1 byte (0xxxxxxx): Caracteres ASCII (U+0000 a U+007F). Esto significa que UTF-8 es retrocompatible con ASCII.
• 2 bytes (110xxxxx 10xxxxxx): Extensiones de escritura latina, griego, cirílico, árabe, hebreo (U+0080 a U+07FF).
• 3 bytes (1110xxxx 10xxxxxx 10xxxxxx): La mayor parte del Plano Multilingüe Básico, incluyendo caracteres chinos, japoneses y coreanos (U+0800 a U+FFFF).
• 4 bytes (11110xxx 10xxxxxx 10xxxxxx 10xxxxxx): Emoji, escrituras históricas, símbolos matemáticos y otros caracteres suplementarios (U+10000 a U+10FFFF).

Este diseño de longitud variable es lo que hace a UTF-8 tan eficiente y dominante. El texto en inglés consume el mismo espacio que ASCII (1 byte por carácter), mientras que los caracteres de otras escrituras usan solo los bytes adicionales que necesitan. A partir de 2026, UTF-8 es usado por más del 98% de todos los sitios web, convirtiéndolo en el estándar de facto para texto en internet.

Existen otras formas de codificación Unicode: UTF-16 usa dos o cuatro bytes por carácter y se usa internamente por JavaScript, Java y Windows. UTF-32 usa exactamente cuatro bytes por carácter, haciendo el acceso aleatorio trivial pero desperdiciando espacio para texto predominantemente ASCII. Para desarrollo web y la mayoría de aplicaciones modernas, UTF-8 es la elección clara.

Codificación de URL (codificación de porcentaje)

Las URLs solo pueden contener un conjunto limitado de caracteres ASCII. La especificación RFC 3986 define qué caracteres son “no reservados” y pueden aparecer en URLs sin tratamiento especial: letras mayúsculas y minúsculas, dígitos, guiones, puntos, guiones bajos y tildes. Todo lo demás—incluyendo espacios, caracteres especiales y caracteres no ASCII—debe ser “codificado en porcentaje.”

La codificación de porcentaje reemplaza cada byte de la representación UTF-8 del carácter con un signo de porcentaje seguido de dos dígitos hexadecimales. Por ejemplo, un espacio se convierte en %20, el signo arroba se convierte en %40, y la e con acento agudo (é, bytes UTF-8 0xC3 0xA9) se convierte en %C3%A9. Esto asegura que las URLs permanezcan válidas incluso cuando incluyen caracteres que tienen significado especial en la sintaxis de URL (como ?, &, = y #).

Escenarios comunes donde la codificación de URL es esencial:

• Parámetros de consulta: Al pasar entrada del usuario en URLs (ej., consultas de búsqueda), los caracteres especiales deben codificarse para evitar que se interpreten como delimitadores de URL.
• Envios de formularios: Los formularios HTML con method="GET" codifican los datos del formulario en la URL usando el formato application/x-www-form-urlencoded, donde los espacios se convierten en signos + (una peculiaridad histórica) y otros caracteres especiales se codifican en porcentaje.
• Nombres de dominio internacionalizados: Los nombres de dominio no ASCII usan codificación Punycode (un sistema separado de la codificación de porcentaje) para representar nombres de dominio Unicode en forma compatible con ASCII.
• Solicitudes de API: Los endpoints de API REST y sus parámetros frecuentemente incluyen caracteres especiales codificados, particularmente al transmitir JSON, fechas o rutas de archivos como parámetros de consulta.

En JavaScript, encodeURIComponent() codifica una cadena para su inclusión segura en un componente de URL, mientras que decodeURIComponent() revierte el proceso. Nuestras Herramientas de Texto incluyen utilidades de codificación y decodificación de URL que te permiten codificar o decodificar rápidamente cualquier cadena.

Base64: codificando binario como texto

Base64 es una codificación de binario a texto que representa datos binarios arbitrarios usando 64 caracteres ASCII imprimibles; así es como las imágenes, los archivos adjuntos de correo y los payloads binarios viajan de forma segura por canales de solo texto como JSON, los URIs de datos y el correo electrónico. Una advertencia que conviene repetir: Base64 no es encriptación—cualquiera puede decodificarlo al instante, así que nunca confíes en él para proteger contraseñas, claves o datos sensibles. Para conocer el algoritmo completo, la sobrecarga del 33% en tamaño, las variantes y ejemplos de código, lee nuestra guía de Codificación Base64 Explicada, o prueba a codificar imágenes directamente con nuestro Codificador de Imágenes Base64.

Conjuntos de caracteres, collation y errores de codificación comunes

Un conjunto de caracteres define qué caracteres están disponibles (ej., Unicode define más de 154,000 caracteres). Una codificación define cómo esos caracteres se representan como bytes (ej., UTF-8, UTF-16). La collation define cómo los caracteres se ordenan y comparan—si “a” es igual a “A,” si “ä” se ordena junto a “a” o después de “z,” y cómo se aplican las reglas de ordenamiento específicas de cada idioma. Estos tres conceptos son distintos pero frecuentemente confundidos, y equivocarse en cualquiera de ellos puede causar problemas sutiles y difíciles de depurar.

Mojibake es el término para el texto ilegible que aparece cuando el texto se decodifica usando la codificación incorrecta. Por ejemplo, la secuencia de bytes UTF-8 para “é” (0xC3 0xA9) se mostrará como “é” si se decodifica incorrectamente como Windows-1252. Las causas comunes de mojibake incluyen:

• Declaración de charset faltante o incorrecta: Si una página HTML no incluye <meta charset="utf-8">, el navegador puede adivinar la codificación incorrecta.
• Desajuste de codificación en la base de datos: Una base de datos MySQL configurada en latin1 que recibe datos UTF-8 corromperá los caracteres multi-byte. Siempre usa utf8mb4 en MySQL para soportar el rango completo de Unicode incluyendo emoji.
• Archivo guardado en codificación incorrecta: Un archivo CSV guardado como Windows-1252 pero abierto como UTF-8 (o viceversa) mostrará caracteres especiales corruptos.
• Doble codificación: Aplicar la codificación UTF-8 dos veces convierte “é” en una secuencia de cuatro bytes que se muestra como “é”—una señal reveladora de doble codificación.
• Respuesta de API sin charset en Content-Type: Si una API devuelve JSON sin especificar Content-Type: application/json; charset=utf-8, el cliente puede interpretar la respuesta usando una codificación predeterminada que no coincide.

Al depurar problemas de codificación, las herramientas que te permiten inspeccionar los valores de bytes crudos del texto son invaluables. Nuestras Herramientas de Texto pueden ayudarte a examinar códigos de caracteres, convertir entre formatos y aislar problemas de codificación. Para datos estructurados, nuestro Formateador de JSON validará y formateará payloads JSON para que puedas detectar secuencias Unicode escapadas como \u00e9. Puedes aprender más sobre las mejores prácticas de JSON en nuestra Guía de Formato y Validación JSON.

Codificación en APIs y desarrollo web

Para los desarrolladores web, la codificación aparece en prácticamente cada capa del stack. Aquí hay una lista de verificación de mejores prácticas de codificación que te salvarán de los errores más comunes:

1. Siempre declara UTF-8: Incluye <meta charset="utf-8"> como el primer elemento dentro de <head> en cada documento HTML. Establece Content-Type: text/html; charset=utf-8 en los encabezados de tu servidor.
2. Configura tu base de datos correctamente: Usa el conjunto de caracteres utf8mb4 y la collation utf8mb4_unicode_ci en MySQL. En PostgreSQL, UTF-8 es la codificación predeterminada y recomendada.
3. Establece Content-Type en respuestas de API: Siempre incluye el charset en el encabezado Content-Type de tu API: application/json; charset=utf-8.
4. Codifica la entrada del usuario en URLs: Usa encodeURIComponent() en JavaScript (o su equivalente en tu lenguaje) antes de insertar valores proporcionados por el usuario en URLs.
5. Ten cuidado con la longitud de cadenas: En UTF-8, un solo carácter puede ser de 1 a 4 bytes. En JavaScript, los caracteres fuera del Plano Multilingüe Básico (como los emoji) se representan como pares sustitutos y tienen un .length de 2, no de 1. Usa Array.from(str).length o el operador spread para obtener el conteo real de caracteres.
6. Maneja el BOM (Marca de Orden de Bytes) correctamente: Los archivos UTF-8 a veces comienzan con los bytes 0xEF 0xBB 0xBF (el BOM). Aunque es opcional en UTF-8, algunas herramientas lo insertan automáticamente. Si tu parser falla en el primer carácter de un archivo, un BOM oculto puede ser el culpable.
7. Prueba con entrada diversa: Prueba tu aplicación con emoji, caracteres CJK, texto de derecha a izquierda (árabe, hebreo) y caracteres combinados (como letras acentuadas construidas a partir de una letra base más un acento combinante). Si tu aplicación maneja estos correctamente, manejará prácticamente cualquier cosa.

Para más técnicas de procesamiento de texto orientadas a desarrolladores, nuestro artículo Herramientas de Texto que Todo Desarrollador Necesita cubre una amplia gama de utilidades desde la conversión de mayúsculas hasta el conteo de palabras y mucho más.

Comienza a trabajar con herramientas de codificación

La codificación es uno de esos temas fundamentales que toca cada parte del desarrollo de software, desde cómo se almacenan los archivos en disco hasta cómo las APIs transmiten datos a través de internet. Ya sea que estés depurando mojibake en una base de datos, construyendo parámetros de URL para una llamada de API o convirtiendo una imagen a un URI de datos Base64, una comprensión sólida de los sistemas de codificación te ahorrará incontables horas de frustración.

Prueba nuestro Codificador de Imágenes Base64 para convertir imágenes a URIs de datos al instante, o usa nuestras Herramientas de Texto para codificación de URL, inspección de caracteres y otras transformaciones de texto. Todas las herramientas se ejecutan completamente en tu navegador—ningún dato se sube a ningún servidor y no hay nada que registrar. Guárdalas en tus marcadores y tenlas en tu kit de herramientas de desarrollador para la próxima vez que surja un problema de codificación.