Erwan David <[EMAIL PROTECTED]> writes: >> Le support de quoi ? Cette variable d�sactive l'UTF-8 au profis de ta >> locale oui ... c'est pas un support, c'est un basculement de choix. > > Donc le code pour les 2 est dans le la lib... > Les 2 sont support�s... Si en plus ma locale est UTF-8 je suppose > qu'il se d�brouille... Le code *peut* traiter les situations. mais on > pr�f�re emmerder l'utilisateur plut�t que de le faire de fa�on > transparente. >
Tu ne comprends pas le probl�me. On sait lire les 2 types de codage, mais pas d�tecter lequel est utilis�. Donc c'est � toi de sp�cifier le format � utiliser. Tu ne peux *pas* traiter les situations de mani�re transparente donc (ie: tu ne peux pas ouvrir un fichier en UTF8 et un en ISO-8859-15 automatiquement sans te planter sur un des deux). Arr�te de penser que les programmeurs font tout ce qu'ils peuvent pour "emmerder" les utilisateurs, c'est archi faux ... > C'est un choix. Encore une fois, NON. Ou alors donne nous ta solution pour d�tecter l'encodage d'un fichier automatiquement. > (PS: on peut *aussi* v�rifier qu'une chaine est une chaine UTF-8 > valide et si ce n'est pas le cas l'interpr�ter selon la locale, y'a > *plein* de moyens de le faire...) Le probl�me est plus complexe : * une chaine encod�e dans ta locale peut-�tre valide en UTF8, donc affichable. Le probleme c'est que affichable ne veut pas dire correcte ... donc le r�sultat � l'�cran ne sera pas forcement le reflet du message d'origine. * tu peux avoir 5 types d'encodages diff�rents dans tes fichiers, il est incorrect de penser que si la chaine n'est pas UTF-8 alors elle est de ta locale ... un tel comportement serait �ronn� et provoquerait des bugs de mani�re al�atoire. Les d�veloppeurs de GTK+ ont voulu faire une API au comportement pr�visible, et c'est bien mieux ainsi que de faire des suppositions de fonctionnement au pif. Salutations, Sebastien Bacher
