ybob a écrit :sly a écrit :Vu que chacun semble bosser de son coté ;-)
Je n'ai rien touché d'autre, il s'agit donc du jeu des erreurs a trouver et voir si cette méthode est ou non viable et si je dois continuer ou non sur cette voie.
Le charset associé de la table et des columns est donc encore
latin1 , avec de l'UTF8 dedans ?
Disons que j'ai tenté plein de truc et que j'ai l'impression que plusieurs phénomène se télescopent...
J'ai utilisé mysqldump pour récupérer une copie de la base que j'imaginais donc être en iso, je l'ai converti par iconv et voilà-t-il pas que je me retrouve avec un double encodage UTF-8 (en gros je me retrouve avec ça : "Refuge rentré hélas un peu rapidement" alors que ma page est bien déclarée en utf-8)
Je creuse la doc et je vois que mon dump est en fait en utf8 ! Et ça semble être une fourberie de mysqldump lié à une locale de mon linux.
Z'y va alors, je récupère mon dump, je change toutes les occurences de CHARSET=latin1 en CHARSET=utf8 et zou.
Et paf, presque, mais pas tout à fait. Mes tables ont un interclassement "utf8_general_ci", avec phpmyadmin tout roule et s'affiche bien, mais sur ma copie du site j'ai une partie seulement qui s'affiche convenablement, et aller savoir pourquoi, le contenu en provenance de certaines tables foire dans la colle... misère
Là, ton idée du "SET NAMES UTF-8" semble d'importance, car si je l'active juste après tous les mysql_connect, ça inverse tout, ce qui s'affichait bien s'affiche mal, et ce qui s'affichait mal s'affiche bien.
Argh ! En général, quand c'est comme ça, c'est qu'une partie n'a pas l'encodage de l'autre partie. Mais pourtant, pourtant si j'ouvre mon fichier sql, tout semble en utf-8 (moins toutefois par ci par là des signe euros et des caractères qui n'ont semble-t-il pas pû être converti en utf8)
Est-ce que par la simple présence de ces caractères foireux par endroit seulement, mysql refuse d'activer mon "SET NAMES UTF-8" sur les tables qui en contiennent ? possible...
sly a écrit :
La page... "marche" maintenant et révèle donc que la conversion vers UTF8 n'a semble-t-il été que partielle
Si rien d'autre a été modifié, il y a de bonne chance que les requêtes mysql/php continuent a travailler en ISO, ainsi que le Header renvoyé (du protocole HTTP, en plus de celui du HTML)
L'en-tête http (vérifié avec wget -S) est bon, il reste des reliques dans le HTML par endroit, mais que je les laissent ou les enlèves, ça ne change rien, j'imagine que l'en-tête "Content-Type: text/html; charset=UTF-8" prend le dessus.
Par contre, l'hypothèse que php continuer à communiquer en iso, parfois, semble la bonne piste, pourtant je fais la même chose qu'elles que soient les tables.
Retour donc à mon hypothèse qui serait que parce qu'une table contient du "caca" le passage en utf8 de l'interconnexion php<->mysql n'ai pas prise en compte.
Je vais creuser et je vais tenter la bonne vielle technique du : je vide tout sauf un enregistrement, je test, j'en ajoute un autre, je test et je vois à partir de quel moment ça foire
Oh et puis [censuré], si tout le monde bosse, je devrais m'y mettre aussi. vous acceptez encore les revenants ? même des années après ?
Ké revenant ?
On accepte tout le monde, les humains, les revenants, les zombies, les martiens, les jaunes, les bleus, les chiens et les chats ! du moment que quelqu'un veut nous prêter main forte il est le bienvenu, refuges.info est un projet libre ouvert à tout le monde !
Je peux te passer une copie complète du code + dump de la base si tu veux tenter, no problèmes.
Ta phrase doit cacher quelque chose mais j'ignore quoi.
Mmmm "ybob" ? quelqu'un qu'on est censé connaître ?
Un lien de parenté avec le mercenaire Bob Denard ? (ne le prend pas mal, c'est une forme de blague, mais si tu comprends la feinte, alors j'ai deviné, sinon, je donne ma langue à un dromadaire marocain)
