Tenemos un antiguo servidor Mysql 5.1 ejecutándose en el servidor 2003. Recientemente nos mudamos a un entorno más nuevo con Mysql 5.6 y el servidor 2008. Ahora en el nuevo servidor seguimos recibiendo errores al insertar caracteres especiales como 'Ã'.
Ahora he comprobado la codificación de la fuente y es UTF-8. Pero el antiguo servidor Mysql se configuró como latin1 (Servidor/tablas/columnas) con intercalación latin_swedish_ci y no recibimos ningún error en el antiguo entorno.
Ahora he hecho algunas pruebas ya que no estamos en vivo en el nuevo entorno. He intentado configurar todas las tablas en tablas/columnas, así como en latin1. En ambos casos sigo recibiendo estos errores.
Lo que noté es que en el servidor anterior, el conjunto de caracteres predeterminado del servidor es latin1 y en el servidor nuevo es utf-8. ¿Podría ser el problema? Encuentro esto muy extraño porque la fuente es utf-8.
¿Existe tal vez alguna opción para manejar esto que podría activarse en el entorno anterior? No estoy seguro de si algo así existe. Comparé la configuración dentro de la herramienta de administración mysql y, aparte del conjunto de caracteres predeterminado, se ve igual.
EDITAR:
MOSTRAR VARIABLES COMO 'char%';
Servidor antiguo:
+--------------------------+-----------------------------------------------+ | Variable_name | Value | +--------------------------+-----------------------------------------------+ | character_set_client | utf8 | * | character_set_connection | utf8 | * | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | * | character_set_server | latin1 | | character_set_system | utf8 |Nuevo servidor:
+--------------------------+-----------------------------------------------+ | Variable_name | Value | +--------------------------+-----------------------------------------------+ | character_set_client | utf8mb4 | * | character_set_connection | utf8mb4 | * | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | * | character_set_server | utf8 | | character_set_system | utf8 |Por lo que entiendo del artículo en el sitio de MySQL, utf8mb4 es un superconjunto de utf8, esto no debería crear un problema para la codificación, creo, ya que son básicamente idénticos en la codificación, ¿verdad?
El antiguo UTF-8 de MySQL no era el UTF-8 real. Si prueba caracteres "especiales" (japonés o chino), probablemente terminará con cuadrados o signos de interrogación en su antiguo servidor.
Su nuevo servidor ahora realmente usa UTF-8 (mb4 significa multi-bytes 4). El servidor recibe caracteres UTF-8 pero, obviamente, no puede almacenar caracteres UTF-8 porque su tabla no usa UTF-8. Convierta todas las tablas a UTF-8 y la base de datos a UTF-8 y resolverá su problema.
Puedes hacer esto con:
ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_unicode_ci; ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;No olvides hacer una copia de seguridad antes.
SHOW VARIABLES; . 5.0 por defecto a latin1 ; 5.6 por defecto es utf8 . Esto es mayormente visible en
mysql> SHOW VARIABLES LIKE 'char%'; +--------------------------+-----------------------------------------------+ | Variable_name | Value | +--------------------------+-----------------------------------------------+ | character_set_client | utf8 | * | character_set_connection | utf8 | * | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | * | character_set_server | latin1 | | character_set_system | utf8 | SET NAMES utf8; establece las tres líneas marcadas.
à es hexadecimal C3 en latin1 y C383 en utf8. Más codificaciones aquí . Haga esto para ver lo que hay actualmente en una tabla:
SELECT col, HEX(col) FROM table WHERE ... Otra posibilidad es que el "movimiento" destrozó los datos. Si puede hacer el mismo SELECT en ambas máquinas, y si salen de manera diferente, entonces la migración fue mala. Dado que hay muchas formas de mover datos, proporcione los detalles de la migración para que podamos analizar qué podría haber salido mal.
En su título, tiene C29F . Eso es extraño: es un APPLICATION PROGRAM COMMAND de código de control, del que nunca he oído hablar. (Nota: no está relacionado con el à que mencionó más adelante). Proporcione más ejemplos de los problemas; ninguna de esas pistas es útil.
La parte importante de esto es que su antiguo servidor tenía:
| character_set_database | latin1mientras su nuevo servidor tiene
| character_set_database | utf8No importa que la conexión y el cliente usen utf8 si la base de datos usa latin1, las tablas se establecerán de forma predeterminada en latin1 y, por lo tanto, los datos se almacenarán en latin1 y obtendrá su error. Por supuesto, puede establecer explícitamente el conjunto de caracteres y la intercalación de cualquier tabla para que no sea la predeterminada de la base de datos.
Supongo que cuando migró el esquema de la base de datos, no editó la codificación de caracteres para la base de datos o las tablas antes de ejecutar el script de migración.
Ahora puede cambiar la base de datos y cada tabla manualmente, o puede editar el script de migración y volver a ejecutarlo. La mayoría de los volcados de bases de datos y secuencias de comandos de migración incluirán el juego de caracteres específico para cada tabla, así como para la base de datos, incluso cuando sean todos iguales.