Texto con caracteres mal codificados en una página web

Por qué los acentos no se muestran bien en HTML y cómo solucionarlo

Uno de esos problemas que siguen apareciendo constantemente en desarrollo web es encontrarte caracteres raros donde deberían aparecer acentos, eñes o símbolos normales. El típico España, información o textos directamente ilegibles que aparecen después de una migración, una importación de base de datos o simplemente al subir una web al servidor.

Aunque pueda parecer algo antiguo, me topo con este problema de manera bastante habitual. Sobre todo en proyectos que han pasado por distintos servidores, herramientas o CMS como WordPress.

Si bien es imposible contemplar todos los casos, normalmente en su mayoría la causa es una codificación de caracteres mal configurada en algún punto del proyecto. Así que vamos a dar un repaso a los sospechosos habituales.

La solución más habitual: usar UTF-8

Lo primero que conviene revisar es que el documento HTML esté declarando correctamente UTF-8. En la mayoría de casos basta con incluir la etiqueta correspondiente dentro del <head>:

<meta charset="UTF-8">

Parece una tontería, pero todavía es relativamente frecuente encontrar proyectos antiguos que siguen funcionando con otras codificaciones o incluso páginas que directamente no especifican ninguna. UTF-8 es el estándar actual y evita prácticamente todos los problemas relacionados con caracteres especiales.

El problema no siempre está en el HTML

Aquí es donde mucha gente pierde tiempo. Añades correctamente el meta charset y el problema sigue exactamente igual. Eso ocurre porque la codificación puede romperse en distintos puntos del flujo.

Por ejemplo, es bastante común que el archivo haya sido guardado con otra codificación distinta. Aunque el navegador interprete el documento como UTF-8, si el fichero se guardó originalmente en ANSI o ISO-8859-1, los caracteres ya estarán mal antes incluso de llegar al navegador.

En Visual Studio Code, por ejemplo, puede comprobarse fácilmente desde la parte inferior derecha del editor, y normalmente merece la pena asegurarse de que todos los archivos del proyecto estén guardados directamente como UTF-8.

Bases de datos y conexiones

Otro caso muy habitual aparece en bases de datos antiguas o migraciones entre servidores. Ahí el problema puede venir tanto de la propia base de datos como de las tablas o incluso de la conexión utilizada desde PHP.

Hoy en día lo recomendable es trabajar directamente con utf8mb4, que además permite almacenar correctamente emojis y otros caracteres especiales que el antiguo utf8 de MySQL no gestionaba del todo bien.

Por ejemplo, una conexión PDO en PHP correctamente configurada sería algo así:

$pdo = new PDO(
'mysql:host=localhost;dbname=miweb;charset=utf8mb4',
'usuario',
'password'
);

También ocurre a veces que el servidor está enviando una cabecera con una codificación distinta a la que espera el navegador. En esos casos puede forzarse desde PHP:

header('Content-Type: text/html; charset=UTF-8');

Mi recomendación es que, si no lo tienes claro, empieces mirando directamente en la base de datos. Accede por ejemplo desde PHPMyAdmin y mira la codificación que se está usando.

El clásico error ñ

El caso más reconocible suele ser cuando aparece algo como España. Normalmente eso significa que el texto estaba realmente en UTF-8, pero en algún punto se interpretó como ISO-8859-1 o Latin-1. Es probablemente el síntoma más típico de un problema de codificación.

Lo complicado de estos errores es que muchas veces funcionan «casi bien». Puede que en local todo se vea correctamente y el problema aparezca solo en producción, o únicamente con ciertos textos concretos. Por eso, cuando aparece este tipo de fallo, merece la pena revisar todo el recorrido completo de los datos:

  1. Cómo está guardado el archivo.
  2. Qué codificación usa la base de datos.
  3. Cómo se realiza la conexión desde PHP.
  4. Qué cabeceras devuelve finalmente el servidor.

Muchas veces, y te lo digo por experiencia, el problema no está donde parece y puedes perder bastante tiempo tocando el HTML cuando el fallo real viene de una importación antigua o de una tabla mal configurada. Pero cuando todo el proyecto utiliza UTF-8 de forma consistente, estos problemas suelen desaparecer por completo.

Jesús Tovar - Desarrollador web freelance Sevilla

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *