Bonjour,
un
tout petit soucis qui n'est pas très agréable m'embête sensiblement.
Sur le serveur apache coté dev - local, aucun soucis d'encodage. Mais
sur le prod - serveur -, certaines pages sont touchés aux problèmes
d'encodage. Il y a quasiment la même chose des deux côtés niveau
configuration apache, et exactement la même chose niveau fichiers (page
web, …).
Je lu que l'on peut ajouter 'AddDefaultCharset UTF-8' sur les fichiers
de config. Mais c'est amusant, ça ne me retire pas le problème, et ça le
crée pour certaines pages (sous-domaine).
Que dois-je faire du côté serveur avec apache?
Merci d'avance.
# t'assurer que les fichiers que tu veux envoyer sont bien UTF8
Posté par NeoX . Évalué à 2.
de ce que tu sembles dire,
ton serveur de dev n'a aucun soucis,
le serveur de prod genere un soucis quand tu forces l'encodage en UTF8
j'aurais tendance à croire que tes fichiers ne sont pas enregistrés/codés en UTF8, ni en ISO
du coup forcer UTF ne regle pas le soucis sur la prod et genere le probleme sur les sous domaines qui fonctionnaient precedemment avec l'encodage par defaut.
il faut donc que tu regardes ton environnement de dev pour savoir quel encodage tu as utilisé à l'interieur des fichiers.
ensuite
iconvdoit pouvoir t'aider à basculer les fichiers d'un encodage (dev) à un autre (prod)[^] # Re: t'assurer que les fichiers que tu veux envoyer sont bien UTF8
Posté par dafp . Évalué à 0. Dernière modification le 22 octobre 2013 à 14:09.
Non
même sans forcer sur la prod il y a des problèmes. Et comment ça se
fait qu'il pourrait avoir des problèmes d'encodage de fichiers? Tout ce
qui en prod provient de dev (synchronisation entre les deux avec rsync).
Même -Index des fichiers d'un dossier ne m'affiche pas correctement les caractères.
[^] # Re: t'assurer que les fichiers que tu veux envoyer sont bien UTF8
Posté par NeoX . Évalué à 2.
un editeur de texte mal configuré, qui va ouvrir/creer le fichier en ISO
alors que le serveur est en UTF8 par exemple.
sur certains editeurs il faut forcer l'encodage pour qu'il travaille et enregistre dans l'encodage qui t'interesse.
[^] # Re: t'assurer que les fichiers que tu veux envoyer sont bien UTF8
Posté par dafp . Évalué à 0. Dernière modification le 22 octobre 2013 à 19:21.
Et
alors pour les noms de fichiers, comment ça se fait? Les noms de
fichiers avec caractères spéciaux ne passent pas.
Se pourrait-il que cela soit lors de la copie entre la machine dev et
prod (donc la faute d'une non prise en compte d'option de rsync)?
Non ça doit venir que du côté web, car quand je suis sur la machine en
ssh, je fais ls sur le même dossier et pas de problème de
caractères, pareil si j'affiche un fichier avec cat.
Sans 'AddDefaultCharset utf-8' sur httpd.conf, il n'y a qu'un
sous-domaine qui a le problème d'encodage.
Avec, il y a un problème avec les pages qui imposé un encodage différent
que utf-8, et aussi toujours le même sous-domaine que précédemment.
J'ai les mêmes fichiers de configurations pour le sous-domaine du côté
dev et prod (aux path près).
Mais bizarrement, le navigateur ne me donne pas la même chose :)
Le navigateur rajoute une ligne du côté dev :
html
<meta http-equiv="content-type" content="text/html;
charset=utf-8">'
Et je ne l'ai pas du côté prod.
Que ça soit une simple page web, ou apache qui liste les fichiers sur le dossier.
[^] # Re: t'assurer que les fichiers que tu veux envoyer sont bien UTF8
Posté par dafp . Évalué à 0. Dernière modification le 22 octobre 2013 à 19:33.
Bon ça devait venir de mon navigateur, ou une manip' que je me souviens pas, mais enfin ça affiche correctement.
MERCI!
# Commentaire supprimé
Posté par Gabriella95 . Évalué à -4. Dernière modification le 22 octobre 2013 à 14:58.
Ce commentaire a été supprimé par l’équipe de modération.
# Root cause
Posté par paulez (site web personnel) . Évalué à 2.
La différence au niveau navigateur se situe-t-elle :
- au niveau de l'encodage annoncé dans l'en-tête http;
- de l'encodage annoncé dans le xml ou html ;
- de l'encodage du code xml lui-même ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.