Estás intentando importar una base de datos en phpMyAdmin, en Plesk, en un hosting nuevo o durante una migración de WordPress y, de repente, aparece un error raro relacionado con utf8mb4_general_ci, una collation desconocida o una mezcla de collations.
Y claro, aquí suele empezar el susto. Porque no estás tocando una imagen, un plugin o un texto cualquiera: estás tocando la base de datos. Es decir, el sitio donde viven entradas, páginas, ajustes, usuarios, pedidos, formularios y buena parte de lo que hace funcionar la web.
La buena noticia es que muchos errores relacionados con utf8mb4_general_ci, MySQL o MariaDB al importar una base de datos tienen solución. La mala es que no conviene arreglarlos a lo bruto sin saber qué se está cambiando.
Respuesta rápida: si al importar una base de datos aparece un error relacionado con utf8mb4_general_ci, normalmente hay un problema de compatibilidad entre el juego de caracteres, la collation usada en el archivo SQL y las collations soportadas por el servidor destino. La solución suele pasar por revisar la versión de MySQL o MariaDB, hacer copia del archivo SQL y sustituir la collation conflictiva por otra compatible.
En esta guía vas a ver: qué significa utf8mb4_general_ci, por qué puede fallar al importar una base de datos, qué diferencia hay entre charset y collation, qué errores son habituales en migraciones WordPress y cómo revisar el archivo SQL sin romper nada por el camino.
Qué es utf8mb4_general_ci
utf8mb4_general_ci es una collation utilizada en bases de datos MySQL y MariaDB. Dicho de forma sencilla, forma parte de la configuración que indica cómo se comparan y ordenan los textos dentro de una base de datos.
Para entenderlo mejor, conviene separar dos conceptos que suelen aparecer juntos:
| Concepto | Qué significa |
|---|---|
| Charset | Define el conjunto de caracteres que puede guardar la base de datos. Por ejemplo, letras, números, símbolos, acentos o emojis. |
| Collation | Define cómo se comparan y ordenan esos caracteres. Por ejemplo, si distingue mayúsculas, acentos o determinadas reglas de idioma. |
En este caso, utf8mb4 es el juego de caracteres y general_ci es la collation. La parte ci significa case insensitive, es decir, que no distingue entre mayúsculas y minúsculas al comparar textos.
Esto no es algo exclusivo de WordPress. Es una configuración propia de MySQL y MariaDB, pero aparece mucho en webs WordPress porque WordPress guarda casi todo su contenido en una base de datos.
Por qué aparece este error al importar una base de datos
El error suele aparecer cuando exportas una base de datos desde un servidor y la intentas importar en otro que no trabaja exactamente igual.
Puede pasar al mover una web de hosting, al restaurar una copia antigua, al pasar de un servidor con MySQL a otro con MariaDB, al importar una base desde phpMyAdmin o al trabajar con versiones distintas del motor de base de datos.
En proyectos reales, el caso típico suele ser este:
- Exportas la base de datos desde un hosting antiguo.
- Intentas importarla en un servidor nuevo.
- El servidor nuevo no reconoce una collation concreta o no la gestiona igual.
- La importación se detiene con un error.
A veces el error menciona directamente utf8mb4_general_ci. Otras veces el problema aparece con collations más nuevas, como utf8mb4_0900_ai_ci, al intentar importar en servidores que no las soportan.
Importante: no todas las collations están disponibles en todas las versiones de MySQL y MariaDB. Por eso una base que funciona perfectamente en un servidor puede fallar al importarse en otro.
Errores habituales relacionados con utf8mb4 y collations
El mensaje exacto puede variar según el servidor, phpMyAdmin, Plesk, la consola o la herramienta de importación que estés usando.
Estos son algunos errores habituales relacionados con este problema:
| Error o situación | Qué suele indicar |
|---|---|
| Unknown collation | El servidor destino no reconoce la collation indicada en el archivo SQL. |
| utf8mb4_general_ci | La base usa esa collation y puede haber conflicto con la configuración del servidor destino. |
| utf8mb4_0900_ai_ci | Muy habitual al exportar desde MySQL 8 e importar en servidores que no soportan esa collation. |
| Illegal mix of collations | Hay columnas, tablas o consultas mezclando collations distintas de forma conflictiva. |
| Error al importar SQL en phpMyAdmin | La importación se corta porque encuentra una instrucción no compatible con el servidor destino. |
El mensaje puede parecer muy técnico, pero la idea de fondo suele ser la misma: el archivo SQL viene con una configuración de caracteres o comparación de textos que el servidor destino no acepta tal como está.
MySQL, MariaDB y el lío de las collations
MySQL y MariaDB se parecen mucho, pero no son exactamente lo mismo. Durante años han compartido muchas bases, pero han ido evolucionando por caminos diferentes. Esto afecta también a los juegos de caracteres y collations disponibles.
Por ejemplo, una base exportada desde un servidor con MySQL 8 puede incluir collations que no existen en una versión antigua de MariaDB. Y al revés, un servidor MariaDB moderno puede usar configuraciones que no coincidan con las de otro entorno más antiguo.
Por eso estos errores aparecen tanto en migraciones, restauraciones y cambios de hosting. No siempre hay un problema “grave” en la base de datos. A veces simplemente estás intentando meter una exportación moderna en un servidor que no entiende esa misma configuración.
El problema no suele ser que la web esté rota. El problema es que origen y destino no hablan exactamente el mismo idioma de base de datos.
Antes de tocar nada: haz una copia del archivo SQL
Aquí nos toca ponernos un poco serios. Antes de editar una base de datos, aunque sea un simple archivo .sql, haz una copia.
No edites el único archivo que tienes. No hagas sustituciones masivas sin guardar una versión original. No importes encima de una base en producción sin saber qué va a pasar.
Una forma prudente de trabajar sería:
- Guardar una copia original del archivo SQL exportado.
- Crear una segunda copia para pruebas.
- Revisar qué collation está provocando el error.
- Sustituir solo lo necesario.
- Importar primero en un entorno de prueba si es posible.
- Comprobar que la web carga, los textos se ven bien y no hay caracteres raros.
Consejo ideaWeb: si el archivo SQL pesa mucho, no lo abras con un editor básico que pueda quedarse colgado o guardar mal la codificación. Usa un editor preparado para archivos grandes.
Cómo comprobar la versión de MySQL o MariaDB
Antes de decidir qué tocar, conviene saber qué servidor tienes en origen y cuál tienes en destino.
Puedes comprobarlo de varias formas:
- Desde el panel del hosting, si muestra la versión de base de datos.
- Desde phpMyAdmin, normalmente en la pantalla principal.
- Desde Plesk o cPanel, si el panel lo indica.
- Desde consola, si tienes acceso SSH.
- Preguntando al proveedor de hosting.
Si tienes acceso a MySQL por consola, puedes consultar la versión con:
SELECT VERSION();Y para ver collations disponibles, puedes usar:
SHOW COLLATION LIKE 'utf8mb4%';Esto ayuda a saber si el servidor destino reconoce la collation que aparece en el archivo SQL.
Cómo solucionar el error utf8mb4_general_ci al importar SQL
La solución más habitual es editar el archivo SQL y sustituir la collation conflictiva por una compatible con el servidor destino.
Pero aquí hay que tener cuidado: no existe una sustitución universal válida para todos los casos. Depende del error, del servidor, de la versión de MySQL o MariaDB y de cómo esté creada la base.
En muchos casos, si el problema es una collation no soportada, puedes hacer una sustitución controlada dentro del archivo SQL.
1. Localiza la collation que da error
El mensaje de error suele mencionar la collation problemática. Puede ser algo como:
Unknown collation: 'utf8mb4_0900_ai_ci'O puede aparecer una referencia a utf8mb4_general_ci, utf8mb4_unicode_ci u otra variante.
2. Abre una copia del archivo SQL
Trabaja siempre sobre una copia. Si algo sale mal, podrás volver al archivo original.
3. Busca la collation en el archivo
Usa la función buscar del editor para localizar la collation. Por ejemplo:
utf8mb4_0900_ai_cio:
utf8mb4_general_ci4. Sustituye por una collation compatible
Una sustitución habitual cuando se importa desde MySQL 8 a un servidor que no soporta utf8mb4_0900_ai_ci puede ser cambiarla por:
utf8mb4_unicode_cio, en algunos casos:
utf8mb4_general_ciPero no conviene hacerlo sin revisar. Si el destino soporta utf8mb4_unicode_ci, suele ser una opción más razonable que forzar cambios sin criterio.
5. Importa de nuevo la base de datos
Una vez guardado el archivo corregido, prueba la importación de nuevo. Si aparece otro error, no sigas haciendo cambios al azar. Lee el mensaje, identifica la nueva collation o instrucción conflictiva y decide el siguiente paso.
No hagas sustituciones masivas a ciegas. Cambiar todas las collations de una base puede resolver una importación, pero también puede generar diferencias en comparaciones, ordenaciones o búsquedas internas.
Qué collation usar: utf8mb4_general_ci o utf8mb4_unicode_ci
Una duda bastante habitual es si conviene usar utf8mb4_general_ci o utf8mb4_unicode_ci.
Para una web WordPress normal, muchas veces el usuario solo quiere que la importación funcione y que la web cargue bien. Pero si estamos afinando, conviene entender la diferencia.
| Collation | Comentario práctico |
|---|---|
| utf8mb4_general_ci | Antigua, rápida y muy usada durante años. Puede ser suficiente en muchas webs, pero no es la opción más precisa para ciertas comparaciones Unicode. |
| utf8mb4_unicode_ci | Más adecuada para reglas Unicode clásicas y habitual como alternativa compatible en muchos servidores. |
| utf8mb4_unicode_520_ci | Versión basada en una especificación Unicode más moderna, pero no siempre disponible en servidores antiguos. |
| utf8mb4_0900_ai_ci | Muy relacionada con MySQL 8. Puede dar errores al importar en servidores que no la soportan. |
| utf8mb4_uca1400_ai_ci | Puede aparecer en entornos MariaDB modernos. No conviene asumir que existe en cualquier servidor. |
Si estás moviendo una web WordPress entre hostings, lo más importante es que el servidor destino soporte la collation elegida y que no se mezclen configuraciones raras dentro de la base.
Error Unknown collation: utf8mb4_0900_ai_ci
Aunque este post nace alrededor de utf8mb4_general_ci, hoy es muy habitual encontrarse con otro error:
Unknown collation: 'utf8mb4_0900_ai_ci'Este problema suele aparecer al exportar una base desde MySQL 8 e intentar importarla en un servidor que no reconoce esa collation, algo frecuente en ciertos entornos con MariaDB o MySQL más antiguo.
Una solución práctica puede ser sustituir en una copia del archivo SQL:
utf8mb4_0900_ai_cipor una collation compatible, como:
utf8mb4_unicode_ciDespués habría que volver a importar y comprobar que la web funciona correctamente.
Consejo técnico: si el error aparece en una migración de WordPress, revisa también que la base de datos destino esté creada con charset utf8mb4. No mezcles latin1, utf8 antiguo y utf8mb4 si no sabes exactamente por qué lo haces.
Error Illegal mix of collations
Otro error relacionado es:
Illegal mix of collationsEste mensaje aparece cuando una operación intenta comparar o combinar textos con collations distintas que no encajan bien entre sí.
Puede pasar en consultas, plugins, búsquedas internas, migraciones incompletas o bases que han ido acumulando cambios durante años.
La solución puede requerir revisar tablas y columnas concretas, no solo reemplazar texto en un archivo SQL.
En algunos casos se puede unificar la collation de tablas o columnas. En otros, hay que revisar qué consulta está fallando, qué plugin la lanza y qué parte de la base tiene una configuración distinta.
Este error no siempre se arregla con buscar y reemplazar. Si aparece en una web en producción, conviene revisar con calma qué tabla, columna o consulta está generando el conflicto.
Qué hacer si el error aparece en una migración de WordPress
En WordPress, los errores de collation suelen aparecer al migrar la web de un hosting a otro, restaurar una copia o importar manualmente la base de datos.
Antes de culpar a WordPress, revisa estos puntos:
- Versión de MySQL o MariaDB en origen.
- Versión de MySQL o MariaDB en destino.
- Collation usada por la base exportada.
- Collations soportadas por el servidor nuevo.
- Codificación del archivo SQL.
- Si la base destino ya existe y tiene otra collation.
- Si estás importando encima de tablas antiguas.
- Si hay plugins que crean tablas propias con collations distintas.
En una migración limpia, lo ideal es crear la base de datos destino correctamente desde el principio, importar el archivo corregido si hace falta y después revisar la web completa.
Cómo editar un archivo SQL sin romperlo
Editar un archivo SQL parece sencillo hasta que el archivo pesa cientos de megas o el editor decide guardarlo con una codificación extraña.
Para hacerlo con más seguridad:
- Trabaja siempre sobre una copia.
- Usa un editor de texto preparado para archivos grandes.
- No uses procesadores tipo Word o Pages.
- Haz sustituciones concretas, no cambios globales sin revisar.
- Guarda el archivo en texto plano.
- Comprueba que no se han añadido caracteres raros al principio del archivo.
Si el archivo es muy grande, puede ser mejor exportar la base de nuevo con opciones compatibles o hacer la corrección desde consola, siempre que sepas lo que estás haciendo.
Solución rápida con buscar y reemplazar
En muchos casos, la solución práctica consiste en buscar una collation no compatible y reemplazarla por otra que sí exista en el servidor destino.
Por ejemplo:
Buscar:
utf8mb4_0900_ai_ci
Reemplazar por:
utf8mb4_unicode_ciO, si el error concreto está relacionado con otra collation, hacer el cambio correspondiente después de comprobar compatibilidad.
También puedes encontrarte líneas como estas dentro del archivo SQL:
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_cio:
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ciLo importante es no cambiar por cambiar. Debes saber qué collation no acepta el destino y cuál sí acepta.
La solución rápida solo es buena si sabes qué estás sustituyendo. Si cambias collations sin entender el error, puedes conseguir que la importación termine, pero dejar una base con problemas difíciles de detectar.
Alternativa: exportar de nuevo la base de datos
A veces no merece la pena pelearse con un archivo SQL exportado de cualquier manera. Si todavía tienes acceso al servidor original, puede ser mejor exportar de nuevo con opciones más compatibles.
Por ejemplo, puedes revisar:
- Opciones de exportación en phpMyAdmin.
- Compatibilidad de exportación si la herramienta lo permite.
- Charset de la conexión.
- Si conviene exportar tablas por separado.
- Si el hosting permite generar una copia desde el panel.
- Si es mejor usar consola para bases grandes.
En bases pequeñas, phpMyAdmin puede ser suficiente. En bases grandes o delicadas, conviene trabajar con herramientas más estables.
Cuándo no deberías tocar la base de datos tú solo
Hay situaciones en las que es mejor parar antes de seguir probando.
Especialmente si:
- La web está en producción.
- No tienes copia completa de archivos y base de datos.
- El archivo SQL pesa mucho y no sabes si se ha exportado bien.
- Hay tienda online con pedidos recientes.
- Hay usuarios, reservas, formularios o datos sensibles.
- El error cambia cada vez que intentas importar.
- No sabes si estás usando MySQL o MariaDB.
- Ya has hecho varios cambios y no recuerdas cuáles.
Aquí nos conviene no jugar a la ruleta. Una base de datos mal importada puede parecer que funciona al principio y dar problemas después.
¿Se te ha atascado una importación de base de datos?
En ideaWeb podemos revisar el error, comprobar el archivo SQL, ver la versión de MySQL o MariaDB y ayudarte a recuperar o mover la web sin ir probando cambios a ciegas.
Ejemplo práctico: migrar WordPress y encontrar un error de collation
Imagina que tienes una web WordPress en un hosting antiguo. Exportas la base de datos desde phpMyAdmin, subes los archivos al nuevo servidor, creas una base vacía e intentas importar el archivo SQL.
La importación empieza bien, pero se detiene con un error de collation. La web todavía no carga porque faltan tablas por importar.
En ese caso, el proceso razonable sería:
- Guardar el archivo SQL original sin tocar.
- Leer el mensaje exacto del error.
- Comprobar qué collation menciona.
- Ver si el servidor destino la soporta.
- Crear una copia del SQL para editar.
- Sustituir la collation conflictiva por una compatible.
- Importar de nuevo en una base limpia.
- Revisar la web, enlaces, caracteres especiales y funcionamiento general.
Si además es una tienda online o una web con datos recientes, habría que tener mucho más cuidado con no pisar pedidos, usuarios o formularios nuevos.
Checklist para solucionar errores utf8mb4 al importar una base de datos
Antes de dar por resuelto el problema, revisa esta lista:
- ¿Tienes copia original del archivo SQL?
- ¿Sabes qué versión de MySQL o MariaDB tiene el servidor origen?
- ¿Sabes qué versión usa el servidor destino?
- ¿El mensaje de error indica una collation concreta?
- ¿Has comprobado si esa collation existe en el servidor destino?
- ¿Has editado una copia, no el archivo original?
- ¿La base destino está limpia antes de importar?
- ¿Has comprobado que los acentos, eñes y caracteres especiales se ven bien?
- ¿La web carga correctamente después de importar?
- ¿Has revisado plugins, formularios, pedidos o datos críticos?
Si no puedes marcar varios puntos de esta checklist, mejor no sigas tocando la base a ciegas. Primero conviene ordenar el diagnóstico.
Qué deberías tener claro antes de cambiar utf8mb4_general_ci
El error utf8mb4_general_ci puede tener solución sencilla, pero no conviene tratar todas las bases de datos igual.
Si estás importando una web WordPress normal, puede bastar con ajustar la collation del archivo SQL para que el servidor destino la acepte. Si estás trabajando con una web grande, una tienda online, una aplicación antigua o una base con tablas de muchos plugins, hay que revisar más.
La idea importante es esta: no estás “arreglando letras raras”. Estás ajustando cómo la base de datos guarda, compara y ordena texto.
Por eso conviene hacer copia, revisar versiones y tocar solo lo necesario.
Preguntas frecuentes sobre utf8mb4_general_ci
¿Qué significa utf8mb4_general_ci?
utf8mb4_general_ci es una collation de MySQL y MariaDB asociada al juego de caracteres utf8mb4. Sirve para definir cómo se comparan y ordenan textos dentro de la base de datos.
¿Por qué falla al importar una base de datos?
Puede fallar porque el servidor destino no soporte la collation usada en el archivo SQL o porque haya diferencias entre la configuración de origen y destino.
¿Es un error de WordPress?
No exactamente. WordPress usa una base de datos, pero el problema suele estar en la compatibilidad entre MySQL, MariaDB, el archivo SQL y el servidor donde se importa.
¿Puedo cambiar utf8mb4_general_ci por utf8mb4_unicode_ci?
En muchos casos puede funcionar, pero conviene comprobar que el servidor destino soporta esa collation y trabajar siempre sobre una copia del archivo SQL.
¿Qué es utf8mb4_0900_ai_ci?
Es una collation usada en MySQL 8. Puede dar problemas al importar la base en servidores que no la reconocen, especialmente si el destino usa versiones antiguas o MariaDB sin esa collation.
¿Qué significa Unknown collation?
Significa que el servidor no reconoce la collation indicada en el archivo SQL. La solución suele ser usar una collation compatible o exportar de nuevo la base con otra configuración.
¿Qué significa Illegal mix of collations?
Significa que una operación intenta combinar textos con collations distintas que no encajan entre sí. Puede requerir revisar tablas, columnas o consultas concretas.
¿Puedo arreglarlo desde phpMyAdmin?
Depende del caso. Puedes importar, exportar o revisar collations desde phpMyAdmin, pero si el archivo SQL tiene una collation no soportada quizá debas corregir el archivo antes de importarlo.
¿Es peligroso editar un archivo SQL?
Puede serlo si no tienes copia o haces cambios masivos sin revisar. Trabaja siempre sobre una copia y comprueba después que la web funciona correctamente.
¿Qué hago si la base de datos es de una tienda online?
En una tienda online hay que tener especial cuidado para no perder pedidos, usuarios o datos recientes. Lo recomendable es hacer copia completa y revisar la migración antes de tocar la base en producción.
