Unicode y codificación de caracteres: por qué tu software se rompe en otros idiomas

Unicode es el estándar que da a cada carácter de cada sistema de escritura, de la "A" a la "あ" pasando por el "🚀", un número único. La codificación de caracteres es el paso aparte que convierte esos números en bytes que un ordenador puede guardar y enviar. La mayoría del software que "se rompe en otros idiomas" no está fallando en la traducción. Falla en esta capa anterior, invisible, y el fallo tiene nombre: mojibake, el texto ilegible que sale cuando los bytes se releen con la codificación equivocada.

Prometimos mirar de cerca esa avería en el desarrollo de software multilingüe y en la internacionalización (i18n), donde un cliente apellidado Muñoz se convierte en "Muñoz" en una etiqueta o en una factura. Aquí lo diseccionamos: cómo ocurre exactamente, los puntos donde los fallos de codificación cuestan dinero de verdad a una empresa, y qué exige "UTF-8 en todas partes" en un sistema real.

Unicode y UTF-8 no son lo mismo

Los dos términos se usan indistintamente, y esa costumbre está en la raíz de casi toda la confusión.

Unicode es un mapa. Asigna a cada carácter un punto de código: un número, escrito U+XXXX. La letra "A" es U+0041. La "ñ" es U+00F1. El carácter chino "中" es U+4E2D. El mapa por sí solo no dice cómo guardar ese número en bytes en un disco ni cómo enviarlo por una red.

UTF-8 es una forma de codificar ese mapa en bytes. Es la dominante: UTF-8 transporta hoy el 99 % de todos los sitios web cuya codificación se conoce (W3Techs, 2026). Representa cada punto de código con entre 1 y 4 bytes: las letras y cifras sin acento ocupan 1 byte (idéntico al viejo ASCII, y por eso UTF-8 es retrocompatible con él), los caracteres latinos acentuados y la eñe suelen ocupar 2 bytes, la mayoría de los caracteres chinos, japoneses y coreanos ocupan 3, y los emojis ocupan 4.

Las codificaciones más antiguas hacen corresponder los mismos valores de byte a caracteres completamente distintos. Windows-1252 y Latin-1 (ISO-8859-1), ambas frecuentes en los sistemas Windows antiguos y en bases de datos heredadas, usan un solo byte por carácter y solo cubren las escrituras de Europa occidental. Dale bytes UTF-8 a un software que espera Windows-1252, o al revés, y obtienes una salida de apariencia válida pero silenciosamente equivocada. Ese desajuste es el mojibake, y es del todo mecánico: nada se "corrompe" en el sentido de datos perdidos, los mismos bytes se releen con el manual de reglas equivocado.

El mojibake, explicado: cómo "Muñoz" acaba escrito "Muñoz"

Recorre los bytes reales y el fallo deja de parecer un misterio.

En UTF-8, la "ñ" se codifica en dos bytes: 0xC3 0xB1. "Muñoz" en UTF-8 es, por tanto, la secuencia de bytes de M, u, luego 0xC3 0xB1, y luego o y z.

Supón ahora que esa secuencia de bytes se entrega a un sistema que la lee como Windows-1252 en lugar de UTF-8, un desajuste que pasa constantemente cuando los datos cruzan entre una aplicación moderna y una base de datos, una herramienta de exportación o un sistema de un socio más antiguos. Windows-1252 no sabe que esos dos bytes forman un solo carácter. Los lee como dos caracteres separados: 0xC3 se muestra como "Ã" y 0xB1 como "±". La sola letra "ñ" se convierte en la secuencia de dos caracteres "ñ", y "Muñoz" pasa a ser "Muñoz" en la pantalla, la etiqueta o la factura.

El mismo mecanismo produce todos los demás patrones de mojibake que seguramente has visto: comillas tipográficas que se vuelven cadenas como “, o una raya que se convierte en â€". Cada caso son los bytes de una codificación leídos con el manual de otra. En cuanto sabes nombrar las dos codificaciones en conflicto, el arreglo suele ser un cambio de configuración, no una reescritura.

El caso del euro, que es europeo y es real

Hay un carácter que un negocio español toca todos los días y que la codificación heredada trata fatal: el símbolo del euro.

