Caracteres especiales en WordPress UTF-8

8 ene 2012, 06:00:51
Vistas: 18.6K
Votos: 5

Tengo un problema con los caracteres especiales que aparecen mal en el front-end. Principalmente se convierten en signos de interrogación o algo como �?).

Ejemplo - Frédèric se convierte en Fr�d�ric.

Algunos hechos que me tienen desconcertado:

  • Esta instalación de WordPress está en una máquina LOCAL y comparte el servidor con al menos otras 40 instalaciones - ninguna de las cuales tiene este problema.

  • Esta instalación de WordPress también comparte la misma base de datos que las demás.

  • Mi archivo wp-config tiene definido el collate y charset.

  • La base de datos parece estar bien, porque cuando veo la publicación en el EDITOR (back end) - todo es correcto, el problema solo está en el FRONT end.

    • La base de datos parece estar bien (2), abriendo la publicación en phpMyAdmin y verificando el valor directo - todos los caracteres están bien.
  • Este problema NO es de codificación del navegador/os, se verificó en 4 máquinas diferentes, 3 sistemas operativos y 9 navegadores.

He probado todas las soluciones que conozco por experiencia previa, que incluyen:

  • Verificar el wp-config (está bien, utf-8 definido, collate ok)
  • Verificar la base de datos - todo UTF-8
  • Verificar mi header (<?php bloginfo('charset'); ?>) - eso se renderiza correctamente como utf-8 con marcado válido.
  • Abrir todos los archivos del tema en mi editor, convertir la codificación a UTF-8 sin bom y guardar.

¿Me faltó algo? ¿Alguna idea?

11
Comentarios

¿Y tus archivos están escritos/guardados en UTF-8 (Temas, Plugins)?

kaiser kaiser
8 ene 2012 07:23:06

sip - ya lo escribí en la pregunta misma. UTF-8 sin BOM

User User
8 ene 2012 07:23:44

Escribiste "Tema", no plugins. ¿Seguro que has desactivado todos los plugins?

kaiser kaiser
8 ene 2012 07:24:39

no. No desactivé ningún plugin, porque no hay ninguno instalado (bueno, quizás askimet o hello dolly - pero no están activados)

User User
8 ene 2012 08:06:05

La única situación en la que me encontré con algo similar fue con los resultados de Google Geocoding ya que no están definidos. La solución fue convertir todo a utf-8 en el hook pre_save.

kaiser kaiser
8 ene 2012 17:33:27

¿Por qué la etiqueta htmlspecialchars-decode? ¿Ocurre el mismo problema con TwentyEleven?

fuxia fuxia
8 ene 2012 18:14:42

@ Kaiser - gracias, SÍ tengo funciones relacionadas con google.maps que escribí... Lo revisaré, aunque NINGUNA de ellas se invoca realmente. @toscho - la etiqueta es porque PODRÍA estar relacionado con un problema en la decodificación y codificación de caracteres especiales html. Y sí, también ocurre con TwentyEleven.

User User
9 ene 2012 07:16:29

ACTUALIZACIÓN - todavía no tengo idea de cuál es el problema... Pero usé mb_convert_encoding() de php. No es ideal, por supuesto, y todavía me gustaría saber POR QUÉ ocurrió para evitar problemas futuros, así que si alguien tiene una idea/solución - por favor publíquenla.

User User
17 ene 2012 08:10:35

Hola @Obmerkronen, suena fascinante. Esto es lo que intentaría si aún no lo has hecho: Ejecuta una instalación limpia de WordPress en una nueva base de datos y verifica que los caracteres UTF-8 funcionen. Si es así, cambia wp-config.php para usar la base de datos de tu instalación, que llamaremos "corrupta". Si la instalación limpia funciona con su propia base de datos pero no con la base de datos "corrupta", sabrás que es tu base de datos. Si la instalación limpia funciona con ambas, sabrás que son los archivos en la instalación "corrupta". Si la instalación limpia no funciona, lo más probable es que sea una configuración de PHP o MySQL (lo cual es posible incluso si otras instalaciones antiguas funcionan). ¡Déjame saber qué pasa!

Matthew Boynes Matthew Boynes
30 ene 2012 03:38:59

@ Matthew Boynes - ¡gracias por tu interés! De hecho, ya hice esta comprobación cuando estaba lidiando con el problema - en una instalación limpia seguía teniendo la misma patología - incluso sin cambiar nada y sin funciones adicionales (excepto las que escribí, que son totalmente irrelevantes e inofensivas... Desde entonces he pasado a otro proyecto, pero en cuanto pueda, intentaré entender por qué sucedió.

User User
1 feb 2012 08:18:18

Puede ser tu servidor. ¿Tienes un archivo .htaccess para el dominio o la carpeta donde está instalado WordPress?

Donald Jenkins Donald Jenkins
17 feb 2012 02:06:27
Mostrar los 6 comentarios restantes
Todas las respuestas a la pregunta 2
3

Editar:

¿Tienes <meta charset="utf-8" /> en tu etiqueta <head>? Un usuario aquí resolvió un problema similar con la codificación de caracteres añadiendo esto.

De hecho, hay muchos resultados en Google que aparecen al buscar utf-8 character encoding in wordpress.

Además, ¿hace alguna diferencia pegar el texto en la vista HTML del editor y guardarlo?


Lo siguiente no es una idea tan buena como @toscho explicó en los comentarios.

No estoy seguro si este es el mejor método para solucionar el problema, pero esto funcionó para uno de los sitios web de mis clientes.

Encuentra estas dos líneas en tu archivo wp-config.php:

define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

Y coméntalas así:

//define('DB_CHARSET', 'utf8');
//define('DB_COLLATE', '');
20 feb 2012 21:55:53
Comentarios

Ahora corres el riesgo de obtener codificaciones guardadas mezcladas. No es una buena idea.

fuxia fuxia
20 feb 2012 22:24:33

@toscho Correcto, estoy buscando en la web una mejor solución y actualizaré mi respuesta pronto.

Jared Jared
20 feb 2012 22:28:53

<meta charset="utf-8" />

Añadir esto funcionó para mí.

Rahul Rahul
17 ago 2017 10:46:10
0

¿Estás usando htmlentities() para escapar tu salida por casualidad? Si es así, necesitas definir 'UTF-8' como el tercer parámetro.

21 feb 2012 22:48:41