Discussion :

[waxman]

Bonjour,

J'ai une colonne
libelle varchar(200) utf8_general_ci

Je souhaite obtenir toutes les lignes donc la colonne libelle commence par la lettre 'a' (par exemple). Mais je me retrouve avec celles commençant par un é majuscule.

J'ai donc fait ce test:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT distinct left(libelle,1), ascii(left(libelle,1)) FROM matable  WHERE left(libelle,1)='a'

Voici le résultat de l'exécution:
left(libelle,1) ascii(left(libelle,1))
A 65
à 195

Le é majuscule, au lieu d'être associé au e, est associé au a

Avez vous une idée pour m'en sortir ??

Merci d'avance

[Fred_34]

Si tu fais ceci tu as 1 ? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT LEFT('Étendu', 1)='a';

[waxman]

Alors voici deux tests:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT LEFT(  'Étendu', 1 ) =  'a'

==> 0
Je m'y attendais puisque le É est saisi dans l'interface et n'est donc pas en utf8.



Par contre, j'ai repéré un enregistrement commençant par É et j'ai fait ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT LEFT( libelle, 1 ) =  'a' FROM matable WHERE id =486

==> 1

Ça confirme ce que j'observais hier soir

Merci

[waxman]

Pour info, voici le champ libelle de l'enregistrement 486 vu par l'interface:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Élodie

[CinePhil]

Voici le résultat de l'exécution:
left(libelle,1) ascii(left(libelle,1))
A 65
à 195

Le é majuscule, au lieu d'être associé au e, est associé au a

Dans ce que tu nous présentes, il s'agit d'un angström majuscule, c'est à dire un genre de A, pas de E. Il est donc normal que la requête retourne ce 'a'.

Ceci dit, comme pour pas mal de choses, MySQL n'est pas bon avec les collations.

[waxman]

Ce que je présente n'est pas un angström majuscule mais un é majuscule, stocké en utf8.
Il est vu comme un angström majuscule suivi d'un second caractère par phpmyadmin car il ne tient pas compte du charset

Cependant, dans l'application qui gère correctement l'utf8, il s'agit bien d'un é majuscule.

mysql est il mauvais à ce point lorsqu'on travaille en utf8 ?

[CinePhil]

Pour info, voici le champ libelle de l'enregistrement 486 vu par l'interface:

Je dirais plutôt alors que ce sont les données qui ont mal été enregistrées en BDD ou que tu as un problème de retranscription de ce qui est enregistré en BDD dans ton interface utilisateur.

Avant les requêtes que tu envoies au serveur, envoie celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET NAMES = utf-8

[waxman]

PEtite précision: Lorsque je parle de l'interface, c'est phpmyadmin qui m'affiche incorrectement la valeur.

Comme je disais, dans mon application, ça s'affiche correctement.
Du point de vue applicatif, je n'ai donc aucun souci pour stocker et retrouver les données

Question surement idiote: Comment, à partir de l'appli php ou phpmyadmin, exécuter la commande que tu me conseilles ?

Merci

[CinePhil]

C'est une requête comme une autre.

[waxman]

C'est ce que j'avais supposé mais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET NAMES=utf-8;

debug : #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1{"success":false,"error":"
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1<\/div>"}

Un bug dans phpmyadmin ?

Je vais tenter dans mon appli php...

Merci

[Fred_34]

A priori, ce serait plutôt ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET NAMES  'utf8'

[ericd69]

salut,

petite question: pourquoi utiliser left qui est une fonction plutôt que like 'a%' qui est une opérateur et permet l'utilisation des index?

comme te dit cinephil, c'est pas parce qu'une table est en utf-8 que tu enregistres en utf-8 dedans...

si tu as un double caractère à la place du "é" c'est que tu as mis du iso dans de l'utf-8... il faut que tu ais tous les niveaux de ton application qui aient les mêmes réglages et comme à cause de l'histoire on a du iso par défaut...

si tu as un mauvais encodage à certain endroit mais celui donné au navigateur qui est finalement en adéquation tu peux avoir le genre de comportement que tu vois...

tout dois être forcé à utf-8 quand c'est possible

• apache
• les headers générés par php pour tout ce qui est texte s'ils sont utilisés
• les déclarations dans les documents textes
• l'encodage des fichiers php niveau éditeur (sauf utilisation de fonctions multibytes pour la conversion)
• les échanges php-ajax
• les échanges php-mysql
• mysql
• la bd
• la table

les limitations de l'utf-8 sont surtout dues au fait que les idiots qui ont implémenté mysql ont choisi de limiter à 3 octets le stockage au lieu des 6 de la norme ce qui engendre l'impossibilité d'utiliser tout un tas de plans et la restitution incohérente des caractères qui en font partie

si tu es en utf-8 le seul gros problème de collation c'est pour savoir si tu veux gérer les recherche en majuscule/minuscule différemment à divers moment éventuellement

[waxman]

Salut,

petite question: pourquoi utiliser left qui est une fonction plutôt que like 'a%' qui est une opérateur et permet l'utilisation des index?

Très bonne question et je vais envisager l'appli sous cet angle de vue...

comme te dit cinephil, c'est pas parce qu'une table est en utf-8 que tu enregistres en utf-8 dedans...

