Soffri di "doppia codifica".
Ecco cosa è successo.
- Il client aveva caratteri codificati come utf8; e
SET NAMES latin1
ha 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 latin1
lo vedevo come 2 caratteri con codifica latin1Ã
e©
(esadecimale:C3
eA9
)- 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 BY
potrebbe 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