Représentation UTF-8/ISO dans la base

Général
1

Bonjour
Je travaille à l'intégration dans SPIP 1.9.1 (sous forme d'un plugin) de modules développés pour une autre appli.

J'ai créé et renseigné dans la base Spip les nouvelles tables nécessaires au plugin (via export des tables de l'appli, puis import dans la base spip avec phpMyAdmin).

J'ai des caractères accentués dans le code html qui s'affichent correctement et j'ai des caractères accentués dans les champs texte des tables qui s'affichent '?'...

Les tables sont au format "myISAM".
J'ai l'instruction
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> dans le bloc "head" mais la supprimer ne change rien...
Si je la change pour <...charset=utf-8...>, tous les caractères accentués, y compris ceux dans le code html, s'affichent '?'.

Dans les tables de l'appli, les caractères accentués sont lisibles, alors que dans les tables spip, les caractères accentués sont remplacés par des insultes (on voit bien que c'est de l'utf-8!).
J'en conclus que mon importation est incorrecte car elle devrait trancoder les caractères en utf-8... mais je ne sais pas comment faire ça sous phpMyAdmin.

Merci pour toute aide
A+
    François

2

On Sat, 2007-06-02 at 19:50 +0200, FGH wrote:

Dans les tables de l'appli, les caractères accentués sont lisibles,
alors que dans les tables spip, les caractères accentués sont
remplacés
par des insultes (on voit bien que c'est de l'utf-8!).

  Quel est le charset des tables de l'appli existante ? (phpMyAdmin
l'affiche quand on demande la structure de la table).
  Le problème de phpMyAdmin, c'est que parfois, il s'emmelle les
pinceaux à l'affichage avec les charsets. S'il y a de utf dans une table
iso, il arrive parfois qu'il l'affiche correctement ou inversement.
  Il faut donc commencer par être sur de ce qu'il y a en table.

  Pour ça, le plus simple est de repérer une colonne dans laquelle
il y a un texte court avec des accents et de demander dessus :
select char_length(toto), length(toto)
si la colonne toto contient le mot "repérer", la réponse est :
- 7, 7 si la table est iso et contient du iso
- 7, 8 si la table est utf et contient du utf
- 8, 8 si la table est iso (ou binaire) et contient du utf
  (c'est le cas des tables de spip carles text sont en binaire)
- 8, 9 si la table est utf et contient de l'utf reconverti en utf

  Une fois que tu es sur de ce que tu as sous la main, on peut agir :wink:
  Il faudra soit convertir les tables spip soit celles de l'appli pour
quelles causes de la même manière. Ou il suffira d'expliquer à spip ce
qu'il a en base

  À suivre ...

--
À+, Pif.

3

Merci Pif pour ces infos. Tu sembles avoir déjà été confronté au pb!!!

Comme conseillé, j'ai passé la requête
"select char_length(toto), length(toto)"
sur une de mes nouvelles tables introduites dans la base "spip", et j'obtiens la réponse "12,12" pour un champ de 12 car. dont 1 est accentué.

D'après les infos données dans ton mail, cette table "appli" est donc ISO et contient de l'ISO.

Le même texte renseigné via l'espace privé dans l'un des champs d'un article Spip me donne la réponse "13,13" confirmant que les tables "spip" sont ISO et contiennent de l'UTF-8.

Si ma table "appli" est ISO et contient de l'ISO, et que mon code html contient "<meta... CHARSET=ISO...>", pourquoi les caractères accentués ne sont-ils pas bien reproduits lorsqu'ils sont lus via "spip_query" ?
NB: Dans mon appli originelle, ils étaient lus via "mysql_query".

Merci de nous faire profiter de ton savoir...
Cordialement
    François

christian lefebvre a écrit :

On Sat, 2007-06-02 at 19:50 +0200, FGH wrote:

Dans les tables de l'appli, les caractères accentués sont lisibles, alors que dans les tables spip, les caractères accentués sont
remplacés par des insultes (on voit bien que c'est de l'utf-8!).

  Quel est le charset des tables de l'appli existante ? (phpMyAdmin
l'affiche quand on demande la structure de la table).
  Le problème de phpMyAdmin, c'est que parfois, il s'emmelle les
pinceaux à l'affichage avec les charsets. S'il y a de utf dans une table
iso, il arrive parfois qu'il l'affiche correctement ou inversement.
  Il faut donc commencer par être sur de ce qu'il y a en table.

  Pour ça, le plus simple est de repérer une colonne dans laquelle
il y a un texte court avec des accents et de demander dessus :
select char_length(toto), length(toto)
si la colonne toto contient le mot "repérer", la réponse est :
- 7, 7 si la table est iso et contient du iso
- 7, 8 si la table est utf et contient du utf
- 8, 8 si la table est iso (ou binaire) et contient du utf
  (c'est le cas des tables de spip carles text sont en binaire)
- 8, 9 si la table est utf et contient de l'utf reconverti en utf

  Une fois que tu es sur de ce que tu as sous la main, on peut agir :wink:
  Il faudra soit convertir les tables spip soit celles de l'appli pour
quelles causes de la même manière. Ou il suffira d'expliquer à spip ce
qu'il a en base

  À suivre ...

4

On Mon, 2007-06-04 at 11:12 +0200, FGH wrote:

Si ma table "appli" est ISO et contient de l'ISO, et que mon code html
contient "<meta... CHARSET=ISO...>", pourquoi les caractères accentués
ne sont-ils pas bien reproduits lorsqu'ils sont lus via "spip_query" ?
NB: Dans mon appli originelle, ils étaient lus via "mysql_query".

je pense que spip_query récupère les bonnes valeurs, mais comme le code
autour s'attend à recevoir de l'utf "brut", il passe un coup de
conversion dessus.

le code html qui contient un "meta iso", c'est un squelette spip et le
méta vient d'une balise #CHARSET ou c'est manuel ?
dans le premier cas, il suffit peut être de mettre le site spip en utf,
via la page d'admin "configuration les langues" ?
sinon, que se passe t'il avec une page spip "d'origine" ? elle est en
utf ou en iso ?

--
À+, Pif.