Le 11/06/2007 11:55, ASM a écrit :
>>>
>>> - dans la page html, partie php
>>> - dans le head de la page html
>>> - dans le mode d'encodage de l'objet XMLHttpRequest
>>> - dans le php.ini : default_charset = "iso-8859-1"
>>> - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
>>
>> Ben oui, mais XML est par défaut en UTF-8,
>
> il paraît.
>
>> et d'après ce que tu
>> décris il semble difficile d'aller contre.
>
> Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons
> en-têtes ?

La question est de savoir comment envoyer ces entêtes, non pas du
serveur vers le client, mais du client vers le serveur.

> Et là on a un très net commandement php de ces en-têtes me semble-ce.
> Pourquoi n'est-ce point suivi ?

Je suis d'accord pour les quatre qui concernent l'encodage de la page
envoyée par le serveur au navigateur, mais ce n'est pas ce qui pose
problème ici :

>>> - dans la page html, partie php
>>> - dans le head de la page html
>>> - dans le php.ini : default_charset = "iso-8859-1"
>>> - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1

Éventuellement, la solution pourrait être ici si ce « mode d'encodage »
concernait ce qu'envoie le navigateur au serveur, mais je ne connais pas
assez l'objet XMLHttpRequest pour savoir ce qu'il en est effectivement :

>>> - dans le mode d'encodage de l'objet XMLHttpRequest

> Serait-ce le XMLHttpRequest qui poste en utf-8 ?

Visiblement, oui.

> Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a
> indiqué autre chose ?

Peut-être, mais ownowl a essayé plusieurs versions d'IE et une de
Firefox qui font toutes la même chose.

> (par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été
> envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de
> charset utf-8 et ce même si la page hôte est en utf-8)

C'est drôle, parce que là c'est l'inverse : le navigateur renvoie de
l'UTF-8 alors qu'il a reçu du Latin1.