5172 sujets

Le Bar du forum

Passage du forum en ISO-8859-15 ou UTF8

Pages :
(reprise du message précédent)

Quentin:
a écrit :
LD > une explication peut-être : c'était le premier post de la journée et hier soir je me suis couché à 3h


Donc tu as anticipé dès le premier post, le coucher tardif? Smiley lol Smiley lol Smiley lol Smiley rofl
Vajra a écrit :
Donc tu as anticipé dès le premier post, le coucher tardif? Smiley lol Smiley lol Smiley lol Smiley rofl
Smiley lol

Il va falloir que je m'intéresse de plus près au encodage aussi... Merci pour toute vos contributions Smiley cligne
Vajra a écrit :
Salut,

Problème: un internaute français qui est en ... Asie Smiley lol ou au Brésil, veut lire ces pages dans un cyber café de Macao ou de Rio de Janeiro... Smiley lol .
Sachant que les cyber café de macao ou de Rio de Janeiro ont le même matériel informatique, dans laquelle de ces villes ces pages pourront être lue en moins de 5 secondes par l'internaute?


Peut-être en adaptant l'encodage du navigateur à celui de la page ?
boulaneige a écrit :


Peut-être en adaptant l'encodage du navigateur à celui de la page ?


C'est ce que font déjà tous les navigateurs, en se basant sur l'en-tête HTTP content-type... charset..., et à défaut, sur différentes pratiques Vaudou secrètes inavouables pour rectifier au mieux les erreurs ou l'absence d'information sur l'encodage.

Cela dit, pour Macao et Rio, tout dépend dans quel sens va le Nino à ce moment là. La température du Gulf Stream influe aussi. C'est très sensible aux variations atmosphériques, ces choses-là.
Laurent Denis a écrit :


C'est ce que font déjà tous les navigateurs, en se basant sur l'en-tête HTTP content-type... charset..., et à défaut, sur différentes pratiques Vaudou secrètes inavouables pour rectifier au mieux les erreurs ou l'absence d'information sur l'encodage.


J'ai beau aller sur un site avec charset=iso-8859-15, quand je regarde l'encodage de Firefox, il reste sur iso-8859-1.

Encore une subtilité qui m'échappe...

Vivement que je récupère mon ordi pour lancer une batterie de tests...
Laurent Denis a écrit :


<p>&oelig;uf...</p>


<edit>Oui, EricLB, tu as mis directement le caractère oe dans ton message, et il est passé... en rendant invalide cette page du forum, car dans ton message, il n'est pas encodé en ISO-8859-1, mais en Windows 1252, jeu de caractère incompatible avec Unicode, HTML, et qui te vaudra de produire des jolis carrés énigmatiques sur des navigateurs linux par exemple...


Hum hum...
Quitte à paraître candide, je ne vois pas vraiment la différence entre codifier le "oe" en &oelig; et le é en &eacute;... ça voudrait dire que dans le 1° cas ce nest pas valide alors que dans le 2° oui ? Smiley ohwell

En fait j'avais codé mes "oe" en &oelig; et non en &#339;...
boulaneige a écrit :


J'ai beau aller sur un site avec charset=iso-8859-15, quand je regarde l'encodage de Firefox, il reste sur iso-8859-1.


Si Firefox indique ISO-8859-1 comme encodage dans Outils>Informations sur la page, ou dans Affichage>Encodage des caractères, c'est qu'il s'agit d'une page mal servie: l'auteur a sans doute utilisé de l'ISO-8859-15 dans le fichier, mais n'a pas configuré son serveur pour qu'il indique ce jeu de caractères dans l'en-tête HTTP accompagnant le fichier.

(Rappel: ce n'est pas la <meta http-equiv...> qui sert au navigateur à déterminer l'encodage d'une page Web en ligne. A ce stade, elle est là pour faire joli.)
Ah d'accord...

Je viens de faire un phpinfo chez mon hébergeur, et j'ai trouvé ceci :

HTTP_ACCEPT_CHARSET 	ISO-8859-1,utf-8;q=0.7,*;q=0.7


Cela veut-il dire qu'il ne faut pas que je travaille en iso-8859-15 ?

J'aurais jamais pensé que c'était si compliqué de choisir un charset !

Encore merci pour ces précisions, et ta patience Smiley cligne
EricLB a écrit :


Hum hum...
Quitte à paraître candide, je ne vois pas vraiment la différence entre codifier le "oe" en &#339; et le é en é... ça voudrait dire que dans le 1° cas ce nest pas valide alors que dans le 2° oui ? Smiley ohwell


Non, ça n'est pas du tout ça.

Quand on dit qu'ISO-8859-1 permet d'écrire un caractère é mais pas un caractères oe, cela veut dire :
- que tu n'as pas besoin d'écrire &eacute; . Tu peux saisir directement le caractère é. Le &eacute; est tout à fait valide, mais totalement inutile en ISO-8859-1.
- que tu ne peux pas saisir directement le caractère oe. Dans son cas, au contraire, tu dois passer par &oelig;

Voir les abondantes explications données dans ce sujet Smiley cligne
boulaneige a écrit :
Ah d'accord...

Je viens de faire un phpinfo chez mon hébergeur, et j'ai trouvé ceci :

HTTP_ACCEPT_CHARSET 	ISO-8859-1,utf-8;q=0.7,*;q=0.7


Cela veut-il dire qu'il ne faut pas que je travaille en iso-8859-15 ?


Non, perdu.... désolé Smiley cligne

ça, c'est l'en-tête envoyé par ton navigateur au serveur quand il demande la page Web pour indiquer quels encodages il aime bien recevoir par défaut, et dans quel ordre de préférence. Mais ce n'est pas d'une importance capitale, en fait : les navigateurs ne déclarent pas le 10e de ce qu'ils peuvent interpréter.

Ce que tu cherches, c'est l'en-tête envoyé par le serveur à ton navigateur quand il envoit la page Web, pour indiquer l'encodage de la page.

Pour ne pas désespérer... Smiley cligne PHPinfo n'est simplement pas le bon outil. Va plutôt à l'adresse http://web-sniffer.net/ . Entre l'url d'une page Web quelconque : Web-Sniffer va t'afficher ces échanges d'informations HTTP entre ton navigateur et le serveur qui héberge la page en question :
- HTTP Request Header : c'est ton navigateur qui parle.
- HTTP Response Header : le serveur parle, c'est là qu'est l'info sur le jeu de caractère, dans la ligne Content-Type. Il se peut qu'elle manque : tu es tombé sur un serveur qui ne fait pas son boulot et qui n'envoie pas cette info essentielle.
Modifié par Laurent Denis (18 Dec 2005 - 20:29)
Alors, j'ai absolument rien compris au formulaire, j'ai donc tout laissé par défaut.

Si je mets l'adresse d'une page en iso-8859-1 et sans doctype (oui je sais, je suis justement en train de refaire ce site), il indique dans HTTP Response Header :
Content-Type: text/html


Avec une page en iso-8859-15 et le doctype X-HTML 1.0 strict : 
Content-Type: text/html; charset=iso-8859-1


Et je ne désespère pas, j'ai juste un peu honte d'étaler au grand jour une de mes nombreuses lacunes Smiley cligne
En fait, dans tout ça, il y a un truc que je ne comprends pas tout à fait encore...

Je suis sous Konqueror (Linux donc...)

Tapons directement le caractère oe : ici ->&#339;<- (N.B. Chez moi, dans l'éditeur de message, il apparaît correctement, mais il se transforme en &amp;#339; [ce qu'on trouve dans la source de la page...]). En fait, ce n'est pas vraiment un problème d'encodage, mais plutôt un bug du forum... Puisqu'il devrait transformer mon caractère en &#339; (ou en &oelig;), pas en &amp;#339;, non ?

Ou alors je ne comprends plus rien là...

Finalement, l'encodage du forum importe peu, du moment qu'on peut remplacer tout caractère manquant par son "entité". Le problème est que, dans mon cas, ça foire... Bug du forum ou bug de Konqueror ?

@+, HoPHP
Bonjour,

Hophp : it's not a bug, it's a feature Smiley cligne

Dew nous le confirmera, mais ce remplacement par &amp;#339; est très probablement voulu, pour faciliter les discussions à propos d'entités, où l'on a besoin de les inclure dans les messages sans qu'elles soient interprétées.

(Si ma mémoire est bonne, au départ, le forum laissait passer les entités sans les échapper, ce qui avait suscité quelques râleries Smiley lol )

boulaneige : ton serveur semble curieusement configuré. S'il s'agit de http://www.boulaneige.com :
- il n'envoie aucune information d'encodage pour les pages .php, ni pour les pages .htm (accueil)
- je suppose qu'il envoie un charset iso-8859-1 pour les pages html (ton test en iso-88589-15 ?)

Tu peux modifier cette configuration de plusieurs manières. Par exemple :

Pour que tous les fichiers .php du serveur soient servis avec le charset iso-8859-15, ajouter au .htaccess :
AddCharset iso-8859-15 .php

(et ainsi de suite pour les différentes extensions de fichier)


Pour qu'un seul fichier php précis soit servi avec ce charset, ajouter directement au début du fichier lui-même :
<?php 
header('Content-Type: text/html; charset=iso-8859-15');
 ?>


A propos de ces questions d'encodage : il y a une excellente série de slides sur le site de la section i18n du W3C, malheureusement uniquement en anglais : http://www.w3.org/International/tutorials/tutorial-char-enc/en/slides/Slide0240.html
Modifié par Laurent Denis (19 Dec 2005 - 05:37)
Réponse au post de L.D. 5h32 : C'est surtout pour éviter de faire un bug si on rentre le caractère & directement sous windows... car il n'est pas encodé en &amp;
Pour le serveur, je suis en mutualisé chez phpnet.org. Je pense que l'admin pourrait être sensible au problème s'il est bien exposé, chose dont je suis bien incapable.

Le premier test a effectivement était fait sur mon splash, le second sur la nouvelle future version (SPIP) (c'est loin d'être fini : on rigole mais on ne se moque pas !).

Je pense que je vais revenir en iso-8859-1, c'est le charset utilisé dans les squelettes fournis par défaut dans SPIP. Et comme tu sais surement, dans la console d'administration, il y a des raccourcis pour faire notamment le oe, euro, é majuscules. Bref, ils ont tout prévu Smiley smile

Désolée pour ton lien, mais l'anglais et moi, ça fait un nombre certain Smiley confused
Modifié par boulaneige (19 Dec 2005 - 11:37)
QuentinC a écrit :
Ah ben forcément, si vous comptez les lettres accentuées... c'est à autre chose que je pensais.

Juste une question, j'ai pas trouvé le code Alt+XXXX pour reproduire le oe lié...

Et la broken bar ¦ elle sert à quoi ?

alt +144
;)
Laurent Denis> Désolé. Pour moi, ça, c'est un bug ! Ou alors il faut qu'on m'explique en quoi ça gêne!

