Problème d'encodage PHP et mySQL

**ForgetTheNorm** · 27/02/2012, 19h10

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 :

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

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

**RunCodePhp** · 27/02/2012, 19h41

Salut

- 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.

**ForgetTheNorm** · 28/02/2012, 08h35

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

**RunCodePhp** · 28/02/2012, 09h18

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

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

C'est ce code là :

Code :

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

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>.

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.

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).

Problème d'encodage PHP et mySQL

PHP & Base de données

Discussions similaires

Partager

Partager