Hello
J'ai un petit problème avec la validation d'un simple fichier XHTML.
Ce petit c*n déconne avec les accents francais.
J'ai pourtant bien précisé le charset au niveau du xml, et dans une balise meta pour le html.
voici le code:

je suppose que l'erreur est toute bête, merci pour votre future aide

http://forum.hardware.fr/forum2.ph [...] =1#t487916
 
 

 
Il manque un / avant la fermeture du tag meta (xhtml -> faut fermer même les tags simples, <meta /> à la place de <meta>
À part ça, aucune erreur.

pour la fermeture de la meta, c'est une erreur tout bête de copier/coller    
 
sinon, si j'ai bien compris, je dois refaire moi-meme la dtd??
autrement l'erreur obtenue sur le validateur est celle-ci:

c'est peut être con ce que je vais dire, mais si tu essaies de mettre la meta avant le titre ?

le plus simple c'est de passer ton charset en us-ascii mais tu vas perdre des accents  

chez moi j'ai pas d'erreur après avoir rajouté ce /
c'est très bizarre...

idem    
 

gnu?
 

nan y'a mieux, je mets les codes html pour les accents et ca passe au pire

quoi "gnu" ?
chez moi il me dit que ta page est valide
 

 
spa beau ça

chez moi il vaut pas la lire à cause des accents, d'ou pourrait donc provenir la faute    
c'est bien ce validateur la: http://validator.w3.org/

Note que j'ai uploadé le fichier à partir de mon PC, plutôt que de donner une URL

j'ai fais pareil  

tricheur

> urd-  : et en us-ascii sans les accents, ca passe ?

je vais essayer à la maison ce soir, mais ca me semble + qu'étrange

oui
de meme qu'avec les codes html

tu as essayé en utf-8 ?

tu veux que j'essaye de chez moi ?  

ca marche pas le
essaye tjs si tu peux ouais

t'es sûr ... ? tu veux pas qu'on essaye ensemble ?

   
 
tu lui as donné quel extension antpai ?

c'est moi qui a cette erreur  

 
.html
 

renommé en conséquence et pas de changement

pareil ....
incompréhensible  

ie    
j'essaye avec moz...
 
 
et non, toujours la meme erreur

Si on indique au validateur le bon encodage, ça passe. Sinon il a l'air de refuser de détecter tout autre encodage que l'us-ascii. Bug ?

c'est quoi les éditeurs (de texte) que vous utilisez ?
peut être que ceux eux qui sauvegarde pas le doc au bon charset ...

testé au bloc-note  

textpad, mais je pense pas que ca soit le problème
mais si jamais j'essayerai avec un autre ce soir

je viens d'essayer à la maison et j'ai toujours le problème.
visiblement ca doit être qqch que je fais de faux
je regarde demain, marre de l'ordi pour today

Je sais
J'ai eu ce problème avec un serveur de test sur lequel j'avais viré tous les type/mime.
 
Bon, déjà, premier truc, enregistre ton fichier en indiquant bien le bon charset, puis envoie par FTP en mode binaire.
Si l'erreur persiste, alors essaie chez un autre hébergeur. A tout les coup tu vas voir que ça va passer.
 
En effet, le type/mime est spécifié au niveau du serveur, et le charset (par défaut us-ascii) aussi. Donc le le type/mime existe sur le serveur et indique us-ascii, ça va merder, quelques soient tes tags.
 
D'où une des recommandations W3C qui consiste à faire systématiquement du us-ascci contrairement à ce que m'a répondu je ne sais plus qui dans un topic à propos du XML.

chez toi, t'as assayé sur un serveur web ou directement depuis le fichier ?

Pour la réponse, je me base sur cette page de validation :
 
http://validator.w3.org/check?uri= [...] 2Fdisk.xml
 
le type d'encodage est pourtant spécifié dans le fichier.
 
mais pas sur le serveur (en fait, y'a plus de type/mime associé à XML)
 

 
-- Edit : Voilà, gilou et Kristof, avant de me contredire outrageusement quand je parle de norme, veuillez les lire entièrement

PS: J'entends déjà arriver les défenseurs de l'UTF-8 qui est le standard du XML et que la phrase que j'ai posté dis simplement qu'à défaut d'être spécifié, on prend l'us-ascii.
 
On est tous d'accord que la phrase signifie que l'us-ascii est le plus petit dénominateur commun. C'est à dire que si tout ce passe bien, on peut utiliser autrechose (et à ce moment, l'UTF-8 est en effet bien pratique). Mais on est aussi d'accord sur le faite (et là c'est le meilleur exemple) que si on ne peux s'assurer que d'un bout à l'autre, cet encodage sera correctement supporté/interprété/transporté - ce qui mise à part pour un fichier XML lu en local je vois pas comment on peut le garantir - il faut utilise l'us-ascii, qui est le plus petit dénominateur commun, afin de s'assurer d'une portabilité sans faille.
Hors, le rôle des recommandations d'une norme, c'est de proposer une solution, qui, quelquesoit le contexte, fonctionnera toujours dans n'importe quelle situation. On ne me fera pas alors gober que l'UTF-8 puisse être recommandé, puisque dès le client FTP on à une change sur deux que le fichier soit transporté en mode texte, c'est à dire sur 7 bits au lieu de 8, et ce, même si le format text/xml est spécifié en mime/type.
 
