web-dev-qa-db-fra.com

Différents caractères, même ASCII code?

J'ai cette requête qui jette deux résultats:

SELECT id FROM table1 WHERE id like 'nm041033%'
  1. nm0410331
  2. nm0410331

Et cette requête légèrement différente qui ne génère qu'un seul résultat:

SELECT id FROM table1 WHERE id='nm0410331'
  1. nm0410331

J'ai essayé de vérifier le ASCII du dernier caractère et j'ai obtenu le même:

SELECT id,ascii(substr(id,9,1)) FROM table1 WHERE id like 'nm041033%'
  1. nm0410331 49
  2. nm0410331 49

Je suppose que c'est un problème d'encodage rare. Comment puis-je le résoudre?

PS: Le champ id est un clé primaire. Le jeu de caractères est latin1_general_ci, Et les valeurs ont été insérées à l'aide de PHP utf8_decode().

PDATE: J'ai changé le jeu de caractères en ascii_general_ci, Et maintenant cette requête ne me donne aucun résultat:

SELECT id FROM table1 WHERE id='nm0410331'

Cependant, ces deux identifiants ne sont pas encore les mêmes. Si j'utilise SELECT DISTINCT Ou GROUP BY J'obtiens deux lignes.

PS: Le dernier caractère n'est pas le nombre que vous pouvez taper avec le clavier.

mysqlvarcharencoding
4
Leopoldo Sanczyk

Grâce à la perspicacité de Akina , qui a suggéré d'utiliser HEX() pour vérifier le champ, j'ai trouvé un octet '0A' supplémentaire à la fin d'une des valeurs.

Après avoir supprimé la contrainte de clé primaire (pour éviter l'ID en double temporaire), j'ai utilisé: UPDATE table1 SET id = TRIM(TRAILING UNHEX('0A') FROM id); Et j'ai pu le résoudre.

PS: Pour les futurs googleurs, utilisez SELECT id FROM table1 WHERE id like 'nm0410331%' pourrait aussi me faire remarquer mon problème idiot ...

4
Leopoldo Sanczyk

Idéalement, vous ne devriez pas avoir à "nettoyer" les données - vous devez les remplir en utilisant TRIM - et en utilisant une fonction d'échappement appropriée ... si un saut de ligne peut se faufiler là-dedans - très probablement une seule citation aussi .. et bonjour , bienvenue dans SQL-injection ....

2
eagle275