J'utilise de l'ajax pour mettre à jour une liste de choix en fonction
d'une autre.
Dans ce cadre, le serveur doit renvoyer des informations qui intègrent
le caractère euro ¤. Cependant le résultat à l'affichage dans la liste
de choix donne le signe ? en lieu et place du ¤.
Je suppose que ce problème vient de l'instruction :
xhr_object.setRequestHeader("Content-type",
"application/x-www-form-urlencoded"); méthode d'envoi POST
Comment puis-je le modifier pour que xhr_object.responseText me renvoie
des ¤ au lieu de ?.
On ne te demande pas le charset que tu déclare à l'intention du serveur Web, mais du charset *réel* de codage de la page. C'est à dire dans quel charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils seront mal encodés dans la page servie (que ce soit via un Ajax ou autre, peut importe).
On ne te demande pas le charset que tu déclare à l'intention du
serveur Web, mais du charset *réel* de codage de la page. C'est à dire
dans quel charset ton éditeur favori sauvegarde le/les fichiers sources
PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des
script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en
utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le
caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les
octets en swedish machin issus de la base ne sont pas traduits en utf-8,
ils seront mal encodés dans la page servie (que ce soit via un Ajax ou
autre, peut importe).
On ne te demande pas le charset que tu déclare à l'intention du serveur Web, mais du charset *réel* de codage de la page. C'est à dire dans quel charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils seront mal encodés dans la page servie (que ce soit via un Ajax ou autre, peut importe).
J'utilise de l'ajax pour mettre à jour une liste de choix en fonction d'une autre.
Dans ce cadre, le serveur doit renvoyer des informations qui intègrent le caractère euro ¤. Cependant le résultat à l'affichage dans la liste de choix donne le signe ? en lieu et place du ¤.
Je suppose que ce problème vient de l'instruction : xhr_object.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); méthode d'envoi POST
Comment puis-je le modifier pour que xhr_object.responseText me renvoie des ¤ au lieu de ?.
Euh, non. Il s'agit du header de la requête http faite au serveur, et son content-type est application/x-www-form-urlencoded, pas text/html.
Euh, non. Le content-type du header n'est pas nécessairement "application/x-www-form-urlencoded", il peut être ce que tu veux. A toi ensuite de gérer convenablement ce que tu reçois sur ton serveur.
Oui, bon. Je l'ai dit comme un manche, mais on ne change pas le header content-type de ce qu'on envoie sans faire en sorte de l'envoyer au format annoncé, - et que le receveur s'attende à ce format, - au moins sous peine de surprises dues aux différents frameworks utilisés.
Ça ne me semble pas une manière raisonnable d'étudier le problème.
-- Mayeul
Cenekemoi a écrit :
Bonjour à Mayeul <mayeul.marguet@free.fr> qui nous a écrit :
Cenekemoi a écrit :
Bonjour à Davy Crockett <davy@crockett.fr> qui nous a écrit :
Bonjour,
J'utilise de l'ajax pour mettre à jour une liste de choix en
fonction d'une autre.
Dans ce cadre, le serveur doit renvoyer des informations qui
intègrent le caractère euro ¤. Cependant le résultat à l'affichage
dans la liste de choix donne le signe ? en lieu et place du ¤.
Je suppose que ce problème vient de l'instruction :
xhr_object.setRequestHeader("Content-type",
"application/x-www-form-urlencoded"); méthode d'envoi POST
Comment puis-je le modifier pour que xhr_object.responseText me
renvoie des ¤ au lieu de ?.
Euh, non. Il s'agit du header de la requête http faite au serveur, et
son content-type est application/x-www-form-urlencoded, pas text/html.
Euh, non. Le content-type du header n'est pas nécessairement
"application/x-www-form-urlencoded", il peut être ce que tu veux. A toi
ensuite de gérer convenablement ce que tu reçois sur ton serveur.
Oui, bon. Je l'ai dit comme un manche, mais on ne change pas le header
content-type de ce qu'on envoie sans faire en sorte de l'envoyer au
format annoncé, - et que le receveur s'attende à ce format, - au moins
sous peine de surprises dues aux différents frameworks utilisés.
Ça ne me semble pas une manière raisonnable d'étudier le problème.
J'utilise de l'ajax pour mettre à jour une liste de choix en fonction d'une autre.
Dans ce cadre, le serveur doit renvoyer des informations qui intègrent le caractère euro ¤. Cependant le résultat à l'affichage dans la liste de choix donne le signe ? en lieu et place du ¤.
Je suppose que ce problème vient de l'instruction : xhr_object.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); méthode d'envoi POST
Comment puis-je le modifier pour que xhr_object.responseText me renvoie des ¤ au lieu de ?.
Euh, non. Il s'agit du header de la requête http faite au serveur, et son content-type est application/x-www-form-urlencoded, pas text/html.
Euh, non. Le content-type du header n'est pas nécessairement "application/x-www-form-urlencoded", il peut être ce que tu veux. A toi ensuite de gérer convenablement ce que tu reçois sur ton serveur.
Oui, bon. Je l'ai dit comme un manche, mais on ne change pas le header content-type de ce qu'on envoie sans faire en sorte de l'envoyer au format annoncé, - et que le receveur s'attende à ce format, - au moins sous peine de surprises dues aux différents frameworks utilisés.
Ça ne me semble pas une manière raisonnable d'étudier le problème.
On ne te demande pas le charset que tu déclare à l'intention du serveur Web, mais du charset *réel* de codage de la page. C'est à dire dans quel charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils seront mal encodés dans la page servie (que ce soit via un Ajax ou autre, peut importe).
en fait la base de données envoie un montant sans symbole monétaire. Puis via un echo en PHP j'associe le montant au signe ¤. C'est pour ça que je dis que l'encodage de la base de donées n'est pas en cause.
Cf le code du fichier php de traiment que j'ai fourni dans le fil de discussion
On ne te demande pas le charset que tu déclare à l'intention du serveur
Web, mais du charset *réel* de codage de la page. C'est à dire dans quel
charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter
que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en
un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en
utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère
¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les
octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils
seront mal encodés dans la page servie (que ce soit via un Ajax ou autre,
peut importe).
en fait la base de données envoie un montant sans symbole monétaire.
Puis via un echo en PHP j'associe le montant au signe ¤. C'est pour ça
que je dis que l'encodage de la base de donées n'est pas en cause.
Cf le code du fichier php de traiment que j'ai fourni dans le fil de
discussion
On ne te demande pas le charset que tu déclare à l'intention du serveur Web, mais du charset *réel* de codage de la page. C'est à dire dans quel charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils seront mal encodés dans la page servie (que ce soit via un Ajax ou autre, peut importe).
en fait la base de données envoie un montant sans symbole monétaire. Puis via un echo en PHP j'associe le montant au signe ¤. C'est pour ça que je dis que l'encodage de la base de donées n'est pas en cause.
Cf le code du fichier php de traiment que j'ai fourni dans le fil de discussion
On ne te demande pas le charset que tu déclare à l'intention du serveur Web, mais du charset *réel* de codage de la page. C'est à dire dans quel charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils seront mal encodés dans la page servie (que ce soit via un Ajax ou autre, peut importe).
en fait la base de données envoie un montant sans symbole monétaire. Puis via un echo en PHP j'associe le montant au signe ¤. C'est pour ça que je dis que l'encodage de la base de donées n'est pas en cause.
Du coup, en effet, le charset de la base de données n'intervient pas.
Mais le charset du fichier .php de la page, lui, intervient. Et le charset de la page qui appelle cet AJAX aussi.
Assure-toi que ton fichier .php est bien enregistré en utf-8. Et que la page qui appelle cet AJAX est bien en utf-8 aussi: - Son fichier est enregistré en utf-8, - Elle est servie avec le header Content-Type: text/html; charset=utf-8 - Indiquer un header n'est pas la même chose que mettre une balise <meta>. La balise <meta> ne sera utilisée que s'il n'y a pas de header Content-Type
On ne te demande pas le charset que tu déclare à l'intention du
serveur Web, mais du charset *réel* de codage de la page. C'est à dire
dans quel charset ton éditeur favori sauvegarde le/les fichiers
sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de
charger des script encodés en un autre encodage peut fournir des
surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites
en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le
caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si
les octets en swedish machin issus de la base ne sont pas traduits en
utf-8, ils seront mal encodés dans la page servie (que ce soit via un
Ajax ou autre, peut importe).
en fait la base de données envoie un montant sans symbole monétaire.
Puis via un echo en PHP j'associe le montant au signe ¤. C'est pour ça
que je dis que l'encodage de la base de donées n'est pas en cause.
Du coup, en effet, le charset de la base de données n'intervient pas.
Mais le charset du fichier .php de la page, lui, intervient. Et le
charset de la page qui appelle cet AJAX aussi.
Assure-toi que ton fichier .php est bien enregistré en utf-8. Et que la
page qui appelle cet AJAX est bien en utf-8 aussi:
- Son fichier est enregistré en utf-8,
- Elle est servie avec le header Content-Type: text/html; charset=utf-8
- Indiquer un header n'est pas la même chose que mettre une balise
<meta>. La balise <meta> ne sera utilisée que s'il n'y a pas de header
Content-Type
On ne te demande pas le charset que tu déclare à l'intention du serveur Web, mais du charset *réel* de codage de la page. C'est à dire dans quel charset ton éditeur favori sauvegarde le/les fichiers sources PHP. À noter que sauvegarder un fichier PHP en UTF-8 et de charger des script encodés en un autre encodage peut fournir des surprises de taille.
Est-ce que tu demandes à ta base de renvoyer les données traduites en utf-8 ?
En fait ma base de données , n'intervient pas à ce niveau, car le caractère ¤ est issu du code PHP de la page qui sert de traitement.
Oui, donc le charset de la base de donnée intervient. Puisque si les octets en swedish machin issus de la base ne sont pas traduits en utf-8, ils seront mal encodés dans la page servie (que ce soit via un Ajax ou autre, peut importe).
en fait la base de données envoie un montant sans symbole monétaire. Puis via un echo en PHP j'associe le montant au signe ¤. C'est pour ça que je dis que l'encodage de la base de donées n'est pas en cause.
Du coup, en effet, le charset de la base de données n'intervient pas.
Mais le charset du fichier .php de la page, lui, intervient. Et le charset de la page qui appelle cet AJAX aussi.
Assure-toi que ton fichier .php est bien enregistré en utf-8. Et que la page qui appelle cet AJAX est bien en utf-8 aussi: - Son fichier est enregistré en utf-8, - Elle est servie avec le header Content-Type: text/html; charset=utf-8 - Indiquer un header n'est pas la même chose que mettre une balise <meta>. La balise <meta> ne sera utilisée que s'il n'y a pas de header Content-Type
-- Mayeul
Davy Crockett
Mayeul a émis l'idée suivante :
- Elle est servie avec le header Content-Type: text/html; charset=utf-8
Ok j'ai juste rajouté ça dans le fichier de traitement PHP.
Header("Content-Type","text/html;charset=UTF-8");
Ca marche maintenant.
Merci à tous pour vos éclaircissements.
Mayeul a émis l'idée suivante :
- Elle est servie avec le header Content-Type: text/html; charset=utf-8
Ok j'ai juste rajouté ça dans le fichier de traitement PHP.