Ca rejoint l'exemple basique :
 
Sur la route, une nationnalle, il y a un panneau "attention gibier".
Vous avez une chance sur 1 million de voir deux oreilles de lapin sur le tallu. Mais parceque le risque qu'un cerf déboule à deux mètres devant le capot, vous abandonnez votre vitesse de 90 km/h pour rouler à 60, le sens sur le qui-vive, près à freiner d'urgence au cas où une feuille morte aurait l'idée d'émètre le plus petit son en tombant sur un brin d'herbe... Ca s'appelle une recommandation. Pourtant la route est limitée à 90, et c'est mieu de rouler à cette vitesse.
 
On peut reprendre le coup de l'aviation civile, avec un article posté par Hotshot dans une autre catégorie du forum. L'aviation est le moyen de locomotion le plus sur du monde. Les pannes sont extrêment rare, les aéroports bloqués se compte sur les doigts d'une main sur une décénie, et pourtant, ci-dessous les textes de lois applicable au Canada, mais aussi, à quelques détails près, partout dans le monde :
 

 
Ca souligne clairement que même s'il y a une chance sur 1 milliard qu'un problème d'instrument vous empêche de faire una approche dans de bonnes conditions, ou qu'un avion avant vous se soit désagrégé sur la piste d'atterrissage, ou je ne sais quelle autre raison vous obligeant à poursuivre votre vol après avoir atteinds la destination, vous devez disposer de suffisament de carburant pour avoir le temps de vous rendre à un autre aéroport, et même y ratter plusieur fois l'approche.
Ca c'est une recommandation. Jugée tellement important, malgré le risque infime que c'est devenu une lois.
 
Donc moi j'attends celui qui va me faire gober que l'UTF-8 est RECOMMANDE pour faire du XML.

heu tu veux tout encoder en US-ascii ? c'est super pratique pour les accents, etc.
Et pour les caractères chinois etc. tu mets les & suivi des chiffres ?
L'UTF8 je trouve ça le plus pratique pour de l'unicode.
Si on doit stocker juste des caractères ouest-européens, autant prendre l'iso8859

J'ai pas dit que l'UTF-8 ne répondait pas mieu aux besoins. Mais je m'insurge quand on me dit que c'est ce qui est recommandé dans la norme.
Et le problème d'Urd-sama, si c'est bien le même que celui que j'ai volontairement reproduit sur mon serveur, nécessite, dans tous les cas de l'us-ascii, puisque c'est le seul à devoir être lu dans ce cas. En effet, si on ne connais pas le charset réel d'encodage du fichier, on risque pas de pouvoir lire les caractères dans les balises meta, donc elles sont à ignorer.

 
Tu vas quand même pas recommander d'utiliser l'US-ASCII ?  
À la limite dire "le plus sûr c'est US-ASCII", mais de là à recommander d'utiliser ça...