UTF-8 et PHP 5 ?

Quelqu’un a-t-il une idée de la façon dont on peut traiter des chaînes de caractères codées en UTF-8 avec du PHP 5 sans se retrouver avec des caractères erronés ?

On sait que PHP 6 est censé être enfin pleinement compatible avec l’encodage UTF-8, mais il doit être déjà possible de s’en sortir puisque phpMyAdmin est écrit en PHP et permet d’afficher correctement les chaînes de caractères UTF-8 extraites d’une base de données.

J’ai essayé de trouver ça dans le code de phpMyAdmin, mais c’est inextricable…

Pourtant le fait que phpMyAdmin y parvienne prouve que c’est possible !

Hello,

Attention à ne pas confondre : PHP peut depuis pas mal de temps déjà "sortir" du code en UTF-8, tu peux enregistrer tes scripts en UTF-8 et y mettre des chaînes de caractères en UTF-8 sans problème. Ce que PHP ne peut pas faire par contre c'est avoir des variables qui portent des NOMS encodé en UTF-8. Par exemple : $ma_variable_à_part. Je suis pas sur que ce soit très utile mais de ce que j'ai compris c'est là où PHP6 amènera une évolution.

edit: J'ai cherché rapidement pour voir si je racontais pas de conneries, de fait je dois en dire une car à ce que je viens de comprendre PHP travaille en ISO même si il est encodé en UTF-8, le soucis c'est qu'il va stocker des caractères UTF-8 sur deux octets au lieu d'un, ce qui peut poser des soucis dans certains cas comme celui-ci :

Code:

<?php

// Déclarations (ce fichier PHP est édité en utf-8)
$names = array();
$names[] = 'le bien être';
$names[] = 'le bien etre';

$str = "Texte : %s (%d caractères)";
// PHP5 : Décalage du au ê
// PHP6 : Gère l'utf8

foreach ($names as $name) {
    printf($str, $name, strlen($name));
}

/*
PHP 5 :
Texte : le bien être (13 caractères)
Texte : le bien etre (12 caractères)

PHP 6 :
Texte : le bien être (12 caractères)
Texte : le bien etre (12 caractères)
*/

Personnellement je n'ai jamais eu de soucis à ce niveau-là bien que travaillant sur des scripts encodés en UTF-8. Le seul point où il faut faire attention c'est à l'entrée et à la sortie, le charset de la page doit être le même. C'est tout.

Quand tu parles de "traiter" des chaînes de caractères codées en UTF-8, pourrais-tu donner un peu plus de détail?
Quand tu as un formulaire HTML avec un charset UTF-8 le navigateur va envoyer les données en UTF-8 et PHP pourra les utiliser sans soucis, il pourra même les enregistrer dans une base MySQL (qu'elle soit UTF-8 ou non ! ). Ce qu'il faut surtout c'est qu'à la restitution de ces données, le charset de la page soit toujours UTF-8.

Sinon tu as toujours la solution de utf8_encode() et utf8_decode() qui te permet de passer de l'ISO-8859-1 à l'UTF-8 et inversement.

Si en parlant de "traiter" tu parles de faire des opérations dessus comme des str_replace() et autres, là il faut faire attention à encoder également ton script en UTF-8. Par exemple je reçois une variable POST en UTF-8 et je veux lui enlever les accents, il faudra bien faire attention à ce que le script PHP qui répertorie ces accents soit en UTF-8 ou qu'il utilise utf8_encode() sur les accents.

PS : Elle est où la rubrique développement?

neiluj a écrit:

Attention […] sur les accents.

Ouaiiiiiis ! une réponse sur ce sujet pourtant peu propice à remuer les foules ! Merci Juju !

Effectivement, j’ai été un peu court dans mes explications.
Bon, alors les scripts sont en UTF-8, les chaînes faisant partie du script sont affichées correctement, en fait les noms de variables peuvent être en UTF-8 si on veut (j’ai pris l’habitude de les écrire en bon français avec des accents et tout), elles sont utilisées, reconnues et tout, sans problème, c’est parfait.

Mais quand j’extrais une malheureuse petite chaîne en UTF-8 d’une base de données en UTF-8 avec un script en UTF-8, dès que je fais le moindre traitement dessus, tel que le placer dans un tableau, envoyer une requête ou je ne sais quoi de ce genre, l’encodage devient faux. À l’affichage j’ai des @Ÿ et autres joyeusetés à la place des caractères non ascii purs. En fait, dès que je l’extrais c’est mauvais, c’est plutôt ça qu’il faut dire.

Or si je passe tout en ISO, scripts, données, chaînes fixes, aucun problème, tout est bon d’un bout à l’autre.

Je suis sûr d’avoir essayé encode/decode, j’ai essayé tellement de choses, mais comme dès qu’elle est extraite, la donnée est mal encodée, ça ne me sert à rien, il est toujours trop tard ! Je me suis cassé le nez pendant des jours entiers sans trouver de solution. J’ai cherché il y a quelques temps sur des tas de forums et j’ai vu que je n’étais vraiment pas le seul a avoir ce problème et aucune réponse ne résolvait quoi que ce soit, tous les fils de discussion finissaient en quenouille. Une page, je ne sais plus où disait que PHP5 ne sait pas traiter correctement l’UTF-8, mais je ne sais pas si c’est vrai.

Voilà donc mon problème formulé autrement.

Comme tu as l’air de dire que ça devrait marcher, je suis plein d’espoir, mais…
En théorie ça doit marcher effectivement, mais as-tu essayé toi-même ? C’est surtout ça que j’aimerais savoir, si ça peut fonctionner effectivement dans la réalité, auquel cas, en partant d’un exemple qui marche je pourrai toujours retracer où ça coince dans mes scripts, mais mon code le plus basique coince tout de suite là-dessus, scrogneugneu !

neiluj a écrit:

PS : Elle est où la rubrique développement?

Ben, je crois que nous y sommes… c’est juste le libellé qui a changé, TG a ajouté quatre mots : « développer vos propres trucs » et hop, labo c’est aussi pour le développement.

Attends, je viens de relire.


Quand tu dis :

/*
PHP 5 :
Texte : le bien être (13 caractères)
Texte : le bien etre (12 caractères)

PHP 6 :
Texte : le bien être (12 caractères)
Texte : le bien etre (12 caractères)
*/

ça montre bien qu’il y a un vrai problème dans php5, puisque les caractères utf-8 en plus d’un octet sont considérés comme 2 ou plusieurs caractères, exactement comme dans mysql avant la 5, je crois bien. Depuis mysql 5, un caractère de plusieurs octets = un caractère, point final, heureusement. Comme je manipule les données dans des tableaux, ça doit foirer quelque part par là, php confondant les octets et les caractères. Merdum !


------------------------
ah, je comprends tout, tu as édité pendant que je répondais sur une première version de ton message…
On arrive bien à l’idée que php5 pense en iso ! L’andouille ! Et php6, c’est pour quand ? Ben je suis pas sorti de l’auberge !
------------------------

hr a écrit:

neiluj a écrit:

Attention […] sur les accents.

Ouaiiiiiis ! une réponse sur ce sujet pourtant peu propice à remuer les foules ! Merci Juju !

Effectivement, j’ai été un peu court dans mes explications.
Bon, alors les scripts sont en UTF-8, les chaînes faisant partie du script sont affichées correctement, en fait les noms de variables peuvent être en UTF-8 si on veut (j’ai pris l’habitude de les écrire en bon français avec des accents et tout), elles sont utilisées, reconnues et tout, sans problème, c’est parfait.

Pas très recommandé les accents pour les variables :/ Moi je préfère utiliser l'anglais, enfin surtout pour les fonctions/méthodes, mais j'évite toujours les accents.

hr a écrit:

Mais quand j’extrais une malheureuse petite chaîne en UTF-8 d’une base de données en UTF-8 avec un script en UTF-8, dès que je fais le moindre traitement dessus, tel que le placer dans un tableau, envoyer une requête ou je ne sais quoi de ce genre, l’encodage devient faux. À l’affichage j’ai des @Ÿ et autres joyeusetés à la place des caractères non ascii purs. En fait, dès que je l’extrais c’est mauvais, c’est plutôt ça qu’il faut dire.

Tu es certain de bien spécifier le charset de ton HTML d'affichage?
Et si tu modifies l'encodage via le menu "Présentation" de Safari, quel charset te donne un affichage correct?
Comment tes données ont-elles été injectées dans la base?
Si tu les visualises avec PhpMyAdmin est-ce que tes champs affichent de bons accents?
Si tu utilises utf8_encode() ou utf8_decode() tu n'as aucun changement? ou plutôt aucun changement positif?

hr a écrit:

Comme tu as l’air de dire que ça devrait marcher, je suis plein d’espoir, mais…
En théorie ça doit marcher effectivement, mais as-tu essayé toi-même ? C’est surtout ça que j’aimerais savoir, si ça peut fonctionner effectivement dans la réalité, auquel cas, en partant d’un exemple qui marche je pourrai toujours retracer où ça coince dans mes scripts, mais mon code le plus basique coince tout de suite là-dessus, scrogneugneu !

Ca marche en théorie et en pratique également, j'ai déjà été confronté à un problème et comme je le disais tout réside dans le charset d 'entrée et de sortie. Il me faudrait un exemple de ton code pour y voir un peu plus clair, mais sache en tout cas que je connais bien le sujet ;-)

hr a écrit:

neiluj a écrit:

PS : Elle est où la rubrique développement?

Ben, je crois que nous y sommes… c’est juste le libellé qui a changé, TG a ajouté quatre mots : « développer vos propres trucs » et hop, labo c’est aussi pour le développement.

Ok c'est bien ce qu'il me semblait

edit :

hr a écrit:

Comme je manipule les données dans des tableaux, ça doit foirer quelque part par là, php confondant les octets et les caractères. Merdum !

Non ce n'est pas sensé jouer dans ton problème, tout dépend de ton script, si tu cherches à manipuler les octets. Mais moi je n'ai jamais eu ce soucis donc...

hr a écrit:

------------------------
ah, je comprends tout, tu as édité pendant que je répondais sur une première version de ton message…
On arrive bien à l’idée que php5 pense en iso ! L’andouille ! Et php6, c’est pour quand ? Ben je suis pas sorti de l’auberge !
------------------------

Je suis certain que tu n'as pas besoin de PHP6, justement parce que comme tu le disais au tout début, PMA y arrive bien ! Et moi également, je manipule des chaînes et des sites entiers en UTF-8, ça ne m'a jamais posé de problème à partir du moment où j'ai bien compris qu'il fallait bien spécifier le charset des pages HTML d'entrée (formulaires) et de sortie (affichage final).

neiluj a écrit:

Pas très recommandé les accents pour les variables :/ Moi je préfère utiliser l'anglais, enfin surtout pour les fonctions/méthodes, mais j'évite toujours les accents.

Ça semble ne pas poser de problème, mais j’ai essayé de les supprimer, ça n’a rien changé.

neiluj a écrit:

Tu es certain de bien spécifier le charset de ton HTML d'affichage?

Absolument, dans l’entête du fichier html généré, dans les entêtes http reçues par le navigateur, dans l’encodage de BBEdit (utf-8 no bom).

neiluj a écrit:

Et si tu modifies l'encodage via le menu "Présentation" de Safari, quel charset te donne un affichage correct?

Aucun : par exemple le mot L’arbre avec une vraie apostrophe est affichée Larbre si je force UTF-8 avec l’apostrophe qui est un caractère invisible, sans doute parce que son code n’est pas bon. Si je force en ISO, je vois LÂ’arbre.
De même le caratère … est mal affiché.

Incroyable, je viens de voir que dans un de mes derniers scripts, les accents sont correctement affichés ! êÊàÀæŒçÇ sera correct. Pourtant je suis sûr que les accents n’allaient pas du tout il y a un certain temps

Par contre, rien de changé pour les caractères comme ’…•— par exemple qui ne sont pas affichés correctement lorsque je les extrais de la bdd, mais sont bons s’il s’agit de chaînes en dur dans les scripts. Ça exclut les problèmes de polices incomplètes ou je ne sais quoi de ce genre.

neiluj a écrit:

Comment tes données ont-elles été injectées dans la base?

Je crois que j’ai tout essayé. Par script, par cocoamysql, par phpmyadmin et que sais-je encore. L’encodage semble bon, rien à faire.

neiluj a écrit:

Si tu les visualises avec PhpMyAdmin est-ce que tes champs affichent de bons accents?

Oui, les caractères de type ’…•— sont affichés parfaitement, mais pma affiche en passant par une usine à gaz complètement folle et je ne sais pas si c’est très significatif.

neiluj a écrit:

Si tu utilises utf8_encode() ou utf8_decode() tu n'as aucun changement? ou plutôt aucun changement positif?

Il y a peut-être un bout de réponse au mystère des accents qui marchent… Je viens de voir que j’ai fourré des utf8_encode() partout dans le script qui les affiche correctement. Peut-être cette fonction est-elle incomplète ? Ils ont peut-être paré au plus pressé et les caractères accentués latins sont correctement traités mais pas les autres ?

Oui ! je viens de vérifier, ma théorie fumeuse est juste :

Code:

echo
    (
    "<p class=\"petittitre\">chez d'autres éditeurs</p>
    <p class=\"note\">" . utf8_encode($bibliographie[$i]) . "</p>"
    );

donne un affichage correct pour les accents alors qu’afficher $bibliographie[$i] sans utf8_encode() donne des affichages faux pour les accents. Par contre utf8_encode() ne code pas correctement les caractères UTF-8 autres que les caractères accentués. ’…•— est toujours aussi faux ! Bon, on progresse !

neiluj a écrit:

Ca marche en théorie et en pratique également, j'ai déjà été confronté à un problème et comme je le disais tout réside dans le charset d 'entrée et de sortie.

En l’occurrence ce n’est pas ça.
Bon, si ça a marché pour toi, c’est peut-être que ça marche aussi pour moi mais je ne m’en rends pas compte, ou inversement… Ce que je veux dire est que les chaînes de texte sont correctement traitées pour le texte pur et peut-être n’as-tu jamais eu à afficher des caractères autres que latins. Es-tu sûr que des choses du genre ’…•— sont correctement extraites chez toi aussi ?

À l’inverse, je peux toujours, en attendant mieux, transformer par le script du formulaire avant d’écrire dans la BDD les caractères qui passent mal en leurs codage en entités : ’…•— serait remplacé par &rsquo;&hellip;&bull;&mdash; ce qui prend de la place mais au moins ne pose plus de problème d’affichage !

neiluj a écrit:

mais sache en tout cas que je connais bien le sujet

Ça, ça me rassure en tout cas !

neiluj a écrit:

Et moi également, je manipule des chaînes et des sites entiers en UTF-8, ça ne m'a jamais posé de problème à partir du moment où j'ai bien compris qu'il fallait bien spécifier le charset des pages HTML d'entrée (formulaires) et de sortie (affichage final).

Bon, mais sachant que mes déclarations de charset sont correctes, je repose ma question : à part ce qui se trouve en dur dans les scripts et qui passe pour tout le jeu utf-8, es-tu vraiment sûr d’avoir mis des apostrophes (des vraies) ou des points de suspension etc. dans la base et de les avoir ressortis sans problème ?


------------------------
ça va tg, on anime assez la rubrique ?
bon, hein, j’rigauuule ! et toute cette sorte de choses !

hr a écrit:

neiluj a écrit:

Pas très recommandé les accents pour les variables :/ Moi je préfère utiliser l'anglais, enfin surtout pour les fonctions/méthodes, mais j'évite toujours les accents.

Ça semble ne pas poser de problème, mais j’ai essayé de les supprimer, ça n’a rien changé.

Non, je ne disais pas que ça pouvait avoir un rapport avec ton problème mais je n'aime pas les caractères accentués dans le "code", le vrai.

hr a écrit:

Par contre, rien de changé pour les caractères comme ’…•— par exemple qui ne sont pas affichés correctement lorsque je les extrais de la bdd, mais sont bons s’il s’agit de chaînes en dur dans les scripts. Ça exclut les problèmes de polices incomplètes ou je ne sais quoi de ce genre.

Ok, je n'avais jamais essayé ces caractères je crois...


Bon après avoir fait quelques tests... il s'avère qu'à l'injection dans PMA on a pas un retour comme on l'attendrait. Enfin, j'ai fait le test de mon côté et bizarrement c'est en forçant Safari en ISO (latin1) que les caractères se sont affichés correctement.

Je t'invite à faire ce petit test de ton côté :

Bon tout d'abord créer une petite table "test" dans une base "test"...

Code:

CREATE TABLE `test` (
  `id` int(11) NOT NULL auto_increment,
  `test` varchar(250) NOT NULL,
  PRIMARY KEY  (`id`)
)

Ensuite tu recopies ce code et changes les identifiants de ta base pour que ça colle...

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
   <title>TEST</test>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<form method="post" name="form" action="">
<input type="text" name="test"/>
<input type="submit" name="ok" value="ok"/>
</form>
<br/><br/>
<?php
// Selon ta config
define('DB_HOST','localhost:8889');
define('DB_USER','root');
define('DB_PASS','root');
define('DB_NAME','test');

