Discussion :

[tavarlindar]

Bonjour,

Après des heures et des heures de recherches, je capitule et décide d’appeler à l’aide.

Voilà :
J’ai un module php/mysql full UTF8 : j’entends par là :
fichier encodé en utf-8,
un header('Content-Type: text/html; charset=utf-8'); au début de chaque page,
etc, etc.
Bref, tout se passe bien. Je stocke dans la base ce que j’ai à l’écran. Les caractères chinois sont stockés en chinois, le russe en russe, etc.
Maintenant, j’ai un formulaire que je dois non seulement enregistrer dans ma base mais aussi dans une base mysql tiers. Et là, je sèche. Je rencontre un problème de conversion. Je n’arrive pas à enregistrer dans une base non utf8 des datas qui le sont.

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
// Code de mise à jour
mysql_query("SET NAMES 'utf8'",$connexion);
if (isset($_POST['nom']))  {$nom = trim(ucwords(strtolower(mysql_real_escape_string($_POST['ag_nom'])))); 
$nom_base2= utf8_decode(trim(ucwords(strtolower(mysql_real_escape_string($_POST['ag_nom'])))));}
 
Code de mise à jour de la base 1 (rien à signaler – tout fonctionne parfaitement)
 
// mise à jour de la base 2 : base tiers
$host2="X.Y.T.U; //nom du serveur
$user2="XXX"; //nom utilisateur
$pass2="ZZZ"; //mot de passe
$base2="QQQ"; //nom de la base de données
 
// connexion à MySQL
mysql_connect ($host2,$user2,$pass2) or die ('ERREUR '.mysql_error());
// sélection de la base de données
mysql_select_db ($base2) or die ('ERREUR '.mysql_error()); 
 
 
//mysql_query("SET NAMES 'iso-8859-1");
$req2 = "UPDATE tabe_a_modifier SET nom='".$nom_base2."' WHERE ID='".$_POST['id']."'";
mysql_query($req2);	
mysql_close();

Si je tape dans le formulaire dans le champ nom :
Paris é 巴黎
La base2 stocke Paris é ??
Le résultat devrait être :

Code :

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

Paris  é  巴黎

J'ai testé plusieurs traitements avec sans utf8_decode(), etc. rien n'y fait.

Si on regarde le code du formulaire initial rattachée à la base 2, on constate les points suivants :
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
Et pour le reste, rien de spécial :
<input type="text" name="name" value="<? print($nom); ?>" size="50" maxlength="100">
Le code de mise à jour dans la base2 est classique, pas de traitement particulier des $_POST.
La table qui reçoit les data utilise un Interclassement latin1_swedish_ci

En vous remerciant par avance,

Tavar

[julp]

- ucwords, strtolower* sont incompatibles avec de l'UTF-8
- iso-8859-1 n'existe pas comme nom de jeu pour MySQL, c'est latin1
- le jeu à indiquer au niveau de MySQL c'est celui de vos données/requêtes pas des colonnes puisque MySQL les connait et se charge des conversions si nécessaire (du moins, je ne considère ici que la partie qui nous intéresse, character_set_client)
- convertir de l'UTF-8 dans un jeu beaucoup plus limité comme l'est l'ISO-8859-1, n'a aucun sens. D'ailleurs utf8_decode ne fonctionnera pas : les caractères chinois devraient être substitués par des points d'interrogation (puisque non retranscriptibles/inexistants en ISO-8859-1).

Par contre, le remplacement de tels caractères en entités XML/HTML (leur point de code) est une mauvaise idée (meilleur moyen d'avoir des recherches incohérentes et interopérabilité nulle, entre autres). Si malgré tout vous n'avez la possibilité d'insister pour une migration en UTF-8, il y a $out = mb_convert_encoding($in, 'HTML-ENTITIES', 'UTF-8') qui convertit également les caractères latin1 (sinon, a priori, l'écrire soi-même ou le plus proche est de passer par PHP 5.4/Transliterator - $out = transliterator_create('[^\x00-\x7F\xC0-\xFF]-Hex/XML10')->transliterate($in)).

* du moins sans mbstring.func_overload & 2 et mbstring.internal_encoding = UTF-8

PS : les balises code/codeinline du code PHP ont reconvertis les caractères en entités

[tavarlindar]

Bonsoir julp,
Merci pour vos éléments de réponse.

Maintenant plusieurs remarques.

* ucwords, strtolower sont incompatibles avec de l'UTF-8

