Problème d'encodage PHP et mySQL

Version imprimable

27/02/2012, 19h10
ForgetTheNorm

Problème d'encodage PHP et mySQL

Bonjour à tous

Je me mélange les pinceaux dans les différents encodages, avec PHP, mySQL, phpmyadmin... Tout s'était à peu près bien passé jusqu'à ce que j'essaye une requête :

Code:

SELECT ... FROM ... WHERE str LIKE '%tôle%'

Lorsque j'effectue cette requête directement dans phpmyadmin, j'ai bien des résultats. Lorsque j'effectue exactement la même requête via PHP, j'en obtiens 0 (je précise bien que ça ne fonctionne pas que lorsqu'il y a des accents !)

- L'encodage de mes pages est en utf-8 (via le header HTML).
- L'encodage de mon champ 'str' de ma table est en latin1_general_cs (c'est ce qui me semblait correspondre le mieux au Français).

Le "tôle" provient d'une variable écrite par l'utilisateur via un formulaire. J'ai essayé un mb_convert_encoding sans succès, un utf8_decode idem, etc...

Pouvez-vous me décoincer un peu ?

Pierre
27/02/2012, 19h41
RunCodePhp

Salut

Citation:

- L'encodage de mon champ 'str' de ma table est en latin1_general_cs (c'est ce qui me semblait correspondre le mieux au Français).

Et non justement, chaque encodage son propre encodage, même si certains ont des similitudes.

Il faudrait reconvertir les tables/champs en : utf8_general_cs (ou utf8_general_ci).
Mise à par certaine différences d'encodage, l'UTF-8 tend à devenir un nouveau standard du fait qu'il l'intègre bien plus de langue que le LATIN.
(fait des sauvegardes au cas où).

A savoir aussi que :
..._cs veut dire : Case sensitive, donc la casse (majuscule - minuscule) sera tenu compte ("SaLuT" ne sera pas équivalent à "salut" ni même "Salut", etc ...)
..._ci veut dire : Case insensitive, donc peu importe la casse.

Il plus courant à mon sens d'utiliser des CI, insensible à la casse.
Mais c'est à toi de voir. ;)
28/02/2012, 08h35
ForgetTheNorm

Bonjour et merci pour ta réponse. J'ai quelques questions subsidiaires !

Il faut donc que je mette le même encodage partout ?
L'encodage d'une chaîne passée en POST est définie comment ?
Le fait de changer un encodage d'un champ sql modifie-t-il l'encodage des chaines de ce champ ?

Pierre
28/02/2012, 09h18
RunCodePhp

Citation:

Il faut donc que je mette le même encodage partout ?

Oui, c'est cette uniformité qui évite le genre d'erreurs que tu remarques actuellement.
Il y a un tuto qui explique ça : Passez à l'UTF-8 sans manquer une étape

Citation:

L'encodage d'une chaîne passée en POST est définie comment ?

C'est ce code là :

Code:

header('Content-Type: text/html; charset=UTF-8');

Mais il faut quand même indiquer au document HTML que le contenu soit aussi du même charset, la balise <meta> dans le <head>.

Citation:

Le fait de changer un encodage d'un champ sql modifie-t-il l'encodage des chaines de ce champ ?

Alors là, c'est le genre de manip que je fais rarement.
De plus la dernière fois ça date de ... je ne sais plus quand.:aie:

Le plus simple c'est de faire un essai sur une Bdd/table/champ fictive (provisoire), et tu mets du contenu avec des caractères spéciaux en tout genre en LATIN1, puis après tu tentes de convertir l'interclassement en UTF-8 via PhpMyAdmin par exemple.
Et espérer que MySQL convertie bien les données.

Par précaution tu peux aussi créer une page fictive interrogeant cette table/champ (fictive) en tout UTF-8 et voir si cela est concluant.

Essai cela d'abord, à moins qu'un membre garantisse que cela fonctionne.

Si cela ne fonctionne pas, alors il faudra faire quelques manips (export structure/données, modifier les interclassements de ces exports, et ré-import).