El euro (U+20AC) llegó al mundo después de que se publicara ISO-8859-1, así que sencillamente no existe en esa tabla. Latin-1 no puede representar el símbolo de la moneda de la mitad del continente. Windows-1252 lo metió por su cuenta en la posición 0x80, un hueco que Latin-1 deja sin usar, y más tarde se publicó ISO-8859-15, también llamado Latin-9, justo para arreglar esa carencia, en otra posición. Resultado práctico: un mismo importe puede pasar por tres sistemas y perder el símbolo por el camino, o cambiarlo por otro carácter, sin que nada dé error.

Ese es el argumento entero en un carácter. La codificación no es una preocupación de gente que exporta a Asia. Es la razón por la que un importe europeo se pinta mal en un PDF generado con una biblioteca configurada en 1998.

Dónde muerden de verdad los fallos de codificación a una empresa

El mojibake en pantalla es el síntoma visible, y el español, lleno de acentos y eñes, lo delata antes que muchos otros idiomas. Los fallos más caros pasan por debajo.

• Nombres corrompidos en documentos de cara al cliente. Etiquetas de envío, facturas y contratos donde el apellido de un cliente aparece como "Muñoz" en vez de "Muñoz" parecen descuidados en el mejor de los casos, y llegan a la dirección equivocada en el peor, un riesgo real en la documentación aduanera y datos de transportistas de la logística, donde el nombre y la dirección de un DUA tienen que coincidir al carácter con lo declarado.
• Búsquedas y consultas rotas. Si un nombre se guarda con una codificación y se busca con otra, las secuencias de bytes no coinciden, y una ficha de cliente perfectamente real devuelve cero resultados. Los equipos de soporte aprenden a sortearlo a mano mucho antes de que alguien diagnostique el desajuste de codificación que hay detrás.
• Truncado silencioso de datos. Una columna de base de datos dimensionada en bytes, no en caracteres, puede cortar un carácter multibyte por la mitad durante la inserción, corrompiendo el último carácter de un nombre o dejando una secuencia de bytes rota que falla en la validación más tarde, a menudo en una parte completamente distinta del sistema.
• Emojis y caracteres CJK que desaparecen sin más. El juego de caracteres que MySQL llamó históricamente utf8 nunca guardó más de 3 bytes por carácter, suficiente para la mayoría de los caracteres latinos, cirílicos y CJK comunes, pero no para los emojis ni algunos caracteres de extensión CJK, que necesitan 4. El texto que los contenía no salía revuelto; salía rechazado o truncado en silencio, hasta usar en su lugar la opción de UTF-8 completo real de MySQL, utf8mb4.
• Exportaciones heredadas que envenenan sistemas modernos. Un flujo CSV o EDI de un ERP viejo o de un sistema socio, que aún emite Windows-1252 por defecto, se importa limpio a primera vista y corrompe cada acento y cada eñe en cuanto alguien lo abre en una herramienta nativa de UTF-8.

Hay además una trampa propia de los equipos que trabajan en español, más retorcida de lo que parece. El español pasa: Latin-1 y Windows-1252 cubren á, é, í, ó, ú, ñ, ü, ¿ y ¡, así que una aplicación pensada para España funciona años sobre una codificación heredada sin que nadie note nada. La factura llega con el primer cliente llamado Wojciech, Öztürk o 田中, con el primer proveedor que envía un flujo en cirílico, o con el primer emoji en un campo de comentarios. Es exactamente por eso que los fallos de codificación se descubren tan a menudo en producción y no en las pruebas.

Las codificaciones heredadas que aún dan problemas

Tres codificaciones explican casi cada desajuste que un sistema de empresa todavía se encuentra: el ASCII puro (solo letras inglesas, cifras y puntuación básica, sin acentos, sin eñe y sin ninguna escritura no latina), Latin-1 / ISO-8859-1 (un byte por carácter, acentos de Europa occidental y ningún euro) y Windows-1252 (el casi-superconjunto de Latin-1 de Microsoft, el valor por defecto del software Windows antiguo y fuente frecuente del patrón de mojibake de las comillas tipográficas de arriba).

Persisten en sitios concretos y previsibles: bases de datos creadas hace años con un juego de caracteres por defecto que nadie revisó, exportaciones CSV de viejos sistemas de contabilidad o ERP, mensajes EDI de socios de logística y transporte que corren sobre formatos de hace décadas, y bibliotecas de generación de PDF que suponen un juego de caracteres estrecho salvo que se les diga lo contrario. Cada uno de estos puntos es una frontera donde los datos pasan de un sistema a otro, y las fronteras son justo donde las suposiciones de codificación quedan sin declarar y desajustadas.

