Usted creó una base de datos en phpMyAdmin, desplegó WordPress y una semana después notó texto ilegible en lugar de caracteres legibles en sus tablas. Abre la configuración y ve latin1_swedish_ci. Todo el que trabaja con Laragon en Windows se topa tarde o temprano con esta sorpresa.

El problema es que la compilación de MySQL que Laragon instala por defecto hereda una configuración predeterminada anticuada: latin1 como conjunto de caracteres y latin1_swedish_ci como cotejamiento. Para el ruso, esto es un desastre: los caracteres cirílicos se escriben como signos de interrogación o galimatías, la ordenación de cadenas se rompe y los plugins fallan con errores.

A continuación, dos cambios en un archivo que resolverán este problema de forma permanente. Lleva tres minutos. Funciona en Laragon 6, 5 e incluso en la antigua versión 4.

💡 Resumen rápido:

• Abra my.ini desde el menú de Laragon y añada dos líneas a la sección [mysqld]
• Elija utf8mb4_unicode_ci como la opción óptima para WordPress en 2026 (y le explicamos por qué)
• Guarde el archivo, reinicie MySQL y verifique el resultado en phpMyAdmin
• Extra: cómo cambiar la codificación de una base de datos existente sin perder datos

Por qué importa la codificación predeterminada

MySQL funciona con un sistema de herencia multinivel: servidor → base de datos → tabla → columna. Si latin1_swedish_ci está configurado a nivel de servidor, cada nueva base de datos lo heredará a menos que se especifique lo contrario durante la creación.

Para WordPress esto es crítico porque:

• El núcleo, los temas y la mayoría de los plugins almacenan contenido en utf8mb4
• Al crear automáticamente una base de datos mediante wp-config.php, WordPress NO anula el valor predeterminado del servidor
• La falta de coincidencia de codificación entre el servidor y las tablas produce errores «poco claros»: ??? en el panel de administración, caracteres rotos en la API REST JSON, fallos durante la exportación

Según datos de W3Techs, WordPress impulsa el 43,5% de todos los sitios web en internet, y el propio CMS exige utf8mb4 desde la versión 4.2 para el soporte completo de emojis. Laragon es uno de los servidores locales más populares para Windows, pero su compilación de MySQL se distribuye con un valor predeterminado conservador por compatibilidad con versiones anteriores. De ahí el conflicto.

Paso 1: Abrir my.ini desde el menú de Laragon

La forma más fácil de acceder al archivo de configuración de MySQL es a través del menú integrado de Laragon:

• Haga clic derecho en el icono de Laragon en la bandeja del sistema
• Seleccione Menú → MySQL → my.ini

Se abrirá el Bloc de notas (o su editor predeterminado) con la configuración completa de MySQL. El archivo está dividido en secciones entre corchetes: [client], [mysqld] y [mysqldump]. Nos interesa [mysqld] (la sección de configuración del demonio de MySQL).

Si por alguna razón el menú no abre el archivo, búsquelo manualmente en: C:\laragon\bin\mysql\<version>\my.ini. En las compilaciones de Laragon 6, la ruta puede ser C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, dependiendo de la versión instalada.

Paso 2: Añadir dos líneas a la sección [mysqld]

Desplácese hasta la sección [mysqld] y añada las dos líneas siguientes al final (antes de la siguiente sección, si la hay):

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Qué está sucediendo aquí:

• character_set_server = utf8mb4 indica al servidor que use la codificación UTF-8 Versión Multilingüe 4 por defecto, que soporta TODOS los caracteres Unicode, incluidos emojis, cirílicos y jeroglíficos
• collation_server = utf8mb4_unicode_ci establece la regla de comparación de cadenas: _unicode_ significa «según el estándar Unicode», _ci significa comparación sin distinción de mayúsculas y minúsculas

Debe añadir estas líneas específicamente a [mysqld], no a [client] ni a [mysqldump]. Usar la sección incorrecta es la razón más común por la que «no cambió nada».

La sección completa después de la edición debería verse más o menos así:

1
[mysqld]
2
port=3306
3
socket=/tmp/mysql.sock
4
key_buffer_size=256M
5
max_allowed_packet=512M
6
character_set_server = utf8mb4
7
collation_server = utf8mb4_unicode_ci

Paso 3: Guardar el archivo y reiniciar MySQL

Guarde my.ini (Ctrl+S) y reinicie MySQL. En Laragon, esto se hace a través del mismo menú:

• Haga clic derecho en el icono de Laragon en la bandeja del sistema
• Menú → MySQL → Detener
• Espere de 3 a 5 segundos
• Menú → MySQL → Iniciar

Alternativamente, haga clic en Menú → Reiniciar y Laragon detendrá e iniciará todos los servicios a la vez.

Después del reinicio, las nuevas bases de datos se crearán con utf8mb4_unicode_ci por defecto. Las bases de datos existentes NO se modifican automáticamente. Lea la sección «Preguntas frecuentes» a continuación para saber cómo convertir una base de datos existente.

Paso 4: Verificar el resultado en phpMyAdmin

Abra phpMyAdmin a través del menú de Laragon (Menú → MySQL → phpMyAdmin) y cree una base de datos de prueba:

• Haga clic en «Crear base de datos»
• Introduzca cualquier nombre
• Observe el desplegable «Cotejamiento»: ahora debería mostrar por defecto utf8mb4_unicode_ci

Si el desplegable aún muestra latin1_swedish_ci, verifique que las líneas character_set_server y collation_server se hayan añadido a la sección [mysqld] (no a [client]) y que no haya espacios adicionales entre el nombre del parámetro y el signo =.

