j'ai une petite appli qui transforme des fichiers html locaux :
html -> xhtml -> ajout d'un menu -> publication (en xhtml mais avec
l'extension html.
bon, la conversion html -> xhtml se fait par tidy, à qui je dois donner
le charset entrant (en sortie je bascule tout en UTF-8)
là j'ai un problème de détection, je vien de faire un petit script ruby
qui détecte le charset, résultat des courses : 10 fichiers sur 26 n'ont
pas défini le charset dans une balise meta.
sur "fr.comp.infosystemes.www.auteurs" "on" me dit que cette balise
n'est qu'un pis-aller.
qu'il faut utiliser l'en-tête HTTP, ce qui n'est pas possible dans mon
cas vu que les fichiers sont locaux, sauvegardés dans un répertoire...
perso je pense attribuer "US-ASCII" à tous les fichiers qui ne déclarent
pas leur charset, par ce que c'est mieux que rien.
notes que je converti tout en UTF-8 pparce que j'ajoute de l'UTF-8 à la
page en question.
pensez-vous que ce soit uen bonne idée ???
savez vous qqc sur l'autodéttection du charset par les navigateurs ?
Je vois mal comment l'encodage d'un document HTML pourrait apparaître dans les infos sur les paramètres du serveur.
-- Eric Jacoboni, ne il y a 1445998638 secondes
pere.noel
Eric Jacoboni wrote:
Je vois mal comment l'encodage d'un document HTML pourrait apparaître dans les infos sur les paramètres du serveur.
pourtant c'est ce qu'on me dit sur "fr.comp.infosystemes.www.auteurs" que cette info est dans les en-têtes http et même que c'est une aberration de mettre le charset dans le fichier si son charset est inconnu (boucle)...
enfin, j'ai un très mauvais souvenir de cela, mais il faut dire avec wanadoo..., j'avais, il y a des années des scripts vrml sur mes pages, ils avaient l'extension "wrl", le contenu était du texte tout ce qu'il y a de plus banal.
eh bien chez wanadoo le serveur m'écrasait systématiquement qq lignes (les plus importantes pour la détection) du début de mes scripts.
je tél chez awnadoo, fini par obtenir "le chef de plateau" au bout du fil qui me dit simplement que leur serveur ne sait pas faire avec du vrml (le site était ok 1 ou 2 années auparavant chez le même FAI).
j'étais sur-excité... lui expliquer que mes scripts n'étaient que du texte us-ascii, qu'ilas avaient marchés chez eux etc...
rien à faire !
le workover (comme dirait Luc ;-)) fut simplement de renommer mess cripts en machin.txt au lieu de bidule.wrl... -- une bévue
Eric Jacoboni <jaco@neottia.net> wrote:
Je vois mal comment l'encodage d'un document HTML pourrait apparaître
dans les infos sur les paramètres du serveur.
pourtant c'est ce qu'on me dit sur "fr.comp.infosystemes.www.auteurs"
que cette info est dans les en-têtes http et même que c'est une
aberration de mettre le charset dans le fichier si son charset est
inconnu (boucle)...
enfin, j'ai un très mauvais souvenir de cela, mais il faut dire avec
wanadoo..., j'avais, il y a des années des scripts vrml sur mes pages,
ils avaient l'extension "wrl", le contenu était du texte tout ce qu'il y
a de plus banal.
eh bien chez wanadoo le serveur m'écrasait systématiquement qq lignes
(les plus importantes pour la détection) du début de mes scripts.
je tél chez awnadoo, fini par obtenir "le chef de plateau" au bout du
fil qui me dit simplement que leur serveur ne sait pas faire avec du
vrml (le site était ok 1 ou 2 années auparavant chez le même FAI).
j'étais sur-excité... lui expliquer que mes scripts n'étaient que du
texte us-ascii, qu'ilas avaient marchés chez eux etc...
rien à faire !
le workover (comme dirait Luc ;-)) fut simplement de renommer mess
cripts en machin.txt au lieu de bidule.wrl...
--
une bévue
Je vois mal comment l'encodage d'un document HTML pourrait apparaître dans les infos sur les paramètres du serveur.
pourtant c'est ce qu'on me dit sur "fr.comp.infosystemes.www.auteurs" que cette info est dans les en-têtes http et même que c'est une aberration de mettre le charset dans le fichier si son charset est inconnu (boucle)...
enfin, j'ai un très mauvais souvenir de cela, mais il faut dire avec wanadoo..., j'avais, il y a des années des scripts vrml sur mes pages, ils avaient l'extension "wrl", le contenu était du texte tout ce qu'il y a de plus banal.
eh bien chez wanadoo le serveur m'écrasait systématiquement qq lignes (les plus importantes pour la détection) du début de mes scripts.
je tél chez awnadoo, fini par obtenir "le chef de plateau" au bout du fil qui me dit simplement que leur serveur ne sait pas faire avec du vrml (le site était ok 1 ou 2 années auparavant chez le même FAI).
j'étais sur-excité... lui expliquer que mes scripts n'étaient que du texte us-ascii, qu'ilas avaient marchés chez eux etc...
rien à faire !
le workover (comme dirait Luc ;-)) fut simplement de renommer mess cripts en machin.txt au lieu de bidule.wrl... -- une bévue
lap
Même si, comme me le recommande madame W3C[1], je colle :
<?xml version="1.0" encoding="UTF-8"?> et <meta http-equiv='content-type' content='text/html; charset=utf-8' />
oui j'ai déjà vu ça, un apache configuré pour prétendre que toutes les pages qu'il sert sont en utf-8, ou en iso-8859-1. Et mon safari suivait aveuglément ce que lui disait le serveur, sans regarder les entêtes en haut de page html.
LaP
Même si, comme me le recommande madame W3C[1], je colle :
<?xml version="1.0" encoding="UTF-8"?>
et
<meta http-equiv='content-type' content='text/html; charset=utf-8' />
oui j'ai déjà vu ça, un apache configuré pour prétendre
que toutes les pages qu'il sert sont en utf-8, ou en iso-8859-1. Et
mon safari suivait aveuglément ce que lui disait le serveur, sans
regarder les entêtes en haut de page html.
Même si, comme me le recommande madame W3C[1], je colle :
<?xml version="1.0" encoding="UTF-8"?> et <meta http-equiv='content-type' content='text/html; charset=utf-8' />
oui j'ai déjà vu ça, un apache configuré pour prétendre que toutes les pages qu'il sert sont en utf-8, ou en iso-8859-1. Et mon safari suivait aveuglément ce que lui disait le serveur, sans regarder les entêtes en haut de page html.
LaP
ASM
enfin, j'ai un très mauvais souvenir de cela, mais il faut dire avec wanadoo...,
J'ai comme l'impression que chez wanadoo le serveur (au moins les sites page perso) aucune en-tête de charset n'est envoyée ...
Sans doute pour que, justement, ce soit le charset indiqué dans la page qui soit reconnu ?
Sinon, sur ton sitos page perso, comment fais-tu pour indiquer côté serveur tel ou tel charset en fonction de la page envoyée ?
scripts vrml sur mes pages, extension "wrl", (contenu texte banal).
rien à faire !
le workover (comme dirait Luc ;-)) fut simplement de renommer mess cripts en machin.txt au lieu de bidule.wrl...
Je viens de regarder chez moi et marche pô, en effet Ha! Ben ! le fichier *.wrl a disparu ! :-((
Et ça fonctionne maintenant en *.txt ? Page exemple ?
-- Stephane Moriaux et son [moins] vieux Mac
enfin, j'ai un très mauvais souvenir de cela, mais il faut dire avec
wanadoo...,
J'ai comme l'impression que chez wanadoo le serveur (au moins les sites
page perso) aucune en-tête de charset n'est envoyée ...
Sans doute pour que, justement, ce soit le charset indiqué dans la page
qui soit reconnu ?
Sinon, sur ton sitos page perso, comment fais-tu pour indiquer côté
serveur tel ou tel charset en fonction de la page envoyée ?
scripts vrml sur mes pages,
extension "wrl", (contenu texte banal).
rien à faire !
le workover (comme dirait Luc ;-)) fut simplement de renommer mess
cripts en machin.txt au lieu de bidule.wrl...
Je viens de regarder chez moi et marche pô, en effet
Ha! Ben ! le fichier *.wrl a disparu ! :-((
Et ça fonctionne maintenant en *.txt ?
Page exemple ?
enfin, j'ai un très mauvais souvenir de cela, mais il faut dire avec wanadoo...,
J'ai comme l'impression que chez wanadoo le serveur (au moins les sites page perso) aucune en-tête de charset n'est envoyée ...
Sans doute pour que, justement, ce soit le charset indiqué dans la page qui soit reconnu ?
Sinon, sur ton sitos page perso, comment fais-tu pour indiquer côté serveur tel ou tel charset en fonction de la page envoyée ?
scripts vrml sur mes pages, extension "wrl", (contenu texte banal).
rien à faire !
le workover (comme dirait Luc ;-)) fut simplement de renommer mess cripts en machin.txt au lieu de bidule.wrl...
Je viens de regarder chez moi et marche pô, en effet Ha! Ben ! le fichier *.wrl a disparu ! :-((
Et ça fonctionne maintenant en *.txt ? Page exemple ?
-- Stephane Moriaux et son [moins] vieux Mac
ASM
lap wrote:
mon safari suivait aveuglément ce que lui disait le serveur, sans regarder les entêtes en haut de page html.
OK, maintenant que tu en parles, je me souviens d'une page avec les en-têtes en utf-8 mais que Firefox s'obstine à ouvrir en cyrillique, : <http://www.aha.ru/~nick77/indexFr.htm>
ben ... sur un domaine "Russe" de quoi t'étonnes-tu ? à part les é è à ù, le reste semble OK (FireFox)
de plus : il y a un p'tit grigri avant le doctype (il ne faut rien de rien avant, même pas un espace)
Si c'est une page à toi : essayer de mettre le meta du charset immediatement après balise d'ouverture du head (qque fois que ...)
il y a pleins d'espaces glissés dans les balises et qui pourraient mettre la zone
voici ce que me dit Tidy pour cette page : line 1 column 1 - Warning: missing <!DOCTYPE> declaration
etc etc : en gros -> le zigouigoui avant le doctype gène un peu
line 20 column 1 - Warning: discarding unexpected <body> line 54 column 15 - Warning: missing </a> before <a> line 60 column 1 - Warning: discarding unexpected </a> line 65 column 36 - Warning: '<' + '/' + letter not allowed here line 62 column 1 - Warning: <script> inserting "type" attribute
0 erreur / 24 avertissements
Si la correction du doctype n'apporte rien il ne restera qu'à convertir les accentués en html-entités ( é = é )
-- Stephane Moriaux et son [moins] vieux Mac
lap <laurent_point_peron_point_lap@free.fr> wrote:
mon safari suivait aveuglément ce que lui disait le serveur, sans
regarder les entêtes en haut de page html.
OK, maintenant que tu en parles, je me souviens d'une page avec les
en-têtes en utf-8 mais que Firefox s'obstine à ouvrir en cyrillique, :
<http://www.aha.ru/~nick77/indexFr.htm>
ben ... sur un domaine "Russe" de quoi t'étonnes-tu ?
à part les é è à ù, le reste semble OK (FireFox)
mon safari suivait aveuglément ce que lui disait le serveur, sans regarder les entêtes en haut de page html.
OK, maintenant que tu en parles, je me souviens d'une page avec les en-têtes en utf-8 mais que Firefox s'obstine à ouvrir en cyrillique, : <http://www.aha.ru/~nick77/indexFr.htm>
ben ... sur un domaine "Russe" de quoi t'étonnes-tu ? à part les é è à ù, le reste semble OK (FireFox)
de plus : il y a un p'tit grigri avant le doctype (il ne faut rien de rien avant, même pas un espace)
Si c'est une page à toi : essayer de mettre le meta du charset immediatement après balise d'ouverture du head (qque fois que ...)
il y a pleins d'espaces glissés dans les balises et qui pourraient mettre la zone
voici ce que me dit Tidy pour cette page : line 1 column 1 - Warning: missing <!DOCTYPE> declaration
etc etc : en gros -> le zigouigoui avant le doctype gène un peu
line 20 column 1 - Warning: discarding unexpected <body> line 54 column 15 - Warning: missing </a> before <a> line 60 column 1 - Warning: discarding unexpected </a> line 65 column 36 - Warning: '<' + '/' + letter not allowed here line 62 column 1 - Warning: <script> inserting "type" attribute
0 erreur / 24 avertissements
Si la correction du doctype n'apporte rien il ne restera qu'à convertir les accentués en html-entités ( é = é )
-- Stephane Moriaux et son [moins] vieux Mac
lists
Eric Jacoboni wrote:
Je vois mal comment l'encodage d'un document HTML pourrait apparaître dans les infos sur les paramètres du serveur.
D'après ce que j'ai compris, on peut le voir avec telnet:
% telnet www.juliensalort.org 80 Trying 213.186.33.40... Connected to juliensalort.org. Escape character is '^]'. GET index.html HTTP/1.0
HTTP/1.1 301 Moved Permanently Date: Fri, 17 Mar 2006 11:42:13 GMT Server: Apache Location: http://300gp.ovh.netindex.html/ Connection: close Content-Type: text/html; charset=iso-8859-1
Là le serveur indique que le fichier HTML qui suit est codé en ISO-8859-1.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Eric Jacoboni <jaco@neottia.net> wrote:
Je vois mal comment l'encodage d'un document HTML pourrait apparaître
dans les infos sur les paramètres du serveur.
D'après ce que j'ai compris, on peut le voir avec telnet:
% telnet www.juliensalort.org 80
Trying 213.186.33.40...
Connected to juliensalort.org.
Escape character is '^]'.
GET index.html HTTP/1.0
HTTP/1.1 301 Moved Permanently
Date: Fri, 17 Mar 2006 11:42:13 GMT
Server: Apache
Location: http://300gp.ovh.netindex.html/
Connection: close
Content-Type: text/html; charset=iso-8859-1
Là le serveur indique que le fichier HTML qui suit est codé en
ISO-8859-1.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Je vois mal comment l'encodage d'un document HTML pourrait apparaître dans les infos sur les paramètres du serveur.
D'après ce que j'ai compris, on peut le voir avec telnet:
% telnet www.juliensalort.org 80 Trying 213.186.33.40... Connected to juliensalort.org. Escape character is '^]'. GET index.html HTTP/1.0
HTTP/1.1 301 Moved Permanently Date: Fri, 17 Mar 2006 11:42:13 GMT Server: Apache Location: http://300gp.ovh.netindex.html/ Connection: close Content-Type: text/html; charset=iso-8859-1
Là le serveur indique que le fichier HTML qui suit est codé en ISO-8859-1.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Eric Jacoboni
(Julien Salort) writes:
Là le serveur indique que le fichier HTML qui suit est codé en ISO-8859-1.
Oui, le content-type du document HTML que tu as demandé : cela ne dépend donc pas du serveur, mais du document, non ? On se comprend peut-être mal, mais pour moi, un content-type, c'est lié à UN document, pas au serveur. Sinon, je ne vois pas comment le même serveur pourrait servir des documents encodés différemment. Mais, bon... je ne suis pas un grand spécialiste de la chose.
Si le fameux $_SERVER[] correspond bien à ce que je pense, à un tableau contenant les variables d'environnement du serveur et du script, voilà ce que j'obtiens (en Ruby/CGI, ça s'appelle ENV) :
AUTH_TYPE DOCUMENT_ROOT GATEWAY_INTERFACE HTTP_ACCEPT HTTP_ACCEPT_ENCODING HTTP_ACCEPT_LANGUAGE HTTP_CONNECTION HTTP_COOKIE HTTP_HOST HTTP_IF_MODIFIED_SINCE HTTP_USER_AGENT MOD_RUBY PATH REMOTE_ADDR REMOTE_PORT REMOTE_USER REQUEST_METHOD REQUEST_URI SCRIPT_FILENAME SCRIPT_NAME SERVER_ADDR SERVER_ADMIN SERVER_NAME SERVER_PORT SERVER_PROTOCOL SERVER_SIGNATURE SERVER_SOFTWARE UNIQUE_ID -- Eric Jacoboni, ne il y a 1446038315 secondes
lists@juliensalort.org (Julien Salort) writes:
Là le serveur indique que le fichier HTML qui suit est codé en
ISO-8859-1.
Oui, le content-type du document HTML que tu as demandé : cela ne
dépend donc pas du serveur, mais du document, non ? On se comprend
peut-être mal, mais pour moi, un content-type, c'est lié à UN
document, pas au serveur. Sinon, je ne vois pas comment le même
serveur pourrait servir des documents encodés différemment. Mais,
bon... je ne suis pas un grand spécialiste de la chose.
Si le fameux $_SERVER[] correspond bien à ce que je pense, à un
tableau contenant les variables d'environnement du serveur et du
script, voilà ce que j'obtiens (en Ruby/CGI, ça s'appelle ENV) :
AUTH_TYPE
DOCUMENT_ROOT
GATEWAY_INTERFACE
HTTP_ACCEPT
HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE
HTTP_CONNECTION
HTTP_COOKIE
HTTP_HOST
HTTP_IF_MODIFIED_SINCE
HTTP_USER_AGENT
MOD_RUBY
PATH
REMOTE_ADDR
REMOTE_PORT
REMOTE_USER
REQUEST_METHOD
REQUEST_URI
SCRIPT_FILENAME
SCRIPT_NAME
SERVER_ADDR
SERVER_ADMIN
SERVER_NAME
SERVER_PORT
SERVER_PROTOCOL
SERVER_SIGNATURE
SERVER_SOFTWARE
UNIQUE_ID
--
Eric Jacoboni, ne il y a 1446038315 secondes
Là le serveur indique que le fichier HTML qui suit est codé en ISO-8859-1.
Oui, le content-type du document HTML que tu as demandé : cela ne dépend donc pas du serveur, mais du document, non ? On se comprend peut-être mal, mais pour moi, un content-type, c'est lié à UN document, pas au serveur. Sinon, je ne vois pas comment le même serveur pourrait servir des documents encodés différemment. Mais, bon... je ne suis pas un grand spécialiste de la chose.
Si le fameux $_SERVER[] correspond bien à ce que je pense, à un tableau contenant les variables d'environnement du serveur et du script, voilà ce que j'obtiens (en Ruby/CGI, ça s'appelle ENV) :
AUTH_TYPE DOCUMENT_ROOT GATEWAY_INTERFACE HTTP_ACCEPT HTTP_ACCEPT_ENCODING HTTP_ACCEPT_LANGUAGE HTTP_CONNECTION HTTP_COOKIE HTTP_HOST HTTP_IF_MODIFIED_SINCE HTTP_USER_AGENT MOD_RUBY PATH REMOTE_ADDR REMOTE_PORT REMOTE_USER REQUEST_METHOD REQUEST_URI SCRIPT_FILENAME SCRIPT_NAME SERVER_ADDR SERVER_ADMIN SERVER_NAME SERVER_PORT SERVER_PROTOCOL SERVER_SIGNATURE SERVER_SOFTWARE UNIQUE_ID -- Eric Jacoboni, ne il y a 1446038315 secondes
pere.noel
Julien Salort wrote:
Là le serveur indique que le fichier HTML qui suit est codé en ISO-8859-1.
ouais mais ce n'est pas tous les serveurs qui font ça, l'info charset n'est pas obligatoire (w3c) dans l'en-tête, elle n'est pas obligatoire dans une balise meta non plus (dixit w3c) par contre, l'info, en elle-même doit être présente mais où, compte-tenu de ce qui précède...
-- une bévue
Julien Salort <lists@juliensalort.org> wrote:
Là le serveur indique que le fichier HTML qui suit est codé en
ISO-8859-1.
ouais mais ce n'est pas tous les serveurs qui font ça, l'info charset
n'est pas obligatoire (w3c) dans l'en-tête, elle n'est pas obligatoire
dans une balise meta non plus (dixit w3c) par contre, l'info, en
elle-même doit être présente mais où, compte-tenu de ce qui précède...
Là le serveur indique que le fichier HTML qui suit est codé en ISO-8859-1.
ouais mais ce n'est pas tous les serveurs qui font ça, l'info charset n'est pas obligatoire (w3c) dans l'en-tête, elle n'est pas obligatoire dans une balise meta non plus (dixit w3c) par contre, l'info, en elle-même doit être présente mais où, compte-tenu de ce qui précède...
-- une bévue
pere.noel
Une bévue wrote:
ouais mais ce n'est pas tous les serveurs qui font ça, l'info charset n'est pas obligatoire (w3c) dans l'en-tête, elle n'est pas obligatoire dans une balise meta non plus (dixit w3c) par contre, l'info, en elle-même doit être présente mais où, compte-tenu de ce qui précède...
dans l'un des deux m'a t'on prcisé sur "fr.comp.infosystemes.www.auteurs".
-- une bévue
Une bévue <pere.noel@laponie.com.invalid> wrote:
ouais mais ce n'est pas tous les serveurs qui font ça, l'info charset
n'est pas obligatoire (w3c) dans l'en-tête, elle n'est pas obligatoire
dans une balise meta non plus (dixit w3c) par contre, l'info, en
elle-même doit être présente mais où, compte-tenu de ce qui précède...
dans l'un des deux m'a t'on prcisé sur
"fr.comp.infosystemes.www.auteurs".
ouais mais ce n'est pas tous les serveurs qui font ça, l'info charset n'est pas obligatoire (w3c) dans l'en-tête, elle n'est pas obligatoire dans une balise meta non plus (dixit w3c) par contre, l'info, en elle-même doit être présente mais où, compte-tenu de ce qui précède...
dans l'un des deux m'a t'on prcisé sur "fr.comp.infosystemes.www.auteurs".
-- une bévue
Erwan David
jose.campos+ (José Campos) écrivait :
Erwan David wrote:
C'est pourtant tellement reposant de coller un charset utf-8 oukifo et ensuite de taper sans soucis ;-)
Encore faut-il que le serveur de l'hébergeur envoie le bon en-tête...
Même si, comme me le recommande madame W3C[1], je colle :
<?xml version="1.0" encoding="UTF-8"?> et <meta http-equiv='content-type' content='text/html; charset=utf-8' /> ?
Ça c'est l'en-tête HTML, il y a aussi l'en-tête HTTP, qui se règle dans la configuration du serveur...
D'ailleurs, comment récupère-t-on le dit en-tête? je ne le vois pas dans $_SERVER[].
On fait la transaction HTTP à la main.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
