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 !
Message édité par MagicBuzz le 19-06-2007 à 19:34:18