Discussion :

[troumad]

Bonjour

La discussion a été commencée ici : http://www.developpez.net/forums/d12...x/header-ajax/ , mais on m'a dit que c'est un problème php. Donc, je continue là !

Dans des include et appel ajax, j'avais mis ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 if (!headers_sent())
 { 
  header('Content-Type: text/xml; charset=ISO-8859-15');
 }

Ceci me permettait de ne pas envoyer de header quand le fichier étaéit utilisé en include et de l'envoyer quand il était envoyé en appel ajax.

Ce header est indispensable pour que les caractères passent correctement lors des appel ajax.

Maintenant, la présence de ces lignes font planter les fichiers php quand ils sont utilisés en include ! Si j'ai bien compris, headers_sent() ne marche plus ! Pourquoi ?

[rawsrc]

Salut,

Est ce que tu utilises le buffer de sortie avant d'émettre une réponse ?
Si oui est ce que tu peux essayer en le désactivant.

[troumad]

Je ne pense pas : je ne sais pas ce que c'est !

[rawsrc]

Ok, tu as à ta disposition headers_list() pour récupérer la liste des headers qui seront envoyés au navigateur.
Vérifie avec un var_dump(headers_list()); ce qui est transmis dans les 2 cas d'utilisation.
Si tu as un envoi intempestif ou qui ne colle pas c'est que je te souhaite la bienvenue dans le merveilleux monde de la migration de Linux vers Windows et je ne te cache pas que les joyeusetés du genre les caractères de fin de ligne, les BOM des fichiers, les encodages... vont causer des soucis. Tu aurais dû rester sur Linux

[troumad]

Tu aurais dû rester sur Linux

Si tout ne dépendrait que de moi, il n'y aurait pas de Windows au boulot...

Le var_dump(headers_list());, tu le conseilles uniquement pour test ! C'est ça ?
http://php.net/manual/fr/function.var-dump.php

[rawsrc]

Le var_dump(headers_list());, tu le conseilles uniquement pour test ! C'est ça ?
http://php.net/manual/fr/function.var-dump.php

Oui pour voir si dans tes scripts migrés il n'y aurait pas des éléments perturbant qui les forceraient à émettre des headers de manière intempestive.

[troumad]

Voici le code que je mets :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 var_dump(headers_list());
 if (!headers_sent())
 { 
  echo "<p>pourquoi je passe là ?</p>"; 
  //header('Content-Type: text/xml; charset=ISO-8859-15');
 }

Voici le retour que j'ai dans toutes les configurations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
array (size=4)
  0 => string 'X-Powered-By: PHP/5.3.13' (length=24)
  1 => string 'Expires: Thu, 19 Nov 1981 08:52:00 GMT' (length=38)
  2 => string 'Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0' (length=77)
  3 => string 'Pragma: no-cache' (length=16)
 
pourquoi je passe là ?

Il va falloir que je regarde pourquoi le retour de l'ajax met ce retour dans le header... Je ne me souviens plus de ce que j'avais fait !

[rawsrc]

Maintenant il ne te reste plus qu'à tracer pas à pas ton code pour retrouver tes petits

Je ne me souviens plus de ce que j'avais fait !

C'est dans ces moments là que l'on sait si on a codé proprement ou pas

Voilà voilà, bon dépieutage

[troumad]

=> Compris....
C'est normal, le début du retour généré par le fichier php est traité par le sript javascript pour être inséré comme un script dans le header et le reste est traité pour être affiché dans l'élément qui a le nom passé en paramètre...

[rawsrc]

Dans ce cas de figure, j'utilise XML comme format d'échange.
A la récupération j'ai une fonction js qui sépare et range le contenu de la réponse. Pas de problème d'en-tête du coup : toujours du XML.

[troumad]

Ma fonction js fait le même travail, mais mon problème, c'est que je ne récupère pas le bon codage. Mon entête permet juste d'avoir le code considéré en iso-8859-15 . Si je ne passe pas cet entête, mon texte s'affiche avec des � dans le texte.

Avec ff si je demande de passer en utf8 => je n'ai rien de mieux, même pire, les accents (ou autres lettres à la française) du texte deviennent n'importe quoi. Si je demande ensuite de revenir en iso, l'affichage devient correct pour tout le texte (aussi bien celui écrit avant l'appel ajax que celui écrit par l'appel ajax). Donc, c'est ff qui n'a pas compris que le nouveau code est en iso et qu'il l'affiche en utf au milieu d'une page en iso. Pour info, affichage => encodage des caractères signale bien iso pourtant.

[rawsrc]

quel est l'encodage de tes fichiers .php ?

[troumad]

Je crois qu'elle est en iso... Enfin, que le code qui arrive des requettes MySQL est en iso !

J'ai transformé les accents du source php en chose du genre ´ lors des premiers tests de migration sous windows...

[rawsrc]

Pour éviter ces tracasseries, il faut être super cohérent sur toute la ligne avec les encodages :
Si par exemple tu utilises UTF-8 :
fichiers .php .css .js : en UTF-8 sans BOM
rendu web : charset=utf-8
base de données : utf-8

Dès qu'il y a un écart quelque part, tu auras à un moment ou à un autre des problèmes qui vont faire que tu vas voir des caractères ésotériques.

Tu peux savoir l'encodage utilisé par la base avec mysql_client_encoding()

[troumad]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Le jeu de caractères actuel est : latin1.

C'est peut-être de là que viennent plein de mes problèmes
latin1 ! Qui utilise ça ? Qui a osé mettre une base en latin1 !!!! C'est du windows ça ?

[rawsrc]

Oui voilà la cause de tous tes malheurs :
latin1 = ISO 8859-1 <> ISO-8859-15

Qui a osé mettre une base en latin1 !!!! C'est du windows ça ?

Bah si j'étais toi je m'en prendrais au type qui a fait la migration

[troumad]

Oui voilà la cause de tous tes malheurs :
latin1 = ISO 8859-1 <> ISO-8859-15

Je croyais que la différence entre ISO 8859-1 et ISO-8859-15 était minime ! À peine visible !

[rawsrc]

Je croyais que la différence entre ISO 8859-1 et ISO-8859-15 était minime ! À peine visible !

Oui c'est minime mais la différence peut être visible...

Ensuite, je ne sais pas quel est l'encodage de tes fichiers source. Le problème peut aussi venir de là et se cumuler avec le précédent.

Liste des caractères supplémentaires gérés par ISO-8859-15 = latin9 :
€ Š š Ž ž Œ œ Ÿ

[troumad]

Liste des caractères supplémentaires gérés par ISO-8859-15 = latin9 :
€ Š š Ž ž Œ œ Ÿ

Des caractères que je n'utilise pas ici.


Voici le début de mon fichier php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php 
echo ('<?xml version="1.0" encoding="iso-8859-15"?>'); ?>
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
 <head>
  <link rel="shortcut icon" href="/pt/favicon.ico" />
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />
  <meta name="Author" content="Troumad" />

C'est bien du iso-8859-15 !

Après, la BOM : et bien je ne pense pas qu'il y en ait de BOM dans mes fichiers. Ils ont été générés par kwrite ou vi. Je ne pense pas avoir utilisé d'autres éditeurs de texte. Un éditeur hexadécimal de mon texte indique bien le code ascii de mon texte au début : 3C 3F 70 68.

Il me reste peut-être à vérifier comment marche le php !

[rawsrc]

Avant de t'attaquer au PHP et maintenant que tu es devenu un aficionado de Windows tu peux toujours vérifier l'encodage de tous tes fichiers avec ceci.