mysql_connect(DB_HOST,DB_USER,DB_PASS);
mysql_select_db(DB_NAME);

if(isset($_POST['test']))
{
   $sql = "INSERT INTO test (id,test) VALUES ('','".addslashes($_POST['test'])."');";
   $res = mysql_query($sql);
}


$sql = 'SELECT id,test FROM test ORDER BY id ASC;';
$res = mysql_query($sql);
if($res && mysql_num_rows($res) != 0)
{
   $return = '<table border="1" cellpadding="4">';
   while($row = mysql_fetch_assoc($res))
   {
      $return .= '<tr><td>'.$row['id'].'</td><td>'.stripslashes($row['test']).'</td></tr>';
   }
   $return .= '</table>';
}
else
{
   $return = 'Erreur SQL ou table vide';
}
echo $return;
?>
</body>
</html>

Si tu mets "’…•— é à è ê ç ù" dans le champ texte, il sera injecté dans la table et afficher immédiatement. Tu pourras constater qu'aucun caractère ne passe à la trappe, et nul besoin d'utiliser utf8_encode() ou utf8_decode() .

PS : TG je suis super déçu, c'est quoi ce charset windows-1252 sur le forum???!!!!

hr a écrit:

ça va tg, on anime assez la rubrique ?

Tain, j'tais sur'l'cul d'taleur : tous forums en vert (sauf la branche Windows, rien d'inquiétant). Du jamais vu depuis l'ouverture.

TG a écrit:

tous forums en vert (sauf la branche Windows, rien d'inquiétant).

Ah ben si j’aurions su, j’aurions fait un entre-filet sur linux…

Bon, effectivement, j’ai essayé ton code et ça marche au poil. Ça c’est drôlement bien. En fait, ça doit marcher dans ton code parce qu’il est minimaliste et donc que les données passent juste par des appels de fonctions basique sans aucun traitement. Il va donc falloir scruter à chaque chose que j’ajouterai autour de ça.

Ben va falloir que je trouve ce qui provoque le problème dans mes fonctions. Plus vite dit que fait… et puis j’ai pas trop le temps pour ça en ce moment, sauf à très petite dose, mais on en reparlera en temps utile.

Merci beaucoup pour ton aide en tout cas !

hr a écrit:

Bon, effectivement, j’ai essayé ton code et ça marche au poil. Ça c’est drôlement bien. En fait, ça doit marcher dans ton code parce qu’il est minimaliste et donc que les données passent juste par des appels de fonctions basique sans aucun traitement. Il va donc falloir scruter à chaque chose que j’ajouterai autour de ça.

Ben va falloir que je trouve ce qui provoque le problème dans mes fonctions. Plus vite dit que fait… et puis j’ai pas trop le temps pour ça en ce moment, sauf à très petite dose, mais on en reparlera en temps utile.

Soit c'est parce que tu fais du post-traitement sur tes données et qu'il y a une transformation ISO quelque part, mais ça m'étonnerait.
Soit c'est parce que tu as injecté tes données via PhpMyAdmin, je ne lui fais jamais confiance pour ça... C'est un outil très pratique mais ça ne vaut pas un BackOffice pour la gestion du contenu.

hr a écrit:

Merci beaucoup pour ton aide en tout cas !

De rien ;-)

neiluj a écrit:

Soit c'est parce que tu as injecté tes données via PhpMyAdmin, je ne lui fais jamais confiance pour ça... C'est un outil très pratique mais ça ne vaut pas un BackOffice pour la gestion du contenu.

Exact. J’ai fait des essais ce matin pour vérifie cette idée et effectivement phpMyAdmin et cocoamysql lisent et écrivent des encodages faux ! En iso ça a toujours parfaitement marché alors, bêtement, je ne les avais jamais soupçonnés. On n’est jamais assez méfiant.

Comme mes sorties étaient incorrects, j’avais touillé dans mes scripts mes résultats extraits pour tenter de corriger et du coup, les données codées correctement dans la BDD par les scripts et les formulaires étaient affichés de façon fausse ! Normal, faire un utf8_encode sur une chaîne déjà en utf-8, ça ne pouvait rien donner de bon…

Maintenant que j’ai enlevé toutes ces choses parasites et que j’ai récrit les données correctement, je me rends compte que mes scripts tels que je les avais écrits au départ fonctionnent parfaitement… Le bug n’était pas chez moi, un comble tout de même ! Que de temps perdu.

Le plus drôle est que, évidemment, maintenant que les données sont correctes dans la base, elles sont affichées de façon incorrectes dans phpMyAdmin et cocoamysql !

Eh bien c’est la fin d’une longue et pénible saga et le redémarrage du développement…
Mille mercis encore, tu m’as sorti d’un sacré pétrin !

hr a écrit:

Le plus drôle est que, évidemment, maintenant que les données sont correctes dans la base, elles sont affichées de façon incorrectes dans phpMyAdmin et cocoamysql !

Eh bien c’est la fin d’une longue et pénible saga et le redémarrage du développement…!

Oui c'est le soucis auquel je suis également confronté, on ne peut toucher aux données avec PMA si on travaille en UTF-8. Il te faut un outil fait "maison" pour être certain de ne pas corrompre l'encodage. PMA est un outil puissant pour créer ses tables et les visualiser de manière simple et sans réinventer la roue à chaque fois, mais à éviter pour les "retouches" de contenu.

neiluj a écrit:

PMA est un outil puissant pour créer ses tables et les visualiser de manière simple et sans réinventer la roue à chaque fois, mais à éviter pour les "retouches" de contenu.

Je l’ai utilisé pendant longtemps sur des bases en iso sans problème et je n’ai pas pensé qu’il pouvait être aussi mauvais. Pareil pour cocoamysql qui est beaucoup plus pratique que pma pour retouche le contenu, mais a la même tare pour l’utf-8.
Tu as raison, la seule façon d’éviter le problème est de ne passer que par ses propres scripts pour le contenu, une fois la structure de la base créée avec pma ou autre chose du même genre.
Mais pour sauvegarder et restaurer une base, pma déglingue-t-il les données ? Il va falloir que je regarde ça de près avant d’envoyer la base chez l’hébergeur. Sinon je devrai aussi faire mon propre outil de sauvegarde/restauration, ce serait bête !

hr a écrit:

neiluj a écrit:

PMA est un outil puissant pour créer ses tables et les visualiser de manière simple et sans réinventer la roue à chaque fois, mais à éviter pour les "retouches" de contenu.

Je l’ai utilisé pendant longtemps sur des bases en iso sans problème et je n’ai pas pensé qu’il pouvait être aussi mauvais. Pareil pour cocoamysql qui est beaucoup plus pratique que pma pour retouche le contenu, mais a la même tare pour l’utf-8.
Tu as raison, la seule façon d’éviter le problème est de ne passer que par ses propres scripts pour le contenu, une fois la structure de la base créée avec pma ou autre chose du même genre.
Mais pour sauvegarder et restaurer une base, pma déglingue-t-il les données ? Il va falloir que je regarde ça de près avant d’envoyer la base chez l’hébergeur. Sinon je devrai aussi faire mon propre outil de sauvegarde/restauration, ce serait bête !

Je crois que si tu fais un dump avec PMA il n'y a pas de soucis, il peut t'afficher des caractères foireux mais si tu les réinjectes sans changer le charset ça fonctionne toujours.
Sinon une solution c'est d'utiliser des BLOB et de dumper en cochant l'option "Utiliser l'hexadecimal pour les BLOB", de cette manière tu es certain de ne pas avoir de perte. Par contre c'est illisible par un humain :-)


Sinon, j'ai réfléchi à cette section "Développement", et je pense que je vais vous honorer de mes quelques connaissances en la matière. J'ai cru comprendre que certains et certaines touchaient un peu ou désiraient toucher un peu plus au développement web donc je vais profiter de ce lieu pour donner quelques leçons ;-)

neiluj a écrit:

Je crois que si tu fais un dump avec PMA il n'y a pas de soucis, il peut t'afficher des caractères foireux mais si tu les réinjectes sans changer le charset ça fonctionne toujours.

Ce serait merveileux ! Je vais faire quelques essais dès que j’ai un peu de temps.

neiluj a écrit:

Sinon une solution c'est d'utiliser des BLOB et de dumper en cochant l'option "Utiliser l'hexadecimal pour les BLOB", de cette manière tu es certain de ne pas avoir de perte. Par contre c'est illisible par un humain :-)

Ah tiens, jamais essayé ce genre de choses. En cas de trouble dans les dumps, j’essayerai.

neiluj a écrit:

Sinon, j'ai réfléchi à cette section "Développement", et je pense que je vais vous honorer de mes quelques connaissances en la matière.

Honore, honore, il en restera toujours quelque chose… Bonne et généreuse idée.