Base de données UTF8, tables et champs Latin1 (site sous Spip)

Bonjour

Je développe un site sous Spip (avec pas mal de plugins) :
- En UTF8 : la base (jeu de caractères + interclassement), en-têtes HTTP, déclaration dans les pages
- En Latin1_swedish_ci : les tables et les champs (interclassement)

Le site s'affiche correctement sauf que j'ai des erreurs avec certaines class (récupération du titre avec une fonction : function no_accent($chaine))

<div class="bloclibre Zoom&quot;Droitdesmn&#65533;dias&quot; bloc1 bloc_global">

Edit : mon "é" est transformé... c'est un point d'interrogation (caractère invalide)

Après recherches et lectures des différents posts dont celui-ci lien, j'ai pris un peu peur à la lecture "Les données retournées sont corrompues"

Comme le site est pour l'instant en développement (mais avec quand même déjà pas mal de données), j'aimerai avoir des conseils :
- laisser tel quel puisque l'affichage est correct (sauf les class)
- mettre tout en UTF8 (là, j'aurai besoin de connaitre la procédure car je n'ai pas de grandes compétences )

Si ce cocktail de déclarations risque d'être une bombe à retardement, je pense qu'il est mieux de réparer maintenant que dans 1 an ou deux, mais là, je n'ai pas assez de recul pour savoir quoi faire, c'est mon premier site en Spip...

Merci
Cécile
Modifié par cilou (09 May 2009 - 15:20)

Salut,

l'interclassement ne concerne que les tris et les recherches dans la base : donc aucune raison que les données soient corrompues. Je pencherais plutôt pour ta fonction no_accent qui ne semble pas supprimer les quotes mais les remplacer par une entité html et qui ne tient peut-être pas compte de l'utf-8 (multi-octets).

Heyoan a écrit :
l'interclassement ne concerne que les tris et les recherches dans la base

Sauf que si tu as un interclassement de type latin1, cela signifie que les données sont marquées dans MySQL comme étant encodées en latin1, ce qui peut signifier:

- avec une connexion en UTF-8, MySQL va s'amuser à convertir les données;
- avec une connexion en ISO-8859-1 (latin1), à priori non (si toutes les données sont marquées comme étant en latin1).

Reste à savoir si ces champs marqués comme étant en latin1 contiennent de l'ISO-8859-1 ou de l'UTF-8. Et ça, ça se détermine... en écrivant un script pour récupérer les données, et en faisant varier le paramètre de la connexion (SET NAMES), pour voir ce qu'on récupère réellement.

Heyoan a écrit :
donc aucune raison que les données soient corrompues

Si les données sont en UTF-8, dans des tables marquées comme étant en latin1 ( ), et avec une connexion par défaut en latin1, alors effectivement on récupèrera les contenus UTF-8 tels quels.

Heyoan a écrit :
Je pencherais plutôt pour ta fonction no_accent qui (...) ne tient peut-être pas compte de l'utf-8 (multi-octets).

Yep.

Florent V. a écrit :
Sauf que si tu as un interclassement de type latin1, cela signifie que les données sont marquées dans MySQL comme étant encodées en latin1

Ah ben merci : je n'avais jamais tilté qu'en changeant l'interclassement d'une colonne l'encodage était lui aussi modifié (je pensais qu'il n'y avait conversion à la volée que dans le cas d'une requête).

Déjà, merci pour les réponses, sauf que... j'ai pas vraiment compris grand chose

a écrit :
Reste à savoir si ces champs marqués comme étant en latin1 contiennent de l'ISO-8859-1 ou de l'UTF-8. Et ça, ça se détermine... en écrivant un script pour récupérer les données, et en faisant varier le paramètre de la connexion (SET NAMES), pour voir ce qu'on récupère réellement.

... écrire un script... heu

Pour l'instant j'en suis là de mes réflexions :
J'écris dans Spip
- Titre : Zoom "Droit des médias" (c'est là ou il a la class avec un point d'interrogation dans un losange à la place du é)
- Texte : Droit des médias. Pavé pour annoncer l’info

Les champs de la base de données
- Titre : Zoom "Droit des médias"
- Texte : Droit des médias. Pavé pour annoncer l'info.

L'affichage de la page : normal

Le code source de la page :
- Titre : <div class="bloclibre Zoom"Droitdesm?dias" bloc1 bloc_global">
<h2>Zoom "Droit des médias"</h2>
- Texte : Droit des médias. Pavé pour annoncer l’info.

