1633 sujets

Formats, encodage, internationalisation, XML

Jeux de caractères utf-8

Bonjour,

développant un site web personnel, j'ai brutalement perdu l'affichage de mes caractères spéciaux (accents etc...). Je ne sais pas comment cela c'est produit et malgré le temps passé à rechercher l'origine du problème, je ne trouve pas de solution. J'ai bien lu et re-lu les détails et notions de base (http://forum.alsacreations.com/topic-17-29978-1-Pre-requis-Notions-de-base-sur-lencodage-des-caracteres.html), mais tout me semble bon.

Lors de mon debogage, j'en suis arrivé à minimiser le code pour cerner le problème sur uniquement deux fichiers : a.php et b.php.
Ils possèdent tous deux le même code et s'appellent mutuellement par un lien interne :
(liens a.php pour b et a.php pour b)
le voici :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="description" content="randonnees et ballades." />
<meta name="keywords" content="randonnees montagne" />

<link rel="shortcut icon" href="img/sc_icon.ico" type="img/x-icon" />
<link rel="stylesheet" href="css/styles.css" type="text/css" title="styles" />
<link rel="stylesheet" href="gr20/css/scroll.css" type="text/css" media="all" />
</head>


<body>

<?php include ('Pages/header.inc.php'); ?>

<div id="global">
<h1><a href="b.php">ééé</a></h1>
</div> <!-- End of global -->

<?php include("gr20/pied.inc.php"); ?>

</body>
</html>

a et b ne décodent pas les caractères spéciaux du header.
a et b décodent correctement les caractères spéciaux du pied.
a ne décode pas ééé correctement
b décode ééé correctement.

J'utilise textpad, firefox 3.6.13 et wampserver.
Ils sont tous trois configurés pour décoder en utf-8.

Quelqu'un peux m'aiguiller ?
MERCI beaucoup Smiley cligne
Bonjour,

En supposant que le serveur web:
- soit ne déclare aucun codage dans l'en-tête HTTP Content-Type;
- soit déclare de l'UTF-8 (comme ta balise META)...

il me semble alors que:
1. header.inc.php n'est pas encodé en UTF-8.
2. pied.inc.php est bien encodé en UTF-8.
3. a.php n'est pas encodé en UTF-8.
4. b.php est bien encodé en UTF-8.

Si tu n'es pas sûr des réglages de ton éditeur de code et du codage réel de tes fichiers, tu peux ouvrir ces fichiers un par un dans Firefox (y compris en mode texte brut, en les glissant par glisser-déposer dans un onglet vide par exemple). On utilisera alors le menu «Affichage > Encodage des caractères» pour chercher quel codage permet de bien afficher le contenu. Par exemple, pour un fichier donné, si c'est ISO-8859-1 qui permet d'avoir un bon affichage des caractères alors le fichier a été enregistré en ISO-8859-1.

Je ne connais pas l'éditeur utilisé donc je ne saurais dire quelle manipulation est nécessaire pour réenregistrer un fichier avec un codage différent.
Merci pour ta réponse Florent.

En utilisant Notepad++ comme éditeur, je peux directement voir l'encodage actuel du fichier (généralement ANSI quand cela ne fonctionnait pas...) et sauvegarder le fichier dans l'encodage désiré (utf-8).

Have a nice day ! Smiley biggrin
Je n'ai qu'une confiance partielle en la gestion des codages de caractères par Notepad++ (rien que le nom «ANSI» est une connerie monumentale...), et certains autres éditeurs (TextMate par exemple).
Gestion idéale des codages de caractères dans un éditeur:

- Utiliser des noms techniquement justes pour les codages (pas le cas de Notepad++ qui parle d'«ANSI», par exemple).
- Gérer un nombre conséquent de codages. UTF-8, ISO-8859-1, Windows-1252 et MacRoman au minimum (pour un public occidental), mais il y en a bien d'autres qui peuvent s'avérer utile ponctuellement.
- Gérer le UTF-8 avec ou sans BOM. S'il ne propose pas de réglage, le codage "UTF-8" proposé sera du UTF-8 sans BOM (surtout si l'éditeur est orienté Web).
- Permettre, dans les préférences du logiciel, de choisir le codage par défaut pour les nouveaux documents.
- Lorsqu'un document est ouvert, détecter le codage du document. La détection peut reposer sur des informations données dans le document (balise META, prologue XML, commentaire «coding:» en Python, présence d'un BOM) et basculer ensuite sur un réglage par défaut, ou, plus intelligemment, tenter de détecter le codage du document à partir du contenu (il y a des libs qui font ça).
- Afficher en permanence (dans la barre d'état par exemple) ou sur demande le codage du document. C'est à dire le codage qui a été détecté, et par conséquent utilisé pour analyser et restituer le fichier. Par ailleurs, ce sera aussi le codage utilisé pour enregistrer le fichier s'il est modifié.
- Permettre de changer de codage en réinterprétant le document. Indispensable si le codage a été mal détecté.
- Permettre de changer de codage sans réinterpréter le document. Utile par exemple lorsqu'on ouvre en fichier en ISO-8859-1 et qu'on veut l'enregistrer en UTF-8.

- Bonus: lors du changement de codage, si le fichier contient des indications de codage (balise META par exemple), proposer à l'utilisateur de modifier ces marqueurs.

Je ne connais aucun éditeur qui remplisse correctement ce cahier des charges. Komodo Edit s'en rapproche, mais gère mal les deux derniers points (changer le codage du document va soit réinterpréter le document, soit le laisser tel quel, selon qu'on passe d'un codage simple à un codage multi-octets ou non; bug signalé mais pas corrigé ou classé WONTFIX, je sais plus). TextMate, que j'utilise actuellement, est assez lamentable si on veut travailler avec plusieurs codages. Je connais mal les éditeurs sur Windows.
Pspad gère pas trop mal les encodages, mais de là à ce qu'il te propose de changer les méta-tags... je crois qu'aucun éditeur le propose.
Nico3333fr a écrit :
mais de là à ce qu'il te propose de changer les méta-tags... je crois qu'aucun éditeur le propose

Il me semblait que Dreamweaver le fait. (Mais bon c'est pas essentiel.)
Modifié par fvsch (28 Jan 2011 - 15:00)
fvsch a écrit :
Je ne connais aucun éditeur qui remplisse correctement ce cahier des charges.


Salut Florent,
J'utilise Coda qui, me semble-t-il, remplit (à l'exception du bonus) presque ton cahier des charges (avec plugin pour le marquage BOM depuis la version 1.6, si j'ai bonne mémoire...), non ?

NB : Les noms ne sont pas ceux de la norme mais assez explicites quand même, je trouve...
NB2 : soucis de réinterprétation ISO vers UTF-8...

tm
Notepad++ me donne l'encodage courant et me permet la sauvegarde dans le mode désiré :

upload/34263-encodage.png

mais effectivement il ne rempli pas totalement le cahier des charges...
Administrateur
Nico3333fr a écrit :
Pspad gère pas trop mal les encodages, mais de là à ce qu'il te propose de changer les méta-tags... je crois qu'aucun éditeur le propose.

Niveau encodage je met aussi PSPad sur la 1ère marche du podium, je ne l'ai JAMAIS pris en défaut.
Notepad++ en deux (j'ai évidemment oublié dans quelles rares cinconstances j'avais eu des soucis avec ...)

edit: PSPad est payant dans le cadre d'une utilisation pro
Modifié par Felipe (28 Jan 2011 - 16:49)
Notepad++ était autrefois limité, et utilisait des noms bizarres pour certaines codages.
À partir de la version 4.0 ou 5.0 la gestion des codages a été largement améliorée, et c'est un des éditeurs qui propose à la fois le réencodage et la réinterprétation du fichier. Par contre, il utilise toujours des noms bizarres, et les fonctions réencodage/réinterprétation sont nommées de manière ambigüe. Donc bon d'un point de vue fonctionnel, mais gros problème de clarté.
Sujet clos
Aller à