Il me semblait l'avoir déjà lu , cela dit cela ne pose pas de problème chez moi (enfin je ne l'ai pas encore constaté). Je vais néanmoins approfondir le sujet.

convertir de l'UTF-8 dans un jeu beaucoup plus limité comme l'est l'ISO-8859-1, n'a aucun sens en soi

Je suis d'accord. Cela dit, j'unifie 2 applications. La personne en charge de la seconde application ne souhaitant pas modifier tout son code, je suis contraint de stocker les infos dans sa base sans tout perturber.

Si vous aviez une idée de code, je suis preneur !

[tavarlindar]

Bonsoir,

Merci , ou plutôt, un Grand merci à vous julp.

Finalement, je vais utilisé

Code :

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

1
2
 
$out = mb_convert_encoding($in, 'HTML-ENTITIES', 'UTF-8')

Après m'être rendu compte que je ne mettais pas à jour le bon fichier (cela n'aide pas à comprendre pourquoi les choses ne fonctionnent pas ), j'ai refait plusieurs tests. Le fait de convertir en HTML-ENTITIES n'a pas d'incidence sur l'application tiers. L'affichage web est correcte et c'est le principal.

Chose curieuse et que je n'arrive pas à m'expliquer : si je saisi dans le module de mise à jour de l'application (que je ne gère pas) : Paris é 巴黎 à €
on stocke dans la base :

Code :

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

Paris é 巴黎 à €

avec mb_convert_encoding($in, 'HTML-ENTITIES', 'UTF-8') on obtient (logiquement ):

Code :

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

Paris é 巴黎 à €

in fin, cela ne change pas l'affichage, mais bon, j'aurais aimé reproduire le même résultat. Si au passage vous avez l'explication, je suis preneur.

Je n'ai pas réussi à tester

Code :

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

$out = transliterator_create('[^\x00-\x7F\xC0-\xFF]-Hex/XML10')->transliterate($in)

Encore merci et encore merci. Je faisais fausse route.

Bien à vous

tavar

[stealth35]

si dans ton formulaire tu mets : Paris é 巴黎 à €
dans ta base tu dois avoir : Paris é 巴黎 à €
dans ton HTML : Paris &eacute; 巴黎 &agrave; &euro;
niveau visuel : Paris é 巴黎 à €


mysql_real_escape_string pour la base
htmlspecialschars pour l'affichage

et c'est tout, y'a rien a encoder, convertir, translitérer ...

[julp]

J'ai compris que :

• des données en UTF-8
• une table (enfin les colonnes) en latin1 avec incapacité d'intervenir dessus

Par conséquent, c'est impossible sans "htmlentitiesation" (avec ce que ça implique et tout) :

• avec character_set_client = character_set_connection = utf8 : MySQL plante parce qu'il ne peut pas faire la conversion vers latin1 (ce que j'ai déjà dit même si cela concernait PHP plus tôt)
• avec character_set_client = character_set_connection = latin1, pas de conversion (= pris tel quel), le seul moyen que ça rentre : mais c'est totalement aberrent puisque ça oblige à avoir character_set_results = latin1 alors que tu récupères de l'UTF-8. Ne parlons même pas des recherches, des reconversions par MySQL (client avec un character_set_results différent ou à la volée - CONVERT) qui donneraient n'importe quoi ni du fait que, de ce que j'ai compris, elles sont également destinées à être intégrées à une page en ISO-8859-1

Les rédacteurs de dvp sont dans une situation similaire d'ailleurs ...

[tavarlindar]

Bonjour,

Concernant les remarques de stealth35:

Je rappelle que je dois enregistrer la même données dans 2 bases de données paramétrées différemment.
Dans ma base je suis full UTF-8, donc RAS. C'est par rapport à l'autre base que je n'arrive pas à enregistrer exactement comme le module de mise à jour rattaché à l'autre base le fait.

Si je tape Paris 巴黎 , j'enregistre, on obtient sur les pages web qui s’appuient sur l'autre base de données: Paris 巴黎.

La solution proposée par julp répond au besoin. Certes, en "htmlentitiesant", cela n'aide pas pour les recherches, mais l'autre application n'en a pas besoin vraiment. L'autre base de données sert finalement que pour afficher des noms sur des pages web. En revanche mon application couvre plusieurs domaines et là RAS nous sommes en utf-8.

Donc je vais clôturer ce post en vous remerciant encore une fois et plus particulièrement julp pour la qualité des ses remarques.

Bien à vous

Tavar