Soffri di "doppia codifica".
Ecco cosa è successo.
- Il client aveva caratteri codificati come utf8; e
SET NAMES latin1ha mentito affermando che il client aveva la codifica latin1; e- La colonna nella tabella dichiarava
CHARACTER SET utf8.
Vediamo cosa succede a e-acute:é .
- L'esadecimale per quello, in utf8 è 2 byte:
C3A9. SET NAMES latin1lo vedevo come 2 caratteri con codifica latin1Ãe©(esadecimale:C3eA9)- Dato che l'obiettivo era
CHARACTER SET utf8, quei 2 caratteri dovevano essere convertiti.Ãè stato convertito in utf8 (hexC383) e©(hexC2A9) - Quindi, sono stati memorizzati 4 byte (hex
C383C2A9)
Durante la rilettura, sono stati eseguiti i passaggi inversi e l'utente finale probabilmente non ha notato nulla di sbagliato. Cosa c'è che non va:
- I dati archiviati sono 2 volte più grandi di quanto dovrebbero essere (3x per le lingue asiatiche).
- I confronti per uguale, maggiore di, ecc. potrebbero non funzionare come previsto.
ORDER BYpotrebbe non funzionare come previsto.
Qualcosa del genere riparerà i tuoi dati:
UPDATE ... SET col = CONVERT(BINARY(CONVERT(
CONVERT(UNHEX(col) USING utf8)
USING latin1)) USING utf8);
Altre discussioni eAltri esempi di correzione