dimi3 Posté 9 Janvier 2011 Posté 9 Janvier 2011 Bonjour, Les pages de mon site sont encodées en UTF-8 car elles affichent des caractères dits exotiques (ĉ - ĝ - ŭ - etc.) . Les visiteurs entrent aussi ce type de caractères dans les formulaires. Ces entrées sont traitées via Ajax et un fichier PHP. Les entrées utilisateur dans les formulaires comportant ces caractères sont parfaitement traitées sur tous les navigateurs (Chrome, Firefox, Safari, Opera), mais sont incorrectement traitées sur Microsoft Internet explorer. Les accents ne sont pas reconnus. J'ai déjà tenté de résoudre le problème par le charset (dans le Méta ou le header), j'ai modifié manuellement le codage dans le menu "Page - codage" de la barre d'outils d'IE, j'ai essayé d'ajouter utf_encode() et utf8_decode() devant mes variables dans mes fichiers PHP, j'ai ajouté la ligne "AddDefaultCharset UTF-8" dans le htaccess du répertoire,... et que sais-je encore ! Rien n'y fait ! Je suis désespéré !!! Avez-vous une idée de l'origine du problème ? Mille mercis.
yuston Posté 9 Janvier 2011 Posté 9 Janvier 2011 Est-ce que tous tes fichiers sont correctement enregistrés en UTF-8? D'où viennent les textes? De SQL? Sinon as-tu une page d'exemple? Car cette histoire me semble étrange: seul IE afficherait mal les caractères? Et finalement, as-tu bien sûr mis la balise HTML meta charset?
dimi3 Posté 9 Janvier 2011 Auteur Posté 9 Janvier 2011 (modifié) Merci pour la réponse. Tout est en ordre pour tous les navigateurs,... sauf pour IE !!! Pas de bases de données. Voici une présentation de ce que j'ai fait : Des questions de langue sont posées sur la page affichant le formulaire. L'utilisateur entre sa réponse en utilisant des caractères latins et/ou non latins. Elle passe par un script Ajax qui permet d'afficher le retour du fichier correcteur PHP dans un DIV. Ainsi l'élève reste toujours sur la même page. La réponse est traitée par un fichier PHP qui compare la réponse entrée par l'élève à la réponse attendue. Quand la réponse n'inclut pas de caractères exotiques, la comparaison marche bien. Quand la réponse inclut des lettres exotiques, la comparaison ne fonctionne pas correctement. J'ai testé pour voir ce qui était reçu par le fichier PHP lorsqu'on entrait une lettre accentuée du type ĝ ou ŭ. Je vois que la réponse accentuée perd ses accents durant l'envoi. D'où la correction erronée renvoyée par le fichier PHP. Par exemple : j'entre le mot " ĉerizo " dans le formulaire. Le test me montre que le fichier PHP reçoit le mot " cerizo " sans accent sur la lettre "c". Schématiquement : formulaire questionnaire ---> script Ajax ---> fichier PHP pour comparaison réponse utilisateur/réponse attendue---> affichage de la correction dans un DIV de la page formulaire de type "Votre réponse est exacte" ou "Votre réponse est inexacte". J'imagine qu'internet explorer a besoin de quelque chose de plus que les autres navigateurs pour bien faire transiter les réponses accentuées sans perdre les accents... mais quoi ???? Modifié 9 Janvier 2011 par Patrick
dimi3 Posté 10 Janvier 2011 Auteur Posté 10 Janvier 2011 Mon message a été modifié par Patrick ? Finalement, ne trouvant pas de solution aux caprices d'Internet Explorer, j'ai ajouté une fonction de remplacement de caractères dans mon programme avant de traiter la réponse. Le programme est légèrement ralenti mais il marche.
Portekoi Posté 10 Janvier 2011 Posté 10 Janvier 2011 Bonjour, Essaie avec la fonction encodeURIComponent() lors de l'envoi de données via Ajax Portekoi
dimi3 Posté 10 Janvier 2011 Auteur Posté 10 Janvier 2011 Bonjour, Essaie avec la fonction encodeURIComponent() lors de l'envoi de données via Ajax Portekoi merci de ta réponse. L'entrée utilisateur est bien envoyée avec tous ses accents. J'ai vérifié par une alert(). C'est au traitement par le fichier PHP que tout se gâte. Sur Internet Explorer uniquement !
MarvinLeRouge Posté 11 Janvier 2011 Posté 11 Janvier 2011 Salut, Ça colle pas : ton alert se passe avant l'envoi des données par la navigateur, donc le test n'est pas bon, à mon avis. Mets dans tn script php, immédiatement après la réception des données, un appel à une fonction qui logge les données reçues en ajax. Et compare avec IE ou sans IE. T'aurais une url de test ?
dimi3 Posté 11 Janvier 2011 Auteur Posté 11 Janvier 2011 Mets dans tn script php, immédiatement après la réception des données, un appel à une fonction qui logge les données reçues en ajax. Et compare avec IE ou sans IE. T'aurais une url de test ? Merci de ta réponse. J'avais testé la réponse aussi à son entrée dans le code de traitement PHP et j'obtenais tout bonnement une réponse non accentuée. Le mot "ĉerizo" était devenue "cerizo" sur le navigateur IE mais était bien "ĉerizo" sur les autres navigateurs. Du fait que, ne trouvant pas de solution - et Dieu sait si j'en ai cherché : j'ai passé deux journées là-dessus !!! - j'ai changé le code PHP afin qu'il remplace les caractères accentués par d'autres caractères non accentués avant de procéder au traitement, tout fonctionne sur tous les navigateurs et je n'ai plus d'url générant le problème.
Portekoi Posté 11 Janvier 2011 Posté 11 Janvier 2011 Prends NotePad++ et vérifie que le fichier PHP est encodé en UTF-8 (sans Bom) Ajoute dans ton fichier php tout en haut, en première ligne (sauf si session) : header ('Content-type: text/html; charset=utf-8');
dimi3 Posté 11 Janvier 2011 Auteur Posté 11 Janvier 2011 (modifié) J'utilise toujours Notepad++. Mes fichiers sont bien enregistrés en UTF8 sans BOM. Quant au header, je ne peux le mettre en raison d'un session_start(). Franchement je me demande ce que je devrais faire de plus pour qu'IE arrête de faire des caprices. Modifié 11 Janvier 2011 par Patrick
Portekoi Posté 12 Janvier 2011 Posté 12 Janvier 2011 Bonjour, Je n'ai jamais eu de soucis en mettant session_start() et l'encodage pour UTF8... Là, je pige pas ton problème Portekoi
dimi3 Posté 12 Janvier 2011 Auteur Posté 12 Janvier 2011 (modifié) Je n'ai jamais eu de soucis en mettant session_start() et l'encodage pour UTF8... Là, je pige pas ton problème Portekoi J'ai cru comprendre que le header devait toujours être en première ligne de code. J'ai testé à l'instant. Ca n'a pas résolu le problème. Modifié 12 Janvier 2011 par dimi3
captain_torche Posté 12 Janvier 2011 Posté 12 Janvier 2011 Non, il doit être avant tout envoi de données au navigateur. Donc tu peux très bien faire un session_start() puis un header() (Dans ce sens, bien entendu : le session_start doit se faire avant tout envoi d'en-têtes).
dimi3 Posté 12 Janvier 2011 Auteur Posté 12 Janvier 2011 Non, il doit être avant tout envoi de données au navigateur. Donc tu peux très bien faire un session_start() puis un header() (Dans ce sens, bien entendu : le session_start doit se faire avant tout envoi d'en-têtes). J'ai encore appris quelque chose aujourd'hui ! Merci.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant