J'ai un problème de décodage des données soumises via des formulaires.
Plusieurs formulaires (sur des serveurs différents et utilisant des
codages différents) doivent soummettre de données à une même
application. Mon souci est de détecter dans cette application, le
codage des données soumises.
Pour l'illustrer, voici deux formulaires identiques sauf que l'un
soumet ses données codées en utf8 et l'autre en iso-8859-1 :
Si je saisie le même caractère "é" dans le champ texte mais cette fois
avec le second formulaire, voici un extrait de la requête HTTP qui est
transmise (par firefox) :
é
-----------------------------12732967551707535069857896562--
++++++++++++++++++++++++++++++++++++++++
Les autres en-têtes des deux requêtes sont similaires. Firefox a bien
respecté le codage demandé (utf8 dans un cas et iso-8859-1 dans
l'autre) par chacun des deux formulaires.
De plus, MIME permet de spécifier le codage de chacun des différents
éléments d'un message multipart/form-data. Pourquoi Firefox ne
l'indique pas dans sa requête ?
Merci.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Ou n'utiliser des form multipart/form-data que pour envoyer des fichiers ?
En utilisant application/x-www-form-urlencoded ? C'est encore pire puisqu'on ne peut utiliser que de l'ASCII !
(...)
Donc, a priori, dès qu'on envoie autre chose que de l'ASCII, on devrait utiliser multipart/form-data....
Je pensais à un form en POST avec les données à saisir, et un form dédié à l'envoi de fichier et uniquement à ça. Mais j'ai le sentiment de manquer d'éléments solides, il faut que je me replonge dans ce sujet et ce ne sera pas avant ce WE.
Paul Gaborit wrote:
Ou n'utiliser des form multipart/form-data que pour envoyer des fichiers ?
En utilisant application/x-www-form-urlencoded ? C'est encore pire
puisqu'on ne peut utiliser que de l'ASCII !
(...)
Donc, a priori, dès qu'on envoie autre chose que de l'ASCII, on
devrait utiliser multipart/form-data....
Je pensais à un form en POST avec les données à saisir, et un form dédié
à l'envoi de fichier et uniquement à ça.
Mais j'ai le sentiment de manquer d'éléments solides, il faut que je me
replonge dans ce sujet et ce ne sera pas avant ce WE.
Ou n'utiliser des form multipart/form-data que pour envoyer des fichiers ?
En utilisant application/x-www-form-urlencoded ? C'est encore pire puisqu'on ne peut utiliser que de l'ASCII !
(...)
Donc, a priori, dès qu'on envoie autre chose que de l'ASCII, on devrait utiliser multipart/form-data....
Je pensais à un form en POST avec les données à saisir, et un form dédié à l'envoi de fichier et uniquement à ça. Mais j'ai le sentiment de manquer d'éléments solides, il faut que je me replonge dans ce sujet et ce ne sera pas avant ce WE.
Gerard Menvussa
Paul Gaborit wrote:
[...] Les autres en-têtes des deux requêtes sont similaires. Firefox a bien respecté le codage demandé (utf8 dans un cas et iso-8859-1 dans l'autre) par chacun des deux formulaires.
De plus, MIME permet de spécifier le codage de chacun des différents éléments d'un message multipart/form-data. Pourquoi Firefox ne l'indique pas dans sa requête ?
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est agaçant. Par curiosité j'aimerais savoir si les autres navigateurs ajoutent cette donnée, vous avez essayé ?
Paul Gaborit wrote:
[...]
Les autres en-têtes des deux requêtes sont similaires. Firefox a bien
respecté le codage demandé (utf8 dans un cas et iso-8859-1 dans
l'autre) par chacun des deux formulaires.
De plus, MIME permet de spécifier le codage de chacun des différents
éléments d'un message multipart/form-data. Pourquoi Firefox ne
l'indique pas dans sa requête ?
Je crois que manifestement c'est un oublie des développeurs de Firefox.
Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a
multipart/form-data is supposed to have a content-type. In the case
where a field element is text, the charset parameter for the text
indicates the character encoding used."
C'est agaçant. Par curiosité j'aimerais savoir si les autres navigateurs
ajoutent cette donnée, vous avez essayé ?
[...] Les autres en-têtes des deux requêtes sont similaires. Firefox a bien respecté le codage demandé (utf8 dans un cas et iso-8859-1 dans l'autre) par chacun des deux formulaires.
De plus, MIME permet de spécifier le codage de chacun des différents éléments d'un message multipart/form-data. Pourquoi Firefox ne l'indique pas dans sa requête ?
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est agaçant. Par curiosité j'aimerais savoir si les autres navigateurs ajoutent cette donnée, vous avez essayé ?
Paul Gaborit
À (at) Thu, 20 Dec 2007 16:27:23 +0100, Gerard Menvussa écrivait (wrote):
Paul Gaborit wrote:
De plus, MIME permet de spécifier le codage de chacun des différents éléments d'un message multipart/form-data. Pourquoi Firefox ne l'indique pas dans sa requête ?
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est du conditionnel (donc pas complètement obligatoire) mais je suis d'accord pour dire que c'est un oubli.
C'est agaçant. Par curiosité j'aimerais savoir si les autres navigateurs ajoutent cette donnée, vous avez essayé ?
Non, je n'ai pas encore essayé. Si j'ai le temps, je testerai IE (6 et 7 mais je n'ai pas beaucoup d'espoir pour aucun des deux) et peut-être konqueror et safari...
Mais d'autres l'ont fait en 2006 et, à l'époque, *aucun* n'envoyait cette information !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 20 Dec 2007 16:27:23 +0100,
Gerard Menvussa <gerard.menvussa@yargloo.con> écrivait (wrote):
Paul Gaborit wrote:
De plus, MIME permet de spécifier le codage de chacun des différents
éléments d'un message multipart/form-data. Pourquoi Firefox ne
l'indique pas dans sa requête ?
Je crois que manifestement c'est un oublie des développeurs de
Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of
a multipart/form-data is supposed to have a content-type. In the case
where a field element is text, the charset parameter for the text
indicates the character encoding used."
C'est du conditionnel (donc pas complètement obligatoire) mais je suis
d'accord pour dire que c'est un oubli.
C'est agaçant. Par curiosité j'aimerais savoir si les autres
navigateurs ajoutent cette donnée, vous avez essayé ?
Non, je n'ai pas encore essayé. Si j'ai le temps, je testerai IE (6 et
7 mais je n'ai pas beaucoup d'espoir pour aucun des deux) et peut-être
konqueror et safari...
Mais d'autres l'ont fait en 2006 et, à l'époque, *aucun* n'envoyait
cette information !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 20 Dec 2007 16:27:23 +0100, Gerard Menvussa écrivait (wrote):
Paul Gaborit wrote:
De plus, MIME permet de spécifier le codage de chacun des différents éléments d'un message multipart/form-data. Pourquoi Firefox ne l'indique pas dans sa requête ?
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est du conditionnel (donc pas complètement obligatoire) mais je suis d'accord pour dire que c'est un oubli.
C'est agaçant. Par curiosité j'aimerais savoir si les autres navigateurs ajoutent cette donnée, vous avez essayé ?
Non, je n'ai pas encore essayé. Si j'ai le temps, je testerai IE (6 et 7 mais je n'ai pas beaucoup d'espoir pour aucun des deux) et peut-être konqueror et safari...
Mais d'autres l'ont fait en 2006 et, à l'époque, *aucun* n'envoyait cette information !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Jean-Marc Desperrier
Gerard Menvussa wrote:
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est pris en compte dans le bug 116346. https://bugzilla.mozilla.org/show_bug.cgi?id6346
Mais voici ce qui arrive quand on l'active : "Cannot add attachment in yahoo mail" https://bugzilla.mozilla.org/show_bug.cgi?id92982
"it almost looks like the server code blindly assumes that the Content-Disposition header will always be the last (or only?) header and that after it there will be two bytes to skip (the blank line CRLF) and then you start reading data."
Pour l'instant, le correctif est désactivé en attendant de voir si le nombre de serveurs qui se mettent à déconner quand on l'ajoute est suffisament faible, et si il est possible de trouver un contournement pour les plus importants.
Gerard Menvussa wrote:
Je crois que manifestement c'est un oublie des développeurs de Firefox.
Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a
multipart/form-data is supposed to have a content-type. In the case
where a field element is text, the charset parameter for the text
indicates the character encoding used."
C'est pris en compte dans le bug 116346.
https://bugzilla.mozilla.org/show_bug.cgi?id6346
Mais voici ce qui arrive quand on l'active :
"Cannot add attachment in yahoo mail"
https://bugzilla.mozilla.org/show_bug.cgi?id92982
"it almost looks like the server code blindly assumes that the
Content-Disposition header will always be the last (or only?) header and
that after it there will be two bytes to skip (the blank line CRLF) and
then you start reading data."
Pour l'instant, le correctif est désactivé en attendant de voir si le
nombre de serveurs qui se mettent à déconner quand on l'ajoute est
suffisament faible, et si il est possible de trouver un contournement
pour les plus importants.
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est pris en compte dans le bug 116346. https://bugzilla.mozilla.org/show_bug.cgi?id6346
Mais voici ce qui arrive quand on l'active : "Cannot add attachment in yahoo mail" https://bugzilla.mozilla.org/show_bug.cgi?id92982
"it almost looks like the server code blindly assumes that the Content-Disposition header will always be the last (or only?) header and that after it there will be two bytes to skip (the blank line CRLF) and then you start reading data."
Pour l'instant, le correctif est désactivé en attendant de voir si le nombre de serveurs qui se mettent à déconner quand on l'ajoute est suffisament faible, et si il est possible de trouver un contournement pour les plus importants.
Paul Gaborit
À (at) Fri, 21 Dec 2007 19:17:30 +0100, Jean-Marc Desperrier écrivait (wrote):
Gerard Menvussa wrote:
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est pris en compte dans le bug 116346. https://bugzilla.mozilla.org/show_bug.cgi?id6346
Une discussion très intéressante... et longue ! 6 ans !
Je vais essayer de modifier ma config de Firefox (en utilisant 'false' pour browser.forms.submit.backwards_compatible)...
Mais voici ce qui arrive quand on l'active : "Cannot add attachment in yahoo mail" https://bugzilla.mozilla.org/show_bug.cgi?id92982
"it almost looks like the server code blindly assumes that the Content-Disposition header will always be the last (or only?) header and that after it there will be two bytes to skip (the blank line CRLF) and then you start reading data."
Pour l'instant, le correctif est désactivé en attendant de voir si le nombre de serveurs qui se mettent à déconner quand on l'ajoute est suffisament faible, et si il est possible de trouver un contournement pour les plus importants.
Parmi les commentaires, on trouve quelqu'un qui demande comment font les autres navigateurs et comment font les serveurs pour décoder le contenu des formulaires ? Mais il n'y a pas de réponse...
Je vais donc tester cela sur différents navigateurs et essayer d'écrire un petit résumé qui pourra peut-être servir.
Merci pour le pointeur sur le bug. Je ne l'avais pas trouvé.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 21 Dec 2007 19:17:30 +0100,
Jean-Marc Desperrier <jmdesp@alussinan.org> écrivait (wrote):
Gerard Menvussa wrote:
Je crois que manifestement c'est un oublie des développeurs de
Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part
of a multipart/form-data is supposed to have a content-type. In the
case where a field element is text, the charset parameter for the
text indicates the character encoding used."
C'est pris en compte dans le bug 116346.
https://bugzilla.mozilla.org/show_bug.cgi?id6346
Une discussion très intéressante... et longue ! 6 ans !
Je vais essayer de modifier ma config de Firefox (en utilisant 'false'
pour browser.forms.submit.backwards_compatible)...
Mais voici ce qui arrive quand on l'active :
"Cannot add attachment in yahoo mail"
https://bugzilla.mozilla.org/show_bug.cgi?id92982
"it almost looks like the server code blindly assumes that the
Content-Disposition header will always be the last (or only?) header
and that after it there will be two bytes to skip (the blank line
CRLF) and then you start reading data."
Pour l'instant, le correctif est désactivé en attendant de voir si le
nombre de serveurs qui se mettent à déconner quand on l'ajoute est
suffisament faible, et si il est possible de trouver un contournement
pour les plus importants.
Parmi les commentaires, on trouve quelqu'un qui demande comment font
les autres navigateurs et comment font les serveurs pour décoder le
contenu des formulaires ? Mais il n'y a pas de réponse...
Je vais donc tester cela sur différents navigateurs et essayer
d'écrire un petit résumé qui pourra peut-être servir.
Merci pour le pointeur sur le bug. Je ne l'avais pas trouvé.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 21 Dec 2007 19:17:30 +0100, Jean-Marc Desperrier écrivait (wrote):
Gerard Menvussa wrote:
Je crois que manifestement c'est un oublie des développeurs de Firefox. Normalement d'après de RFC 2388 chapitre 4.5 : "Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used."
C'est pris en compte dans le bug 116346. https://bugzilla.mozilla.org/show_bug.cgi?id6346
Une discussion très intéressante... et longue ! 6 ans !
Je vais essayer de modifier ma config de Firefox (en utilisant 'false' pour browser.forms.submit.backwards_compatible)...
Mais voici ce qui arrive quand on l'active : "Cannot add attachment in yahoo mail" https://bugzilla.mozilla.org/show_bug.cgi?id92982
"it almost looks like the server code blindly assumes that the Content-Disposition header will always be the last (or only?) header and that after it there will be two bytes to skip (the blank line CRLF) and then you start reading data."
Pour l'instant, le correctif est désactivé en attendant de voir si le nombre de serveurs qui se mettent à déconner quand on l'ajoute est suffisament faible, et si il est possible de trouver un contournement pour les plus importants.
Parmi les commentaires, on trouve quelqu'un qui demande comment font les autres navigateurs et comment font les serveurs pour décoder le contenu des formulaires ? Mais il n'y a pas de réponse...
Je vais donc tester cela sur différents navigateurs et essayer d'écrire un petit résumé qui pourra peut-être servir.
Merci pour le pointeur sur le bug. Je ne l'avais pas trouvé.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