Qué exige de verdad "UTF-8 en todas partes"

"Usa UTF-8 y ya está" es un consejo correcto que subestima el trabajo. Un soporte UTF-8 completo significa declararlo de forma explícita en cada capa, no dar por hecho que se propaga solo.

1. Juego de caracteres y colación de la base de datos. UTF-8 declarado en la base, en cada tabla y en cada columna, no solo en la conexión. En MySQL en concreto, eso significa utf8mb4, no el alias heredado utf8.
2. Cabeceras HTTP y de archivo. Cada respuesta de API y cada exportación de archivo declara su codificación de forma explícita (Content-Type: text/html; charset=utf-8), en vez de dejar que los clientes adivinen.
3. Exportaciones CSV con BOM cuando el destino es Excel. Excel suele leer un CSV UTF-8 pelado como Windows-1252 si no hay una marca de orden de bytes (BOM). Y en España se junta con su hermano: Excel en configuración española usa el punto y coma como separador de listas, porque la coma ya está ocupada haciendo de separador decimal, así que un CSV separado por comas se abre entero en una sola columna. Entre los dos suman la mayoría de los tickets de "¿por qué mi exportación se ve rota en Excel?".
4. Cobertura de glifos de la fuente. Un carácter cirílico o CJK bien codificado se muestra igualmente como un cuadro vacío ("tofu") si la fuente elegida no tiene glifo para él. Es un problema de diseño, no de codificación, pero para el usuario es idéntico.
5. Validación en cada frontera. Las subidas, las entradas de API y los flujos de datos de socios ven su codificación comprobada y normalizada a UTF-8 a la entrada, para que unos bytes revueltos no lleguen nunca al almacenamiento.

Acierta las cinco de una vez, a nivel de arquitectura, y la codificación de caracteres deja de ocupar a nadie. Falla una, y resurge como ticket de soporte cada vez que un nombre con acento, un emoji o una escritura no latina llega a esa frontera concreta.

Preguntas frecuentes sobre Unicode y la codificación de caracteres

¿Qué es Unicode?

Unicode es un estándar que asigna un número único, llamado punto de código, a cada carácter de cada sistema de escritura importante. Es un mapa de caracteres a números. No define, por sí solo, cómo se guardan esos números en bytes.

¿Cuál es la diferencia entre Unicode y UTF-8?

Unicode es el mapa de caracteres; UTF-8 es una codificación que convierte los puntos de código de Unicode en bytes, con 1 a 4 bytes por carácter. UTF-8 es la codificación dominante en la web actual, y transporta el 99 % de los sitios cuya codificación se conoce (W3Techs, 2026).

¿Qué es el mojibake?

El mojibake es el texto revuelto que se produce cuando unos bytes codificados en un juego de caracteres se releen con otro. Es mecánico, no aleatorio: el mismo desajuste de codificación produce siempre el mismo patrón revuelto, como "Muñoz" convertido en "Muñoz".

¿Por qué mi software muestra caracteres raros como "ñ" en lugar de la eñe?

Un componente del sistema, a menudo una base de datos, una herramienta de exportación o un flujo de un socio más antiguo, lee bytes UTF-8 como Windows-1252 o Latin-1. El arreglo consiste en localizar dónde ocurre el desajuste y ajustar ese componente a UTF-8 de forma explícita, no en volver a teclear los datos.

¿Cómo arreglo los problemas de codificación en un software que ya existe?

Audita cada frontera: juego de caracteres y colación de la base, exportaciones de archivo, cabeceras de API y flujos de datos de socios, y ajusta cada una a UTF-8 de forma explícita (utf8mb4 si la base es MySQL). Hacemos esta auditoría como parte de la definición del alcance en cada proyecto multilingüe; pide un presupuesto cerrado y va incluida.

Consigue un software que gestiona bien cada carácter

Cuéntanos qué tiene que admitir tu software, incluidos los nombres, las escrituras y los flujos de datos de socios que debe tratar correctamente. Respondemos con un alcance cerrado, un precio cerrado y una fecha de entrega.

Pide un presupuesto cerrado →