Discussion :

[mm_71]

Bonjour,

Le problème d'affichage est classique, au lieu de lire:

"3 planches dépliantes hors texte."
Dans le navigateur on lit:
"3 planches d�pliantes hors texte."

Je dois passer le navigateur en mode 'occidental' pour qu'il s'affiche correctement ( la partie html n'utilise que des é et consorts donc ça marche aussi ).

Le site est 100% en utf-8, le navigateur le détecte bien comme tel ( affichage par défaut unicode ) le problème vient de la base de données ( Pour apache et php.ini j'ai tout épluché et c'est bien en UTF8 et c'est seulement ce qui est chargé depuis la bdd qui dérappe, de plus les symptômes sont les mêmes sur la version en ligne chez mon hébergeur ) et la suite devient beaucoup moins banale !

J'ai rajouté

Code :

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

1
2
3
[mysql]
default-character-set = utf8
default-collation = utf8_general_ci

Dans my.cnf, à l'ouverture de la table j'ai rajouté:

Code :

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

1
2
mysqli_set_charset( $conn , UTF8 );   
mysqli_query("SET character_set_results = 'utf8', character_set_client = 'utf8', character_set_connection = 'utf8', character_set_database = 'utf8', character_set_server = 'utf8'");

Et la structure de la table ( Qui s'affiche bien en unicode dans phpmyadmin ) semble correcte:

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE `0b_cat_full` (
  `CODE` varchar(12) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `CODACHAT` varchar(12) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `TITRE` varchar(100) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `AUTEUR` varchar(70) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `EDITEUR` varchar(70) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `ILLUSTR` varchar(70) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `TYPILL` varchar(4) CHARACTER SET utf8 NOT NULL DEFAULT '.',
  `TYPE` varchar(3) CHARACTER SET utf8 NOT NULLTYPE` varchar(3) CHARACTER SET utf8 NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Mes requêtes n'ont rien de spécial et ressemblent toutes à ça:

Code :

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

1
2
3
4
$Liste=$db->query("$SeekInstru LIMIT $From, $NbLines" );
While ( $Fiche= $Liste->fetch_array())
$Titre=$Fiche['TITRE'];
Etc...

J'ai aussi:

Code :

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

<meta charset="utf-8">

Dans le header du site.

Rien n'y fait, si je veux que l'affichage par défaut soit correct je n'ai que deux options:

1: A l'importation des données dans la table via phpmyadmin je choisis l'option d'encodage ISO-8859-15 et tout est correct ( Les fichiers .sql sont bien en UTF8).
2: Au début du site je rajoute:

Code :

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

header('Content-Type: text/html;charset=ISO-8859-15');

Ça marche aussi mais le gag c'est que le navigateur passe en détection automatique Japonais. Avec ISO-8859-1 il reste en occidental.

Ce truc me fait tourner en bourrique depuis hier, est-ce que quelqu'un à une idée de pourquoi un BDD UTF8 veut impérativement s'afficher en ISO ?

[Celira]

Si je comprends bien, tu alimentes ta base avec des fichiers SQL. La base et les fichiers étant encodés en UTF-8, les données sont correctes dans le fichier, tu exécutes ton fichier et pouf ! dans la base elles retrouvent en ISO ?

[mm_71]

Si je comprends bien, tu alimentes ta base avec des fichiers SQL.

Oui.

La base et les fichiers étant encodés en UTF-8, les données sont correctes dans le fichier

,
Oui.

tu exécutes ton fichier et pouf ! dans la base elles retrouvent en ISO ?

Non, si je la liste avec phpmyadmin l'affichage par défaut avec un navigateur est bien en unicode,

Serveur : Localhost via UNIX socket
Type de serveur : MySQL
Version du serveur : 5.7.20-0ubuntu0.16.04.1 - (Ubuntu)
Version du protocole : 10
Utilisateur : root@localhost
Jeu de caractères du serveur : UTF-8 Unicode (utf8)

Apache/2.4.18 (Ubuntu)
Version du client de base de données : libmysql - mysqlnd 5.0.12-dev - 20150407 - $Id: b5c5906d452ec590732a93b051f3827e02749b83 $
Extension PHP : mysqliDocumentation mbstringDocumentation
Version de PHP : 7.0.22-0ubuntu0.16.04.1

Dans mysql workbench l'affichage est tout aussi correct.
C'est seulement quand je la charge sur mon site local ou distant que tout part en vrille ( Quelque soit le navigateur ).

[mm_71]

Je sens que je vais craquer, j'ai fait le test le plus minimaliste qui soit et c'est la même chose, donc ça ne vient pas de la programmation de mon site.

Résultat du test:

Pour tester les acccents.
Test accents �����

Terminé

Avez vous cette même horreur sur cette url: EDIT: N'est plus nécessaire.

Le code:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title></title>
    </head>
    <body>
        <?php
            $host="";          
            $Base="";
            $user="";
            $pass=""  ;
 
            $db = mysqli_connect($host,$user,$pass, $Base);
             if (mysqli_connect_errno()) {
                printf("Échec de la connexion : %s\n", mysqli_connect_error());
                exit();        
            }
            echo "Résultat du test:<br><br>";
            $Req=$db->query("SELECT * FROM test_utf8");
 
            while ($Fiche=$Req->fetch_array()) {
                echo $Fiche[CHAMP]."<br>";    
            }
            echo "<br>Terminé";  
         ?>
    </body>
</html>

La requête SQL crée et exportée directement de phpmyadmin, donc ma méthode d('import et mes .sql n'est pas en cause.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
-- phpMyAdmin SQL Dump
-- version 4.6.6
-- https://www.phpmyadmin.net/
--
-- Client :  localhost
-- Généré le :  Mar 05 Décembre 2017 à 15:57
-- Version du serveur :  5.7.20-0ubuntu0.16.04.1
-- Version de PHP :  7.0.22-0ubuntu0.16.04.1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Base de données :  `mabdd`
--
-- --------------------------------------------------------
--
-- Structure de la table `test_utf8`
--
CREATE TABLE `test_utf8` (
  `CHAMP` varchar(25) CHARACTER SET utf8 NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
--
-- Contenu de la table `test_utf8`
--
INSERT INTO `test_utf8` (`CHAMP`) VALUES
('Pour tester les acccents.'),
('Test accents éàèêû');
 
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

[mm_71]

Bon... Il n'y a pas que ma BDD qui foire, j'ai reçu un mail m'informant que CinePhil venait de répondre et je ne vois pas sa réponse sur le forum.

***************
Ben en même temps, si j'affiche le code HTML de la page, je lis ça :
Test accents �����
Faites-nous un test avec les é et compagnie pour voir...
***************

Voilà le résultat ( logique et attendu ) du test:

Pour tester les acccents.
Test accents �����
é à

Code :

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

Test accents �����

Utiliser un truc du genre str_replace au chargement des données serait en effet une solution radicale mais fort peu propre,

EDIT: Si j'en crois ce que je vois en faisant un C/C avec les balises CODE au lieu de QUOTE ça ne fonctionnerais sans doute pas.

et surtout j'aimerai comprendre une bonne fois pour toutes ce qui ne tourne pas rond !
Manifestement il y-a quelque chose qui ne va pas dans la BDD ( Le serveur distant n'a pas la même version de php ni de mysql mais fait la même chose ). J'en déduis que quelque chose convertit automatiquement les caractères en ISO au moment ou php accède aux données mais quoi ?

[Celira]

Ah oui quand même, là tu as vraiment un problème. Le même code ultra-minimal avec mysqli_set_charset($db, "utf8") donne le même résultat ?

Bon... Il n'y a pas que ma BDD qui foire, j'ai reçu un mail m'informant que CinePhil venait de répondre et je ne vois pas sa réponse sur le forum.

C'est normal, il l'a supprimée On ne pense pas toujours aux mails informatifs dans ce genre de situation

[mm_71]

Ah oui quand même, là tu as vraiment un problème. Le même code ultra-minimal avec mysqli_set_charset($db, "utf8") donne le même résultat ?

Message salvateur ! Ça marche sur le test, et ça m'a permis de remarquer que si ça ne marchait pas sur le site principal c'est parce-que j'avais placé la ligne au mauvais endroit.
Pour l'essentiel c'est résolu mais j'aurai quand même aimé comprendre la raison de ce bin's. Si c'est un bug de php ou de mysql ça doit faire des années qu'il traîne, le serveur distant est toujours sur mysql: 5.5.37-0ubuntu0.12.04.1-log.

Je viens de regarder ça: https://secure.php.net/manual/fr/mbs...figuration.php et cette extension qui s'est installée par défaut me semble fort suspecte ?

C'est normal, il l'a supprimée On ne pense pas toujours aux mails informatifs dans ce genre de situation

Je n'avais pas vu qu'on pouvait supprimer un message.

[Celira]

Pour information, il y a une fonction pour connaître l'encodage utilisé par la connexion : mysqli_character_set_name(), ça peut servir

Je n'avais pas vu qu'on pouvait supprimer un message.

En tant qu'utilisateur du forum, tu peux éditer un message dans les 3 jours après l'avoir posté en cliquant sur le bouton "modifier le message" en bas à gauche, ce qui inclut une suppression pure et simple.

[CinePhil]

Et comme je suis modérateur sur ce forum, j'ai le privilège de pouvoir le faire même sur de vieux messages.
En l'occurrence, comme je l'ai indiqué en motif de suppression, mais peut-être cela n'est-il pas accessible au "simple" utilisateur, mon message n'était en fait pas pertinent, après lecture complète du premier message.
Fin de l'histoire.

[Celira]

comme je l'ai indiqué en motif de suppression, mais peut-être cela n'est-il pas accessible au "simple" utilisateur,

Il faut effectivement être modo pour voir les messages supprimés, et donc les motifs de suppression

[mm_71]

Pour information, il y a une fonction pour connaître l'encodage utilisé par la connexion : mysqli_character_set_name(), ça peut servir

En effet ! ( Il y-a qq. années que je n'ai plus remis le nez dans php et autres, même si le site est fonctionnel il sert surtout à me maintenir les neurones en bon état ).

Donc:

Code :

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

1
2
  mysqli_set_charset( $db , UTF8 );           
$Charset= mysqli_character_set_name($db);

Renvoie utf8

Code :

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

1
2
  //mysqli_set_charset( $db , UTF8 );           
$Charset= mysqli_character_set_name($db);

Renvoie latin1
Tout étant configuré et créé en utf-8 c'est déjà très anormal, mais je viens de trouver pire: En faisant des séries de "reload" des pages un coup j'ai latin1 un autre utf8 !!???!.
Mon test minimaliste faisant la même chose ça ne vient pas du site en lui même, ça se produit sur des hôtes différents avec des versions de php et mysql différentes. ça ne peut donc venir que de ma BDD en elle même mais que peut-elle bien avoir qui ne tourne pas rond ?

[mm_71]

Ok. J'ai piqué ma crise et détruit la BDD pour la refaire en entier et le souci a disparu à condition que j'importe depuis un script perso ( Lazarus FPC ).
Avec phpmyadmin ( Pourtant lui aussi bien configuré en utf8 ) rien ne va plus.
Si j'ai le malheur d'éditer ou d'ajouter un champ avec des caractères accentués depuis son interface le champ concerné est interprété en latin1 quoique je fasse. Ça pourrait expliquer ce truc bizarre:

En faisant des séries de En faisant des séries de "reload" des pages un coup j'ai latin1 un autre utf8 !!???!

La page concernée fait un affichage aléatoire de 6 fiches. Si aucune n'a subi phpmyadmin c'est OK sinon c'est raté.

Ça devient trop compliqué pour moi, j'arrête ici.