On Wed, Mar 10, 2004 at 04:57:47PM +0900, Mike Hommey wrote:
[...]
> >Quand bien m�me c'est possible d'avoir l'information sur l'encodage, �a
> >ne suffit pas toujours. Je suis encore tomb� sur un exemple � la con :
> >les signets � param�tres de galeon (ou autre). Quand tu vas sur
> >google.fr et que tu cherches un mot avec des accents, il se d�merde avec
> >l'encodage en envoyant le formulaire, car la page de d�part contient un
> >encodage (iso8859-1 ici). Mais quand tu veux faire une recherche en
> >utilisant directement un signet, tu n'as pas l'information sur
> >l'encodage dans lequel le site � l'autre bout veut ses informations. Et,
> >corrigez-moi si je me trompe, autant HTTP pr�cise un encodage pour ce
> >que le serveur envoie, autant le client ne peut pas pr�ciser en quoi son
> >URL est encod�e, et doit donc pr�supposer qu'elle est en utf-8. Et ma
> >recherche sur R�mi se transforme en Rémi.
>
> Oui, c'est le truc le plus con � propos d'HTTP : la plupart des �changes
> entre serveur et client n'ont aucune indication de codage. Autrement
> dit, c'est le foutoir. On ne peut pas savoir si les champs d'un
> formulaire ont �t� remplis en UTF-8, en ISO-bidule ou en ISO-machin...
Dans le cas des formulaires, �a d�pend de la m�thode (GET vs. POST) et
est expliqu� dans les specs de l'HTML, par exemple
http://www.w3.org/TR/html401/interact/forms.html#h-17.13
Note. The "get" method restricts form data set values to ASCII
characters. Only the "post" method (with enctype="multipart/form-data")
is specified to cover the entire [ISO10646] character set.
C'est pourquoi sur Google le codage est pass� en argument des requ�tes.
Bien s�r, � on � va r�torquer qu'il suffit d'utiliser XForms � la place,
qui r�pond au probl�me en imposant un codage en UTF-8 ;)
http://www.w3.org/TR/2003/REC-xforms-20031014/slice11.html#serialize-urlencode
Denis
