Bonjour,

J'ai du contourner le problème pour pouvoir passer à autre chose, mais effectivement, la commande
// PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8',
a été mise en commentaire car elle posait des problèmes dans d'autre parties du code ( bdd partiellement pas en utf8 de mémoire).

La prochaine fois que j'aurai des données a importer de la sorte, je décommenterai la ligne pour voir si cela résoudra le problème.
Je vous tiens au courant.
Merci.

As-tu bien précisé le charset lors de ta connexion PDO ?
Cf 1er commentaire ici : http://php.net/manual/fr/pdo.construct.php

Je pense avoir cerné le problème et trouvé une solution... sans le résoudre pour autant.

Bien que je positionne des charset en utf-8 partout, je résous une majorité des problèmes en faisant une requête update depuis Mysql ( c'est important).
Si je prends cette requète et que je l'exécute en pdo dans un script php, j'ai une modification de charset quelque part.

J'ai beau relire mon code, pour l'instant, je ne trouve pas.

interprétation du ü en ÃŒ

Mon impression c'est que ça ressemble à un double encodage UTF8.
J'ai mpeut être mal compris ce que tu as dit précédement, mais il m'a semblé avoir compris que ton décodage fonctionnait bien en dev, et c'est uniquement lors du transfert de ta BDD (corrigée?) de la dev vers la prod que tu as un pb, c'est bien ça ?

@ @arthur : En fait, je n'ai ce problème qu'avec une partie des enregistrements, une majorité d'autres avec caractères particuliers passent très bien.

Je recherche donc un charset proche de ceux précités ( Windows-1252 , ISO-8859-15 et ISO-8859-1) que je pourrais essayer et qui corrigerait cette interprétation du ü en ÃŒ

Le problème, c'est que lorsque je transfère mes données de ma table temporaire vers ma table de production, j'ai, quelle que soit le charset utilisé une discordance entre la source et la table de destination. En effet,

MüHLENSTRASSE devient MÃŒHLENSTRASSE.

Il faut que tu vérifies que le charset utilisé à l'export correspond bien à celui à l'import, et que bien sûr tes 2 bases de données aient la même configuration de charset.

Fait un export uniquement sur 1 enregistrement pour tester et pouvoir corriger/vérifier que tout soit ok

Bonjour,

Je viens vers vous après 3 jours d'arrachage de cheveux et un mal de crâne qui s'installe bien.
J'ai récupéré un fichier de donnée contenant des points d'intérêts , quelque part sur le net et je suis en train de le parser pour intégrer son contenu dans une base de donnée Mysql.

Ne connaissant pas le charset du fichier, j'ai utilisé une fonction (trouvée sur le net également) qui permet d'aider à l'identification du jeu de caractère du fichier: double boucle sur un tableau de nom de charset a utiliser, et conversion de la chaine avec ces élements. Si l'output est lisble, c'est un bon candidat.

J'obtiens divers résultats à éliminer directement, du genre:
Windows-1252 Windows-1252
M�HLENSTRASSE
ou encore :
ISO-8859-15 ISO-8859-1
M�HLENSTRASSE

Mais d'autres résultats sont beaucoup plus prometteurs comme :
Windows-1252 UTF-8
ISO-8859-15 UTF-8
et
ISO-8859-1 UTF-8
qui me renvoient tous MüHLENSTRASSE.

Le problème, c'est que lorsque je transfère mes données de ma table temporaire vers ma table de production, j'ai, quelle que soit le charset utilisé une discordance entre la source et la table de destination. En effet,

MüHLENSTRASSE devient MÃŒHLENSTRASSE.

Quelqu'un peut-il m'aider à identifier la source du problème ? Voir déterminer quel autre charset j'aurais dû utiliser ? En effet, il est possible qu'aucun des 3 précités ne convienne.