J'en ai conscience. Mes données sont en uft8, l'appli est en ut8. Et lorsque je récupère les données, elles sont toujours en utf8.
Je n'ai aucun souci avec ça. Les pages web sont déclarées utf8 également auprès du navigateur et tout fonctionne parfaitement.
Encore une fois, je n'ai aucun problème dans l'appli, ni au niveau de l'affichage, ni au niveau de l'enregistrement des données. Seuls les traitements internes à mysql me posent problème...

si tu as un double caractère à la place du "é" c'est que tu as mis du iso dans de l'utf-8...

Je dirais l'inverse
Je stocke bien de l'utf8 (soit un caractère sur 2octets) et à la fois phpmyadmin et certains traitement internes de la base le considèrent en iso et ne tiennent donc compte que du premier octet

si tu es en utf-8 le seul gros problème de collation c'est pour savoir si tu veux gérer les recherche en majuscule/minuscule différemment à divers moment éventuellement

Oui, j'ai noté l'absence de CS en utf8

Encore merci pour vos conseils, je vais regarder ça de plus pres...

[ericd69]

l'utf8 c'est 1 à 3 octets (pour mysql, au lieu des 1 à 6 de la norme)
l'iso c'est 1 à 2, c'est pour ça qu'anciennement on l'utilisait plus volontiers

oui ou l'utf8 en iso en effet... dans un sens ou l'autre... enfin ça donne à pensé qu'il y a eu une quiproquo à l'engistrement à un moment

après il suffit que tu ais des fonction mb_ qui convertisse dans ton application pour que ça donne ça...

un truc tu as vérifié que phpmyadmin est bien en utf lui aussi? car ça expliquerait simplement l'erreur d'exécution et d'affichage dans php myadmin...

il y a plein de limitations et de risques (si tu n'as pas accès à sa configuration) à tester des requêtes avec lui... il est pensé sur pour l'administration, la mise en place, si tu peux utilises d'autres outils, surtout si tu testes sur windows...

@fred_34

A priori, ce serait plutôt ça :
Code :
Sélectionner tout - Visualiser dans une fenêtre à part

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

SET NAMES  'utf8'

tu y étais presque:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

SET NAMES='utf8'

[waxman]

phpmyadmin n'est pas en utf8, ça je le sais depuis le début et je m'en accommode.
Les données sont enregistrées et affichées par l'application qui est en utf8, alors ça ne me pose aucun problème et je suis en utf8 de bout en bout
Je n'utilise phpmyadmin que pour des besoins d'administration, de définitions de tables par ex et j'ai appris à ne pas faire attention aux erreurs d'affichage...

Je résume mon probleme qui n'est pas lié à phpmyadmin:

->J'ai une table contenant une colonne "libelle"
->Les données sont en utf8
->Je cherche à faire un index (au sens table des matières, non pas au sens bdd) des libellés
->Du coup, pour afficher la page des A (par exemple), je fais un select where left(libelle,1)='a'
-> problème, mysql (rien à voir avec mon appli ni même phpmyadmin, c'est interne à mysql) me ressort aussi les é majuscules lors de la requête précédente....

PS: SET NAMES='utf8' n'est pas accepté, seul SET NAMES 'utf8' me donne une exécution réussie

Merci

[waxman]

J'ai testé

petite question: pourquoi utiliser left qui est une fonction plutôt que like 'a%' qui est une opérateur et permet l'utilisation des index?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM matable WHERE libelle LIKE  'a%' ORDER BY libelle

ça me retourne tous ceux qui commencent par a et par un é majuscule....

[ericd69]

autan pour moi pour le set names
fred_34

question tu mets bien

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
set names 'utf8';
SELECT * FROM matable WHERE libelle LIKE  'a%' ORDER BY libelle;

car je crois que pma crée une connexion indépendante pour chaque séquence de requêtes..

[waxman]

Alors, dans pma, en lançant les deux requêtes en une fois, ça ne change rien. Je vais tester dans l'application (à laquelle je n'ai pas accès immédiatement) et je vous dirai...

Merci encore

[ericd69]

oui essaye de faire cette requête via un petit fichier test en php

attention tu ne pourras pas avoir 2 commandes en même temps sur ton applicatifs avec un seul appel php sauf à configurer pour que ça passe

mais tu n'auras pas besoin de faire ce set names supplémentaire vu que ton code dans l'appli le fait déjà...

je pense juste que les autres lignes correspondent à des a accentés en début de libellé...

sinon fait ça pour vérifié dans pma:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT left(libelle,1),libelle FROM matable WHERE libelle LIKE  'a%' ORDER BY libelle;

plus compact pour bien voir...
chaque caractère accentué mal encodé apparaitra sur 2 caractères, les normaux sur 1 seul

[waxman]

Voici le résultat de ta requete dans pma:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
...
A	Auban
...
Ã	Évelyne

Les libellés sont des prénoms.
indépendamment des pb d'affichage de pma (dont on se fout ici, l'important n'est pas si c'est bien ou mal affiché mais quelles sont les lignes renvoyées par la requête), le moteur mysql me renvoie des prénoms qui commencent par un é majuscule....