Verificación rápida mediante consulta SQL (ejecutar en phpMyAdmin en la pestaña SQL):

1
SHOW VARIABLES LIKE 'character_set_server';
2
SHOW VARIABLES LIKE 'collation_server';

Ambas variables deberían devolver utf8mb4 y utf8mb4_unicode_ci respectivamente.

Qué codificación elegir: comparación de opciones

La codificación de MySQL ha acumulado muchos mitos, así que analicemos tres opciones actuales y una obsoleta:

Por qué recomendamos utf8mb4_unicode_ci para el desarrollo local en Laragon:

• Laragon se distribuye con diferentes versiones de MySQL (de 5.7 a 8.0+), y utf8mb4_0900_ai_ci solo apareció en MySQL 8.0 y está ausente en MariaDB, que a menudo viene en compilaciones alternativas
• utf8mb4_unicode_ci funciona en todas partes a partir de MySQL 5.5.3 (2010)
• La diferencia en la calidad de ordenación entre unicode_ci y 0900_ai_ci es insignificante para un sitio WordPress típico
• Los planes de hosting compartido a menudo usan MySQL 5.7. Si desarrolla localmente con 0900_ai_ci pero falta en producción, obtendrá un error durante la migración

Si sabe con certeza que su servidor de producción ejecuta MySQL 8.0+ y su Laragon local usa MySQL 8.0, opte por utf8mb4_0900_ai_ci. Este es el estándar moderno recomendado por Oracle, con mejor soporte de ordenación multilingüe.

¿Y qué pasa con utf8_general_ci? Era relevante hace unos diez años, cuando utf8mb4 aún no tenía soporte generalizado. Hoy tiene dos fallos fatales: no puede almacenar emojis (WordPress los usa activamente en el panel de administración) y ordena incorrectamente los caracteres extendidos. No hay razón para usarlo en 2026.

Vídeo: cómo cambiar la codificación de la base de datos MySQL mediante phpMyAdmin

Las instrucciones de texto son geniales, pero a veces es más fácil verlo una vez. Este vídeo de 4 minutos muestra el proceso completo de cambio de codificación de una base de datos existente a través de la interfaz de phpMyAdmin, desde la selección de tablas hasta la verificación final:

⁉️🤔 Preguntas frecuentes

Ya tengo una base de datos con latin1_swedish_ci. ¿Cómo cambio su codificación?

La forma más segura es a través de phpMyAdmin. Seleccione la base de datos a la izquierda, vaya a la pestaña «Operaciones», elija utf8mb4_unicode_ci en el bloque «Cotejamiento» y haga clic en «Continuar». phpMyAdmin generará consultas ALTER para cada tabla. Antes de esta operación, asegúrese de crear una copia de seguridad: pestaña «Exportar» → formato SQL → «Continuar».

Cambié my.ini, reinicié MySQL, pero phpMyAdmin aún muestra latin1_swedish_ci. ¿Qué está mal?

Tres causas más comunes: (1) las líneas se añadieron a [client] en lugar de a [mysqld]. Verifique bajo qué sección de corchetes se encuentran. (2) MySQL no se reinició. Abra el Administrador de tareas de Windows y verifique que el proceso mysqld.exe desapareció y reapareció. (3) Hay múltiples secciones [mysqld] en my.ini. Esto a veces sucede después de varias actualizaciones de Laragon. Conserve solo una.

¿Qué es mejor para WordPress: utf8mb4_unicode_ci o utf8mb4_general_ci?

Para WordPress, la diferencia es mínima. utf8mb4_unicode_ci ordena el contenido multilingüe con mayor precisión (por ejemplo, la «ß» alemana = «ss»), mientras que utf8mb4_general_ci es ligeramente más rápido en grandes volúmenes, pero la diferencia es de milisegundos. Elija unicode_ci y no se preocupe.

¿Puedo simplemente especificar la codificación en wp-config.php?

define('DB_CHARSET', 'utf8mb4') y define('DB_COLLATE', 'utf8mb4_unicode_ci') en wp-config.php afectan SOLO a las tablas que el propio WordPress crea durante la instalación. El valor predeterminado del servidor permanece sin cambios, y cualquier base de datos creada manualmente a través de phpMyAdmin obtendrá latin1_swedish_ci. Por eso sigue siendo necesario editar my.ini.

Después de cambiar la codificación, parte del texto del sitio se convirtió en signos de interrogación. ¿Es reversible?

Sí, pero debe proceder con cuidado. Los signos de interrogación aparecen cuando los datos se escribieron en latin1 pero se leen como utf8. La solución: exporte la base de datos con el flag --default-character-set=latin1, luego importe con --default-character-set=utf8mb4. El comando exacto depende de su versión de MySQL, así que consulte la documentación oficial.

Resumen: qué añadir a my.ini ahora mismo

Si usa Laragon para el desarrollo local de WordPress, las dos líneas a continuación resolverán el problema de codificación de una vez por todas:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Esta opción funciona en cualquier versión de MySQL desde la 5.5 hasta la 8.4 y en todas las compilaciones actuales de MariaDB. Almacena correctamente cirílico, emojis y no crea sorpresas al migrar la base de datos de local a producción, independientemente del hosting en el que se ejecute su servidor de producción.

¿Tiene preguntas sobre una versión específica de Laragon o una configuración no estándar? Consulte el hilo en el foro de Laragon, donde los desarrolladores discuten los matices de la configuración de codificación, incluidas las compilaciones de Docker y los puertos personalizados. Y si este artículo le ahorró una tarde, compártalo con colegas que también estén lidiando con latin1_swedish_ci.