Parce que je ne comprends pas pourquoi la transformation caractère-entité se fait deux fois... oe -> &#339; => &amp;#339;

???

Dew ?
HoPHP a écrit :
Laurent Denis> Désolé. Pour moi, ça, c'est un bug ! Ou alors il faut qu'on m'explique en quoi ça gêne!


Parce qu'en l'absence de caractère d'échappement, toute entité sera reproduite en tant que caractère et non à l"identique, ce qui est gênant quant tu ne veux pas obtenir le caractère résultant, mais l'entité dans ton message.

Exemple : si on me demande comment obtenir le signe é en us-ascii, je pourrais toujours écrire &eacute; dans mon message, ça donnera un é. Mon interlocuteur sera bien avancé Smiley cligne


Ou alors, il faudra que j'écrive des choses du genre : un & eacute; sans l'espace entre le & et le eacute... bof.

La solution qui mettra tout le monde d'accord: réplication des entités à l'identique sans encodage du & et possibilité d'utiliser un caractère d'échappement du & quand on veut obtenir l'entité et non le caractère. Restera aux modos à expliquer comment ça marche aux utilisateurs Smiley cligne


HoPHP a écrit :
Dew ?

Oui, on va tous se prendre une grande claque, là, parce qu'on a tout faux Smiley lol : DEW ! DEW ! DEW ! (sur l'air de We are the champions avec les briquets et tout)

<edit>Non, mais. Ce gars se les casse à vous produire une solution de forum très promettrice. Et vous râlez parce qu'il ne fait pas les o dans l'e ? Bandes de maniaques obsessionnels ! Smiley lol
</>
Modifié par Laurent Denis (19 Dec 2005 - 14:49)
En fait, je crois que la solution dans ce cas devrait s'énoncer comme suit:
a écrit :
À part les codes Wiki, tout caractère devrait s'afficher comme dans la fenêtre d'écriture.

Donc la seule chose à transformer, c'est le & en &amp; et les caractères "hors charset" en entités, rien d'autre, afin d'avoir l'affichage correct. Là où je ne comprends pas, c'est la double transformation. Il prend mon caractère oe et il le transforme en &#339; puis en &amp;#339; ce qu'il ne devrait pas faire. C'est donc un bug, non?

DEW, DEW, DEW, DEW !

@+, HoPHP

P.S. Dew> En fait, une réponse "oui, ajouté à la To-dew" ou "non, jamais" me suffirait !
Pages :
Sujet clos
Aller à