Commence donc par configurer ton serveur pour qu'il annonce le jeu de caractères utilisé dans l'entête HTTP Content-Type. Si ça ne marche pas tu peux essayer de rajouter un attribut charset à la balise <script>, mais je ne sais pas si ça fonctionne pour les scripts internes comme pour les scripts externes.
J'ai une page ouèbe qui s'affiche très bien en direct, avec des
accents, sous Firefox:
Commence donc par configurer ton serveur pour qu'il annonce le jeu de
caractères utilisé dans l'entête HTTP Content-Type. Si ça ne marche pas
tu peux essayer de rajouter un attribut charset à la balise <script>,
mais je ne sais pas si ça fonctionne pour les scripts internes comme
pour les scripts externes.
Commence donc par configurer ton serveur pour qu'il annonce le jeu de caractères utilisé dans l'entête HTTP Content-Type. Si ça ne marche pas tu peux essayer de rajouter un attribut charset à la balise <script>, mais je ne sais pas si ça fonctionne pour les scripts internes comme pour les scripts externes.
vicnet
On 16 avr, 17:12, Olivier Miakinen <om+ wrote:
J'ai une page ouèbe qui s'affiche très bien en direct, avec des accents, sous Firefox: http://osele.free.fr/prg/accent.html Content-Type: text/html
Commence donc par configurer ton serveur pour qu'il annonce le jeu de caractères utilisé dans l'entête HTTP Content-Type.
En effet, il n'y rien, mais ca je ne peux le changer vu que le serveur, c'est free ! Je n'ai pas accès à la conf appache.
Si ça ne marche pas tu peux essayer de rajouter un attribut charset à la balise <script>, mais je ne sais pas si ça fonctionne pour les scripts internes comme pour les scripts externes.
Je viens de faire le test, ca ne fonctionne pas (j'ai changé le fichier accent.html).
Ce que je ne comprends pas, c'est pourquoi Firefox voit le même fichier comme de l'utf-8 alors qu'en accès direct ca marche. J'ai la même réponse du serveur sous firebug en direct et en ajax....
Que faut-il faire sous js de firefox pour forcer l'iso ?
Néanmoins, merci pour ta réponse.
a+ Vincent
On 16 avr, 17:12, Olivier Miakinen <om+n...@miakinen.net> wrote:
J'ai une page ouèbe qui s'affiche très bien en direct, avec des
accents, sous Firefox:
http://osele.free.fr/prg/accent.html
Content-Type: text/html
Commence donc par configurer ton serveur pour qu'il annonce le jeu de
caractères utilisé dans l'entête HTTP Content-Type.
En effet, il n'y rien, mais ca je ne peux le changer vu que le
serveur, c'est free !
Je n'ai pas accès à la conf appache.
Si ça ne marche pas
tu peux essayer de rajouter un attribut charset à la balise <script>,
mais je ne sais pas si ça fonctionne pour les scripts internes comme
pour les scripts externes.
Je viens de faire le test, ca ne fonctionne pas (j'ai changé le
fichier accent.html).
Ce que je ne comprends pas, c'est pourquoi Firefox voit le même
fichier comme de l'utf-8 alors qu'en accès direct ca marche.
J'ai la même réponse du serveur sous firebug en direct et en ajax....
Que faut-il faire sous js de firefox pour forcer l'iso ?
J'ai une page ouèbe qui s'affiche très bien en direct, avec des accents, sous Firefox: http://osele.free.fr/prg/accent.html Content-Type: text/html
Commence donc par configurer ton serveur pour qu'il annonce le jeu de caractères utilisé dans l'entête HTTP Content-Type.
En effet, il n'y rien, mais ca je ne peux le changer vu que le serveur, c'est free ! Je n'ai pas accès à la conf appache.
Si ça ne marche pas tu peux essayer de rajouter un attribut charset à la balise <script>, mais je ne sais pas si ça fonctionne pour les scripts internes comme pour les scripts externes.
Je viens de faire le test, ca ne fonctionne pas (j'ai changé le fichier accent.html).
Ce que je ne comprends pas, c'est pourquoi Firefox voit le même fichier comme de l'utf-8 alors qu'en accès direct ca marche. J'ai la même réponse du serveur sous firebug en direct et en ajax....
Que faut-il faire sous js de firefox pour forcer l'iso ?
Néanmoins, merci pour ta réponse.
a+ Vincent
Mihamina (R12y) Rakotomandimby
vicnet - :
En effet, il n'y rien, mais ca je ne peux le changer vu que le serveur, c'est free ! Je n'ai pas accès à la conf appache.
htacces, tout ça... genre: http://www.w3.org/International/questions/qa-htaccess-charset
En effet, il n'y rien, mais ca je ne peux le changer vu que le serveur, c'est free ! Je n'ai pas accès à la conf appache.
htacces, tout ça... genre: http://www.w3.org/International/questions/qa-htaccess-charset
ASM
vicnet - :
En effet, il n'y rien, mais ca je ne peux le changer vu que le serveur, c'est free ! Je n'ai pas accès à la conf appache.
htacces, tout ça... genre: http://www.w3.org/International/questions/qa-htaccess-charset
Perso, je ne suis jamais arrivé à esspliquer à FF que responseText n'était pas en utf-8 de même, avec Safari, je ne suis pas arrivé à lui faire comprendre que respnseText pouvait être en utf-8.
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
Le code suivant fonctionne bien chez moi : (FF et Safari)
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>test ajax et charset</title> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" /> <meta http-equiv="Content-Style-Type" content="text/css"> <title>pas de titre</title> <script language="Javascript" type="text/javascript"> function ajax(url) { var httpRequest = false; if (window.XMLHttpRequest) { // Mozilla, Safari,... httpRequest = new XMLHttpRequest(); if(httpRequest.overrideMimeType) { httpRequest.overrideMimeType('text/xml'); } } else if(window.ActiveXObject) { // IE try { httpRequest = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { httpRequest = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {} } } if (!httpRequest) { alert('Abandon :( Impossible de créer une instance XMLHTTP'); return false; } httpRequest.onreadystatechange = function() { alertContents(httpRequest); }; httpRequest.open('GET', url, true); httpRequest.send(null); }
function alertContents(httpRequest) { if httpRequest.readyState == 4) { if (httpRequest.status == 200) { var tmpdiv = document.createElement('div'); tmpdiv.innerHTML = httpRequest.responseText; document.body.appendChild(tmpdiv); } else { alert('Un problème est survenu avec la requête.'); } }
En effet, il n'y rien, mais ca je ne peux le changer vu que le
serveur, c'est free !
Je n'ai pas accès à la conf appache.
htacces, tout ça...
genre: http://www.w3.org/International/questions/qa-htaccess-charset
Perso, je ne suis jamais arrivé à esspliquer à FF que responseText
n'était pas en utf-8
de même, avec Safari, je ne suis pas arrivé à lui faire comprendre que
respnseText pouvait être en utf-8.
La seule parade que j'ai trouvée est d'insérer le code de charset à la
mode XML dans les fichiers appelés via XMLHttpRequest
Le code suivant fonctionne bien chez moi :
(FF et Safari)
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>test ajax et charset</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1" />
<meta http-equiv="Content-Style-Type" content="text/css">
<title>pas de titre</title>
<script language="Javascript" type="text/javascript">
function ajax(url) {
var httpRequest = false;
if (window.XMLHttpRequest)
{ // Mozilla, Safari,...
httpRequest = new XMLHttpRequest();
if(httpRequest.overrideMimeType) {
httpRequest.overrideMimeType('text/xml');
}
}
else if(window.ActiveXObject)
{ // IE
try {
httpRequest = new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e) {
try {
httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}
catch (e) {}
}
}
if (!httpRequest) {
alert('Abandon :( Impossible de créer une instance XMLHTTP');
return false;
}
httpRequest.onreadystatechange = function() {
alertContents(httpRequest);
};
httpRequest.open('GET', url, true);
httpRequest.send(null);
}
function alertContents(httpRequest) {
if httpRequest.readyState == 4) {
if (httpRequest.status == 200) {
var tmpdiv = document.createElement('div');
tmpdiv.innerHTML = httpRequest.responseText;
document.body.appendChild(tmpdiv);
}
else {
alert('Un problème est survenu avec la requête.');
}
}
En effet, il n'y rien, mais ca je ne peux le changer vu que le serveur, c'est free ! Je n'ai pas accès à la conf appache.
htacces, tout ça... genre: http://www.w3.org/International/questions/qa-htaccess-charset
Perso, je ne suis jamais arrivé à esspliquer à FF que responseText n'était pas en utf-8 de même, avec Safari, je ne suis pas arrivé à lui faire comprendre que respnseText pouvait être en utf-8.
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
Le code suivant fonctionne bien chez moi : (FF et Safari)
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>test ajax et charset</title> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" /> <meta http-equiv="Content-Style-Type" content="text/css"> <title>pas de titre</title> <script language="Javascript" type="text/javascript"> function ajax(url) { var httpRequest = false; if (window.XMLHttpRequest) { // Mozilla, Safari,... httpRequest = new XMLHttpRequest(); if(httpRequest.overrideMimeType) { httpRequest.overrideMimeType('text/xml'); } } else if(window.ActiveXObject) { // IE try { httpRequest = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { httpRequest = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {} } } if (!httpRequest) { alert('Abandon :( Impossible de créer une instance XMLHTTP'); return false; } httpRequest.onreadystatechange = function() { alertContents(httpRequest); }; httpRequest.open('GET', url, true); httpRequest.send(null); }
function alertContents(httpRequest) { if httpRequest.readyState == 4) { if (httpRequest.status == 200) { var tmpdiv = document.createElement('div'); tmpdiv.innerHTML = httpRequest.responseText; document.body.appendChild(tmpdiv); } else { alert('Un problème est survenu avec la requête.'); } }
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
vicnet
On 17 avr, 01:43, ASM wrote:
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Le seul hic, c'est que je ne maitrise pas les pages html que je charge. Mon prog est en fait une extension firefox ajoutant des fonctions à phpbb, fonctions utilisant ajax. Or phpbb (plus précisement le template du phpbb sur lequel je fait mes tests) n'insère pas cette balise xml.
Peut être que je peux forcer ceci dans l'extension elle même...
En tout cas, merci pour l'info et une partie de la solution !
a+ Vicnet
On 17 avr, 01:43, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
wrote:
La seule parade que j'ai trouvée est d'insérer le code de charset à la
mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Le seul hic, c'est que je ne maitrise pas les pages html que je
charge.
Mon prog est en fait une extension firefox ajoutant des fonctions à
phpbb, fonctions utilisant ajax.
Or phpbb (plus précisement le template du phpbb sur lequel je fait mes
tests) n'insère pas cette balise xml.
Peut être que je peux forcer ceci dans l'extension elle même...
En tout cas, merci pour l'info et une partie de la solution !
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Le seul hic, c'est que je ne maitrise pas les pages html que je charge. Mon prog est en fait une extension firefox ajoutant des fonctions à phpbb, fonctions utilisant ajax. Or phpbb (plus précisement le template du phpbb sur lequel je fait mes tests) n'insère pas cette balise xml.
Peut être que je peux forcer ceci dans l'extension elle même...
En tout cas, merci pour l'info et une partie de la solution !
a+ Vicnet
ASM
On 17 avr, 01:43, ASM wrote:
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Le seul hic, c'est que je ne maitrise pas les pages html que je charge.
Et en passant par un fichier php ? (qui aura le bon header de charset)
Mon prog est en fait une extension firefox ajoutant des fonctions à phpbb, fonctions utilisant ajax.
Oui ... bon ... j'y connais rien en extensions. Le coup du php de chargement ne va sans doute pas être le top comme soluce. D'autant que je ne suis pas fortich en php et ne sais si ce code pourrait faire ...
Or phpbb (plus précisement le template du phpbb sur lequel je fait mes tests) n'insère pas cette balise xml.
y a plus qu'à :-)
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
On 17 avr, 01:43, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
wrote:
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Le seul hic, c'est que je ne maitrise pas les pages html que je
charge.
Et en passant par un fichier php ?
(qui aura le bon header de charset)
Mon prog est en fait une extension firefox ajoutant des fonctions à
phpbb, fonctions utilisant ajax.
Oui ... bon ... j'y connais rien en extensions.
Le coup du php de chargement ne va sans doute pas être le top comme
soluce. D'autant que je ne suis pas fortich en php et ne sais si ce code
pourrait faire ...
Or phpbb (plus précisement le template du phpbb sur lequel je fait mes
tests) n'insère pas cette balise xml.
y a plus qu'à :-)
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Mon prog est en fait une extension firefox ajoutant des fonctions à phpbb, fonctions utilisant ajax.
Oui ... bon ... j'y connais rien en extensions. Le coup du php de chargement ne va sans doute pas être le top comme soluce. D'autant que je ne suis pas fortich en php et ne sais si ce code pourrait faire ...
Or phpbb (plus précisement le template du phpbb sur lequel je fait mes tests) n'insère pas cette balise xml.
y a plus qu'à :-)
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Pierre Goiffon
vicnet wrote:
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
vicnet wrote:
La seule parade que j'ai trouvée est d'insérer le code de charset à la
mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé
qu'entre la déclaration charset dans le prologue XML et la déclaration
dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
ASM
vicnet wrote:
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
L'entête HTTP de quoi ?
Si j'ai bien compris, on tente de récupérer via XMLHttpRequest, un fichier de provenance (serveur) inconnue ou sans entête 'serveur' de charset
Est-ce que le serveur "headerise" systématiquement le charset par défaut sur une requête asynchrone ?
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
vicnet wrote:
La seule parade que j'ai trouvée est d'insérer le code de charset à la
mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé
qu'entre la déclaration charset dans le prologue XML et la déclaration
dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
L'entête HTTP de quoi ?
Si j'ai bien compris, on tente de récupérer via XMLHttpRequest, un
fichier de provenance (serveur) inconnue ou sans entête 'serveur' de charset
Est-ce que le serveur "headerise" systématiquement le charset par défaut
sur une requête asynchrone ?
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
La seule parade que j'ai trouvée est d'insérer le code de charset à la mode XML dans les fichiers appelés via XMLHttpRequest
<?xml version="1.0" encoding="ISO-8859-1"?>
En effet, avec cette ligne tout fonctionne.
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
L'entête HTTP de quoi ?
Si j'ai bien compris, on tente de récupérer via XMLHttpRequest, un fichier de provenance (serveur) inconnue ou sans entête 'serveur' de charset
Est-ce que le serveur "headerise" systématiquement le charset par défaut sur une requête asynchrone ?
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Patrick Mevzek
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Sur http://www.w3.org/International/O-charset il est dit : Ensure that there is no conflict between what you declare in the document and what the server automatically applies, since server settings override in-document declarations.
L'entête HTTP de quoi ?
De la réponse. Tout message HTTP a des en-têtes, et une réponse d'un serveur doit avoir l'en-tête Content-Type.
Si j'ai bien compris, on tente de récupérer via XMLHttpRequest, un fichier de provenance (serveur) inconnue ou sans entête 'serveur' de charset
L'application qui génère la réponse sur le serveur est donc fautive : c'est son travail que de préciser le charset dans l'en-tête HTTP adéquat.
Est-ce que le serveur "headerise" systématiquement le charset par défaut sur une requête asynchrone ?
Un serveur bien configuré met systématiquement un charset (s'il n'est pas déjà présent), à toutes les réponses (asynchrones ou non), pour éviter un certain nombre d'attaques.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé
qu'entre la déclaration charset dans le prologue XML et la déclaration
dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Sur http://www.w3.org/International/O-charset il est dit :
Ensure that there is no conflict between what you declare in the document
and what the server automatically applies, since server settings override
in-document declarations.
L'entête HTTP de quoi ?
De la réponse. Tout message HTTP a des en-têtes, et une réponse d'un
serveur doit avoir l'en-tête Content-Type.
Si j'ai bien compris, on tente de récupérer via XMLHttpRequest, un
fichier de provenance (serveur) inconnue ou sans entête 'serveur' de
charset
L'application qui génère la réponse sur le serveur est donc fautive :
c'est son travail que de préciser le charset dans l'en-tête HTTP
adéquat.
Est-ce que le serveur "headerise" systématiquement le charset par
défaut sur une requête asynchrone ?
Un serveur bien configuré met systématiquement un charset (s'il n'est
pas déjà présent), à toutes les réponses (asynchrones ou non), pour
éviter un certain nombre d'attaques.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Sur http://www.w3.org/International/O-charset il est dit : Ensure that there is no conflict between what you declare in the document and what the server automatically applies, since server settings override in-document declarations.
L'entête HTTP de quoi ?
De la réponse. Tout message HTTP a des en-têtes, et une réponse d'un serveur doit avoir l'en-tête Content-Type.
Si j'ai bien compris, on tente de récupérer via XMLHttpRequest, un fichier de provenance (serveur) inconnue ou sans entête 'serveur' de charset
L'application qui génère la réponse sur le serveur est donc fautive : c'est son travail que de préciser le charset dans l'en-tête HTTP adéquat.
Est-ce que le serveur "headerise" systématiquement le charset par défaut sur une requête asynchrone ?
Un serveur bien configuré met systématiquement un charset (s'il n'est pas déjà présent), à toutes les réponses (asynchrones ou non), pour éviter un certain nombre d'attaques.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
En résumé (du plus prioritaire au moins prioritaire) : 1. HTTP Content-Type 2. XML declaration 3. meta charset declaration 4. link charset attribute
Content-Type rulez !
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé
qu'entre la déclaration charset dans le prologue XML et la déclaration
dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
