Bonjour à tous,
 
Je vais faire simple : J'ai une base de données sauvegardée a l'aide de PhpMyAdmin. En voulant la remettre, tous les caractères type accents ... s'affichent en petits carrés noirs. Le problème est sans aucun doute un problème d'encodage, puisqu'en réglant manuellement ISO-8859-1 dans Firefox cela marche parfaitement.
 
Le charset-type étant défini dans la page comme iso-8859-1, comment puisje convertir la base de données dans un type compatible afin que mon site s'affiche de nouveau correctement ?
 
Merci d'avance
 
WiiDS
 
PS : Le urgent aidez moi célafindumonde toussa d'habitude c'est pas mon truc mais la je suis bien dans la panade

http://dev.mysql.com/doc/refman/5.0/fr/charset.html

Incompréhensible

Ben c'est pourtant là dedans que tu vas trouver ton bonheur

Ou pas
 
En mettant le contenu ci dessous dans un htaccess ca rulz da world
 
AddDefaultCharset iso-8859-1
AddCharset ISO-8859-1 .html
AddCharset ISO-8859-1 .php
 
Mon hébergeur n'étant autre qu'un ami avec un dédié, il a du foirer sa config
 
En tout cas merci a toi MagicBuzz

Revoie quand même ta config générale. Parceque ton HTML ne doit pas être contradictoire avec le reste.
 
D'ailleurs, il faut configurer le serveur web pour publier le charset désiré avec le content-type (header HTTP)
 
Et ne pas remettre cette info dans le HTML ni htaccess, ça sert à rien d'autre que de foutre la merde.
 
Mais s'assurer avant en amont que ta base est bien configurée (et je supposais que ton serveur était correctement configuré, mais pas la base )
 
Question à deux balles : pkoi ISO-8859-1 ?
 
1/ Elle est dépréciée, il faut utiliser la -15
2/ La windows-1252 en est une surcharge contenant quelques corrections -donc plus adaptée- (et contrairement à son nom, elle est reconnue par tous les systèmes)
3/ Sâchant qu'aujourd'hui ne pas faire de l'UTF-8 c'est un peu se tirer une balle dans le pied (tu fais quoi si demain y'a un suédois qui veut poster des trucs sur ton site ?)

attention, je ne sais pas si c'est encore le cas, mais un moment, j'ai eux des problèmes avec phpMyAdmin qui gère mal les encodages sur ces formulaires, etc. (import/export par de problème par contre)

1) Je sais, il parait meme que UTF8 c'est bien
2) Ca je savais pas, bon a savoir
3) C'est son problème
 
Plus sérieusement j'utilise aussi un PunBB donc s'il me fallait tout convertir etc ... la galère. Ma base est en latin1_general_ci
 
Mais pour un futur site j'y penserais, thx

En tout cas, tu peux passer en -15 sans souci à partir du -1, ça rajoute juste le support de nouveau caractères, ça touche pas les existants (d'ailleurs généralement c'est automatiquement supporté par le navigateur : € n'existe pas en -1, mais pourtant il s'affiche normalement sur un site en -1 )
 
Pour windows-1252 idem, ça doit passer à partir d'un -1.

Mais après niveau BDD ca risque pas de causer des soucis ?

Non, ça reste du latin-1 de toute façon.
Je te dis, c'est juste des surcharges.
 
A noter que dans le SGBD, tu peux stocker tes textes n'importe comment de toute façon. Il saura les relire du moment que dans le PHP tu écris avec un charset précis et que tu relis avec le même charset.
 
J'ai longtemps travaillé sur un site en UTF-8 mélangeant la plupart des langues occidentales, mais aussi de l'hébreux et quelques langues asiatiques... Le SGBD était configuré en ASCII-US
 
Le seul truc, c'est que autant pour faire des LIKE ça ne pose pas (trop) de problème, autant pour les recherches FULLTEXT SEARCH ou SOUNDEX, évidement ça ne marche pas
 
Mais sorti de ça, je n'ai jamais eu le moindre problème de caractères.
 
Exemple :
 
En UNICODE (donc UTF-8) le caractère japonais "あ" a le code héxa 3042.
 
Si je stocke ça dans une variable ASCII, le SGBD va se dire "3042" = caractère 30 + caractère 42, soit "0B".
 
Mais à la relecture, le site va dire "30" est une valeur en UNICODE qui attends un second caractère, donc je lis aussi le 42 qui suit, et reconstituer le "あ"
 
Si je fais un LIKE '%あ%', alors le SGBD va faire un LIKE '%0B%' et va donc retrouver ma ligne.
Seul hic, si j'ai un caractère qui termine par le code 30, suivit d'un caractère qui comment par le code 42, je vais le trouver aussi, donc je vais avoir des résultats parfois bizarres.
Pour SOUNDEX() évidement, 0B ça se prononce "zerobi" ou "obi", tandis que あ se prononce "a", il ne va donc pas trouver !
Idem pour FULLTEXT SEARCH, qui va détecter 0B comme un code ou autre, un statement à ignorer et non à indexer, on ne pourra donc jamais mettre la main dessus !