Bonjour !
 
J'ai une question de culture générale :
 
Lorsqu'on fait un site internet avec php et mysql, y a-t-il un intérêt particulier d'écrire ses fichiers .php avec l'encodage utf8 ?  
 
J'ai cru comprendre que utf8 serait plus simple d'emploi, mais je ne comprends pas pourquoi on dit ça.  
 
Merci de vos opinions.  
 
Thiebo

Si ton site doit afficher ou traiter des langues differentes, alors oui, l'UTF-8  et l'unicode en général sont interessant: Quand tu travail entierrement en unicode, tu n'a pas à te soucier à transcoder tes caractères d'un codage à un autre.

C'est tout ? Mon site est entièrement en français, donc je n'ai pas ce souci-là.  
Merci pour ta réponse en tous cas.

 
...Pourtant il n'est pas difficile de te donner un peu de souci. Le français, par exemple, comporte un caractère appelé "e-dans-l'o" d'un usage fréquent, surtout en minuscule (DIGRAMME SOUDÉ MINUSCULE LATIN OE, U+0153).
 
Ce caractère n'est pas présent dans le jeu US-Ascii, donc absolument intransportable sans un minimum de réflexion. Mieux: il est absent du jeu Latin-1 qui est la "langue" support du PHP. Autrement dit, l'ISO-8859-1 est incapable de coder ce caractère. Certes, on le trouve en Latin-9, c'est-à-dire que l'ISO-8859-15 sait l'exprimer... au rang 0xBD, donc à l'emplacement où l'ISO-8859-1 (et Unicode) verraient le caractère FRACTION UN DEMI!
 
Par ailleurs, ce fameux caractère "e-dans-l'o" réside dans le jeu Windows Occidental (càd CP1252, trop vulgairement appelé "Ansi Windows", à tort) à l'emplacement... 0x9C, lequel se situe dans une zone de code réservée des jeux ISO-8859-x et correspond en Unicode à un caractère de commande ("fin de chaîne" ). Pour varier les plaisirs, il se trouve en MacRoman au rang 0xCF.
 
Cela signifie qu'un utilisateur qui "tape" un e-dans-l'o dans tel ou tel système d'exploitation, sous réserve du "charset" dans lequel travaille son logiciel d'édition, va charger tantôt l'octet correspondant à 0xCF, tantôt à 0x9C, tantôt à une toute autre valeur. Je te passe évidemment la problématique du serveur PHP et de la base MySQL hébergée sous Linux qui vont "stocker" ce e-dans-l'o.
 
De son côté, l'UTF-8 -- qui n'est pas un jeu de caractères mais une traduction sur 1 à 4 octets d'un caractère Unicode (codé sur 1 à 21 bits) -- peut te parvenir malgré toi sous la forme de "chaînes Latin-1" (si l'on me passe cette simplification) par le biais d'un formulaire HTML par exemple (les MIME dans la filière POP et SMTP sont assez amusants aussi, de ce point de vue là). L'utilisateur distant -- dont tu ignores l'OS -- t'envoie un "e-dans-l'o"... c'est-à-dire? quelle valeur numérique, dans l'absolu?
 
Eh bien, dans l'absolu -- si l'émetteur s'est vraiment montré Unicode-friendly -- l'UTF-8 devrait cracher deux octets pour coder U+0153: 0xC5 et 0x93 (si je ne m'abuse), ce qui pourrait apparaître en Latin-1 sous la forme d'un "A majuscule rond en chef" suivi d'un caractère à la con (dépendant du système récepteur) car 0x93 n'existe pas dans le codage ISO-8859-1.
 
Bon, j'arrête là...
 
La question ultime de cet exercice est de savoir quel charset spécifier dans l'http-equiv de ta page HTML générée par PHP au sortir de ce formulaire transitant par un stockage MySQL.
 
Au fait, voici la solution que HFR a trouvé pour restituer un "e-dans-l'o d'origine" CP-1252 (0x9C): œ
Est-ce bien raisonnable?

Merci ACut pour cette réponse très complète. Je fait tout en UTF-8 maintenant :les fichiers .php, les tables mysql et l'interconnection aussi grâce à  la commande  
 
mysql_query("SET NAMES 'UTF8'" );
$resultat = mysql_query ($requete, $this->connexion);
 
Thiebo

A noter que MySQL depuis 4.1 a vu apparaitre l'interclassement dans les tables et les champs "textes"
Par ailleur on s'en sert avec php avec mysqli et la commande mysqli-set-charset (ici http://fr2.php.net/manual/fr/funct [...] harset.php )

php et mysqli oui, mais ces commandes n'existent pas pour mysql...
mysql 4.1 et 5 connaissent ces commandes, que j'ai exécutées bien sûr, mais la connection php -> mysql restait quand même en latin1. Il me faut la commande indiquée ci-dessus pour que tout rentre dans l'ordre !

non mais bon mysql 4.1 est stable depuis 1 an et la 5 vient de sortir en production donc tout baigne depuis un moment