Discussion :

[karamaster]

Bonjour,
J'ai un problème l'encodage de mon site en WebDev.
Ma base de données est en utf8mb4_general-ci, lors des enregistrement tous les mots sont tronqué à partir du caractère accentué (par exemple : Validée => Valid) aussi la page la page les caractères accentués ne s'affiche pas.
J'ai fais quelques recherche dans le forum mais je ne trouve pas la solution.

[frenchsting]

Bonjour,

Je n'y connais pas grand chose en webdev, mais je pense que tu as effectivement un problème d'encodage. Est-ce que tu as regardé le charset de la page concernée ?

[CosmoKnacki]

Je ne connais pas WinDev, mais tu peux t'intéresser au code produit par celui-ci.

utf8mb4_general_ci n'est pas un encodage mais une collation (ou interclassement), c'est l'ensemble des règles qui font qu'un mot est devant, derrière ou au même niveau qu'un autre lors d'une comparaison et donc d'un tri (dans une requête comprenant une clause ORDER BY par exemple).

À noter que la collation utf8mb4_general_ci est archaïque et ne respecte pas les règles de l'Unicode, conduisant à des classements parfois étranges. Suivant ce qui est disponible avec ta version de MySQL/MariaDB, utf8mb4_0900_ai_ci, utf8mb4_unicode_520_ci ou utf8mb4_unicode_ci, dans cette ordre, sont de bien meilleurs choix. Pour voir les collations utf8mb4_* respectant l'Unicode:

Code SQL :

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

1
2
3
4
5
6
7
SELECT collation_name AS `collation`,
       character_set_name AS character_set,
       is_default AS `default`,
       pad_attribute AS pad
FROM information_schema.`collations`
WHERE collation_name RLIKE '^utf8mb4_(unicode|0900_a)'
ORDER BY collation_name;

Le soucis avec les problèmes d'encodages, c'est qu'ils peuvent se trouver à plusieurs niveaux:

niveau base de données:

Si ta base de données utilise la collation utf8mb4_general_ci cela signifie que l'encodage par défaut de celle-ci est utf8mb4, ce qui est une bonne chose. Ceci dit, rien n'empêche les tables de ta base de données d'utiliser un autre encodage (elles héritent de celui de la base de données qui est leur encodage par défaut mais peuvent choisir un encodage qui leur est propre), et il en va de même pour les colonnes par rapport aux tables. Donc tu peux déjà vérifier que les tables et les colonnes incriminées n'ont pas leur propre encodage et prennent bien celui par défaut de la base de données.

Pour vérifier que toutes les colonnes (type CHAR, VARCHAR, TEXT ...) d'une table sont bien encodées en utf8mb4, tu peux utiliser la requête:

Code SQL :

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

1
2
3
4
SELECT column_name, character_set_name
FROM information_schema.`columns` 
WHERE table_name = 'ma_table'
  AND character_set_name IS NOT NULL; -- filtre les colonnes non concernées par l'encodage (BIT, INT, DATE, BLOB...)

Éventuellement précédé de USE nom_de_la_bdd; pour préciser de quelle base de données on parle.

Si pour chaque colonne tu obtiens utf8mb4, alors c'est ok, sinon tu dois changer l'encodage soit au niveau de la colonne, soit au niveau de la table (si aucune des colonnes n'a le bon encodage).

niveau PHP:

C'est à ce niveau que s'établit la connexion pour ouvrir une session avec le serveur MySQL. Il faut ici aussi définir un encodage que va utiliser le serveur MySQL pour communiquer avec PHP. Donc suivant le module utilisé par PHP (PDO ou MySQLi), on a:

• PDO:

  Code php :

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

  $conn = new PDO("mysql:host=$hostname;dbname=$database;charset=utf8mb4", $username, $password);

• MySQLi:

  Code php :

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

  1
  2
  $conn = new mysqli($hostname, $username, $password, $database);
  $conn->set_charset("utf8mb4");

Pour le reste du code PHP, il faut partir à la chasse aux fonctions iconv et mb_convert_encoding et méthodes UConverter::convert voire Transliterator::transliterate pour chercher si des conversions malheureuses n'ont pas eu lieu.

niveau HTML:
S'assurer de la présence de <meta charset="utf-8"/> entre les balises <head>...</head> de la page.
On peut aussi éventuellement vérifier l'attribut accept-charset des balises <form>, si présent (dans le cas contraire, c'est l'encodage définit dans <meta charset...> qui est utilisé).

niveau sources externes:
Si des fichiers comme par exemple un CSV viennent hydrater la base de données, bien vérifier l'encodage et convertir au besoin.

niveau outils:
Vérifier les préférences d'encodage des éditeurs et autres applications, ainsi que l'encodage lors de l'enregistrement des fichiers code.

[karamaster]

Merci de votre aide.