Si j'ai bien compris ce que j'ai lu sur internet et au vu du e accent aigu et de l'apostrophe du l : j'envoie en UTF8 dans la base de données, celle ci "mouline" et stocke ces données en ANSII (Latin1) et quand la page est appelée par le navigateur, ça "re-dé-mouline" pour les afficher en UTF8...

a écrit :
Je pencherais plutôt pour ta fonction no_accent qui ne semble pas supprimer les quotes mais les remplacer par une entité html et qui ne tient peut-être pas compte de l'utf-8 (multi-octets).

... je mets la fonction au cas ou

function no_accent($chaine){ 
   $chaine = strtr
// La ligne suivante entre parenthèse doit être sur une seule ligne, sinon erreur php
($chaine,  "ÀÁÂÃÄÅàáâãäåÒÓÔÕÖØòóôõöøÈÉÊËèéêëÇçÌÍÎÏìíîïÙÚÛÜùúûüÿÑñ", "aaaaaaaaaaaaooooooooooooeeeeeeeecciiiiiiiiuuuuuuuuynn");
 $chaine = str_replace("\"", """, $chaine);
 return $chaine;
  }

Heyoan a écrit :
Ah ben merci : je n'avais jamais tilté qu'en changeant l'interclassement d'une colonne l'encodage était lui aussi modifié (je pensais qu'il n'y avait conversion à la volée que dans le cas d'une requête).

Il n'y a pas de modification des données si tu change l'interclassement, à ma connaissance. Mais la présence d'un interclassement rattaché à un encodage donné signifie que MySQL considère que les données sont dans l'encodage en question (que ça soit vrai ou pas).

Lorsque j'ai parlé de conversion par MySQL, je parlais bien sûr d'une conversion lors d'une requête. On peut éviter une telle conversion (potentiellement lourde en ressources...) en s'assurant que la connexion utilise le même encodage que celui marqué pour les données (qu'il corresponde aux données ou non!), ou en configurant MySQL pour ne pas effectuer de conversion.
Modifié par Florent V. (09 May 2009 - 16:23)

A propos des modifications des données, j'ai essayé de mettre table et champs en UTF8 mais médias est resté médias.

Sinon, je trouve que les pages sont lentes à s'afficher, est ce que ça peux venir de la conversion ?

cilou a écrit :
... écrire un script... heu

Va peut-être falloir trouver un développeur...

cilou a écrit :
Les champs de la base de données
- Titre : Zoom "Droit des médias"
- Texte : Droit des médias. Pavé pour annoncer l'info.

L'affichage dans un phpMyAdmin ou équivalent n'est pas fiable. Notamment sur phpMyAdmin déclares les pages qu'il affiche en ISO-8859-1 (ça se configure, il me semble). Mais même en configurant l'encodage déclaré, il me semble qu'on n'a pas un contrôle suffisant sur les paramètres de la connexion avec le serveur MySQL, donc ce n'est jamais réellement fiable. D'où la nécessité d'écrire un script de test quand on n'est pas sûr de ce qui est enregistré en base.

cilou a écrit :
L'affichage de la page : normal

Il n'y a à priori aucun problème particulier avec MySQL. Il faut se concentrer sur la fonction PHP utilisée.

cilou a écrit :
j'envoie en UTF8 dans la base de données, celle ci "mouline" et stocke ces données en ANSII (Latin1) et quand la page est appelée par le navigateur, ça "re-dé-mouline" pour les afficher en UTF8...

Je ne crois pas. Je dirais: tu envois de l'UTF-8 dans la base de données, dans des champs marqués en latin1, avec une connexion en latin1. Pour MySQL, tu envoies du latin1 (même si ce n'est pas le cas), et donc il écrit les données telles quelles sans les modifier. Pour les requêtes, ça marche pareil. Donc pas de moulinage en amont ou en aval.

Merci Florent

a écrit :
Va peut-être falloir trouver un développeur...

... Si j'ai choisi Spip, c'est parce que je ne suis pas capable de développer un site en PHP, mais cela ne m'empêche pas d'essayer de comprendre et de réparer quand Tidy me signale une erreur.

Bonjour

Qui cherche, trouve
Résultats du "script" :

- Latin 1
Texte : Zoom "Droit des médias"
Contenu : Droit des médias. Pavé pour annoncer l'info.

- UTF8
Texte : Zoom "Droit des médias"
Contenu : Droit des médias. Pavé pour annoncer l'info.

Bonsoir

Désolée d'insister... mais si quelqu'un pouvait me conseiller à partir du résultat du script de test sur ma question initiale :
- laisser la base de données telle quelle puisque l'affichage est correct (sauf les class)
- tout mettre en UTF8 puisque SPIP semble configuré pour cela

Merci d'avance