[Résolu] Pages encodées UTF8 reviennent en ANSI à la réouverture

Bonjour !

Voici, mon "petit" souci :

sous Notepad++ j'ai créé mes pages sous l'encodage UTF-8 sans BOM. Après fermeture et réouverture des dites pages, certaines restent sous l'encodage d'origine et d'autres basculent en ANSI... je réencode la page en UTF8 sans BOM mais après fermeture/réouverture le résultat est le même ; idem si je créé à nouveau la page. Je ne comprends pas... exemple la page aide.php restera toujours dans son encodage d'origine contrairement à la page aproposdenous.php qui elle bascule en ANSI dès sa réouverture.

les pages sont toujours visibles à cette adresse : www.enveloppes-ardennes.com/essais/index.php.

Vous remarquerez que les pages aide.php et aproposdenous.php ont pourtant exactement la même structure...

Quelqu'un a t-il une idée ? merci !!

Marie
Modifié par Marie08 (25 Jun 2012 - 16:36)

Bonjour,

quelle préférence a Notepad++ dans :
Paramétrage / Préférences / Nouveau document/Dossier => Encodage ?
Perso j'ai UTF-8 sans BOM, pas appliqué aux fichiers ANSI ouverts (parce que j'ouvre indifféremment des fichiers de client en UTF-8 et parfois en ANSI).

Regarde dans chacun des fichiers s'il y a ou non des caractères pas encodés pareils en UTF-8, notamment les diacritiques é à etc
Peut-être que Notepad++ sait quoi faire quand il rencontre un é alors que si le document est strictement identique encodé en ANSI ou UTF-8 il est bien en peine de savoir quoi faire (i.e. si le document est du pur ASCII 7 bits)

Bonjour Felipe et merci de ta réponse

Mon Notepad++ est paramétré de la même façon que le tien pourtant.

De plus, je viens de remarquer une chose étrange : en faisant ctrl+U sur l'index.php la source démarre bien en ligne 1 avec le doctype. Alors que sur les pages aide.php et aproposdenous.php, la source démarre à la ligne 6 ! il y a cinq lignes vides avant la déclaration du doctype... chose que je n'ai pas sur mon notepad++

tu as une explication possible ?

Marie
Modifié par Marie08 (24 Jun 2012 - 15:57)

Marie08 a écrit :
en faisant ctrl+U sur l'index.php
(...)
chose que je n'ai pas sur mon notepad++

Dans ton éditeur de code tu vois le code PHP de ta page.
Dans ton navigateur tu reçois le code HTML (ou tout autre format de données) généré par ce code PHP une fois interprété par le serveur web.
Donc forcément c'est pas la même chose.

Pour le reste, si je puis me permettre:
- Lire les Notions de base sur les codages de caractères.
- Travailler en UTF-8 (ou UTF-8 sans BOM dans les logiciels qui proposent à la fois "UTF-8" et "UTF-8 sans BOM"). Partout. Tout le temps.

Bonjour fvsch

a écrit :
Dans ton éditeur de code tu vois le code PHP de ta page.
Dans ton navigateur tu reçois le code HTML (ou tout autre format de données) généré par ce code PHP une fois interprété par le serveur web.
Donc forcément c'est pas la même chose.

ok c'est compris

a écrit :
Pour le reste, si je puis me permettre:
- Lire les Notions de base sur les codages de caractères.
- Travailler en UTF-8 (ou UTF-8 sans BOM dans les logiciels qui proposent à la fois "UTF-8" et "UTF-8 sans BOM"). Partout. Tout le temps.

Je ne devrais même pas le dire mais... j'ai lu toute la faq... et autres articles traitant du sujet sur Alsacreations... et il m'a semblé pourtant que j'appliquais correctement les consignes j'ai raté un truc alors. J'y retournerai donc !

Merci !

Marie

En regardant le site: toutes tes pages sont déclarées (dans le code HTML) en UTF-8, et apparemment tes données sont bien en UTF-8 donc ça passe bien.
Du côté des en-têtes HTTP, aucun codage de caractères n'est déclaré, et tu peux laisser les choses en l'état.

Maintenant, pour comprendre ce qui se passe quand tu ouvres un fichier dans un éditeur de code, il faut savoir que les fichiers texte brut n'ont en général pas de métadonnée qui précise le codage de caractères utilisé. Les éditeurs de code ont donc trois moyens de détecter le codage de caractère utilisé pour savoir comment analyser le contenu (car tout logiciel qui lit un fichier texte, que ce soit un éditeur de code ou un navigateur, ne lit pas des lettres: il lit des nombres, en l'occurrence des octets, et il doit appliquer un filtre de conversion pour savoir quel caractère correspond à quel nombre):
1. Il peut chercher un texte qui annonce un codage précis, par exemple <meta charset="..."> en HTML ou @charset "..."; en CSS. Beaucoup d'éditeurs de code n'utilisent pas du tout cette méthode.
2. Il peut analyser le contenu (octets) du fichier et essayer de déterminer avec un algorithme de quel codage il peut s'agir (en utilisant des probabilités). Quand la probabilité est forte qu'il s'agisse du codage "X", il va donc utiliser "X" pour interpréter le fichier.
3. À défaut d'information existante ou de détection efficace, il va utiliser un codage par défaut, qui peut souvent être modifié dans les préférences du logiciel.

Ici tu es sans doute dans le deuxième cas. Et si ton éditeur de code détecte du ANSI (nom qui ne veut rien dire, car Notepad++ est une merde, mais il s'agit en fait de ISO-8859-1) c'est parce que beaucoup de jeux de caractères sont rétrocompatibles avec ASCII, notamment ISO-8859-1 et UTF-8. ISO-8859-1 et UTF-8 sont tous les deux différents de ASCII et surtout très différents entre eux, mais si tu te limites au jeu de caractères réduit contenu dans ASCII et que tu enregistres ton fichier en UTF-8 ou en ISO-8859-1 ou en ASCII... tu obtiens dans tous les cas un fichier ASCII.

C'est souvent le cas avec un fichier qui contient essentiellement ou uniquement du code: comme les langages informatiques utilisent exclusivement les caractères ASCII, tu as beau enregistrer ton fichier en UTF-8 tu obtiens en fait un fichier ASCII. Donc Notepad++ détecte (à l'ouverture) un fichier ASCII, et comme ISO-8859-1 est compatible ASCII (et est sans doute utilisé dans les réglages du logiciel comme codage par défaut) il va utiliser ISO-8859-1 (qu'il appelle ANSI parce que le développeur de Notepad++ fume des trucs pas nets).

Un grand merci : tu as fait preuve une nouvelle fois d'une grande patience en expliquant à nouveau un sujet que tu as déjà traité "trente-six mille fois" rien que sur ce site.

Cela est sécurisant de pouvoir compter sur des forumiens aux explications claires rendant l'intervention efficace

Marie

Bonjour,

Je viens de lire attentivement ce sujet car je me retrouve dans le même cas avec un fichier php que j'appelle via include dans ma page. Impossible de l'enregistrer au format utf-8. Ce fichier est composé de quelques blocs divs et d'une liste. Il est entièrement rédigé en anglais (voir plus bas le code).

Si je lis le point 2 que tu évoques fvsch et si je comprends bien, c'est à dire que mon fichier n'ayant aucun caractères spécifiques pourra être interprêté comme étant un fichier ASCII ?
Dreamweaver me le réouvre et m'indique le format "Europe de l'Ouest", alors que je l'avais encodé en UTF. Le même fichier en français lui par contre, structure identique mais ayant donc des accents est bien enregistré et reconnu en UTF-8.

Cela peut-il poser des soucis au niveau du site ?
Merci d'avance pour ta réponse.

<div id="header-top">
	<div id="header-langues">ENGLISH FRANCAIS</div>
</div>
<div id="header-bottom">
	<div id="navigation">
		<ul id="menu1">
			<li>Link</li>
			<li>Link</li>
			<li>Link</li>
			<li>Link</li>
			<li>Link</li>
		</ul>
	</div>
</div>