Reprise du message précédent :

 
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...

Moi je ne recommande de rien, je cite simplement la doc.
 
Deplus, recommander le plus petit dénominateur commun a toujours été la véritée absolue quelquesoit le domaine. A chacun de faire en sorte que ce dernier change.
 
Pour info (au cas où )
 
18
10
=> Plus petit dénominateur commun : 2
 
18
9 (donc régression pourtant)
=> plus petit dénominateur commun : 9
 
euh... d'ailleurs, depuis tout à l'heure, je dis une connerie, c'est "plus grand dénominateur commun"
 
Vous aurez corrigé de vous-même
 
Aujourd'hui où on nous casse les oreilles avec le XHTML pour faire des pages compatible avec les navigateurs texte et les aveugles sourds, on n'ira pas me faire gober que c'est pas le plus grand déominateur commun. On ne recommande pas de faire des sites avec des effets visuels en Open/GL et une présentation à la Copland OS (regarder l'anime intitulé "Lain" pour les incultes). Ce serait pourtant vachement plus sexy et sympa à développer. Mais le problème c'est bien l'accessibilité.
 
Hors l'UTF-8 et loin d'être accessible à tous les systèmes...
 
Je rappelle juste au passage d'ailleurs que le XML est prévu à la base pour échanger, par ftp ou http (donc le ftp risque de virer des infos si on passe en mode texte) des données entre serveurs de base de données hétérogènes. Hors entre deux bases, si tu utilises le même charset, t'as beaucoup de pot, et tous les SGBD sont loin de supporter tous les charset pour les intégrer. Donc passer le XML en us-ascii et s'assurer qu'en aucun cas l'information sera corrompue est tout de même la principale préoccupation dans de telles circonstances...

par défaut, c'est us-ascii.
si tu utilise un charset spécifie (sous Windows, de base, c'est le charset windows-1251 pour l'europe de l'ouest) à ce moment il sera enregistré dans ce mode (à condition de passer par l'OS pour accéder au fichier). C'est pour cette raison que tu as très souvent des problèmes d'accent quand tu passes un fichier de windows à ms-dos ou à linux. parceque chacun utilise de base sont propre charset. l'UTF-8 et l'UTF-16 sont les seuls encodage qui permettent de stocker et relire n'importe quel caractère écrit dans n'importe quel alphabet... à condition que tout le long le fichier soit transoprté en binaire, et que tu le lise bien en UTF-x. Sinon, tu vois rien du tout

l'UTF8 c'est de l'ASCII 8 bits tout con, tu le transporte comme tu veux tant que ça reste sur 8 bits, ça passe bien en mode texte (il n'utilise pas de caractères non imprimables pour le stockage des caractères étendus)

Exemple des problèmes d'encodage. (et en quoi ça peut foutre une merde noire en UTF-8)
 
http://stats.manga-torii.com/test.txt
http://stats.manga-torii.com/test.asc
 
Ouvre notepad, et copie ces deux url dans la boîte d'ouverture d'un nouveau document.
 
Les deux fichiers sont les mêmes, enregistrés en UTF-8
 
Le premier est text/text;charset=utf-8 sur le serveur.
Notepad l'ouvre correctement. (enfin... sous XP/2003)
 

 
Le second est text/text;charset=us-ascii (ça peut par exemple être un firewall qui modifie le header pour s'assurer que les fichiers ne peuvent pas contenir du code executable)
Notepad affiche n'importe quoi.
 
Chez moi ça donne :
 

 
On voit tout de suite que les caractères présents dans l'us-ascii sont passés correctement.
 
C'est le plus grand dénominateur commun. En effet TOUS les encodages de texte interprètent correctement les caractères us-ascii.
 
Là où ça merde à mort, c'est surtout le "" en début de fichier : avec ça, c'est bon, le fichier XML est à coup sûr pas valide. Hors, si le fichier ne contenait que du ASCII, alors ces caractères auraient disparus, rendant valide le fichier.
 
PS: pour faire le test, ne passez pas par IE ou même Moz si vous êtes sous Windows : en effet, Microsoft, par souci de simplification, ne respecte pas la norme, et réinterprète lui-même le charset, et retrouve donc le bon charset quand il vous ouvre notepad.

Euh... Non, l'UTF-8 peut utiliser jusqu'à 3 bytes pour stocker un unique caractère (c'est le cas du japonnais)
Deplus, je maintiens que si tu passes par FTP et que tu as la bonne idée de mettre "text" (format par défaut pour un fichier txt entre autre) il va transporter les 7 bits de poids faible, donc ton fichier ne ressemble plus à rien à l'arrivée, même si tu utilises le bon encodage pour le relire.

Dans tes deux fichiers exemple, les deux s'affichent nickel chez moi dans Notepad (les deux sont identiques)... donc je pige pas où tu veux en venir
Mais là tes fichiers sont encodés en UTF8 avec un "header" de 3 bytes qui indique que c'est de l'UTF8.
Or pour un fichier XML c'est pas nécessaire, on l'encode comme du 8 bits classique (ASCII étendu ou un truc du genre), et c'est tout. Là y aura pas de problèmes tant qu'il reste en 8 bits.
 

Et alors ?
il stocke ton caractère japonais en tant que Éüõ (par exemple), je vois pas en quoi ça pose un problème, n'importe quel soft peut le traiter comme du texte
Je lis et écris des données de fichiers XML UTF8 avec un parseur XML qui ne supporte que l'ANSI (chaînes à 1 octet par caractère), ça marche nickel, je les retransforme en unicode dans mon soft par après pour avoir des chaînes WideString où chaque caractère prend deux octets.
 

il transfère pas en 8 bits le mode texte ?

 
Je sais pas ce que tu as fumé, mais c'est très fort ! La seule chose que le mode de transfert ftp texte fait par rapport au mode binaire, c'est convertir le caractères de retour à la ligne dans le format de la machine du destinataire. Pour étre précis, le client et le serveur se mettent d'accord sur le format Unix pour le transport. Autrement dit, entre 2 machines Unix, le mode ftp ascii et le mode binaire se comportente exactement de la même façon.

vous utilisez quel OS ?
moi j'utilise 2K3, et notepad se comporte normalement, c'est à dire qu'il ne retrouve pas le content-type du second fichier.
 
et non, le mode texte tronque tes bytes à 7 bits, plus 1 bit pour la parité. sinon, pour ce qui est des caractères UTF-8 convertis en ANSI, deux problèmes :
 
1) t'es pas à l'abrit qu'un des caractères contienne un < ou un >, ou encore un & (à moins qu'ils aient prévu ça dans la norme, mais j'en doute, ça relève du bricoleur du dimanche)
2) des convertisseurs & #1234; en n'importe quel charset, ça se trouve dans n'importe quelle librairie de n'importe quel langage. Par contre, un convertisseur de "è" en "è" dans un charset donné, c'est déjà plus chaud à trouver... Hors, tu ne peux pas stocker ça dans la base tel quel, puisque si par exemple tu utilise MySQL, et qu'une donnée se termine par "à", ça va donner "à ", hors MySQL a un bug qui fait qu'il vire systématiquement les espaces en bout de chaîne dans un varchar (cf. lien que j'ai donné à simogeo dans son topic sur le type char avec MySQL). A ce moment, l'information UTF-8 est définitivement perdue, et c'est pas le seul exemple. Alors que si tu stockes les caractères encodés à la sauce HTML, tu ne perdra aucune info.
 
Dans tout langage y'a des fonction HTMLEncode et HTMLDecode, c'est pas fait pour les poissons rouges.
 
Surtout que dans tous les cas, il te faudra passer par ces fonctions, puisqu'il faut remplacer les <, & et > par des caractères qui ne risquent pas de faire planter le parseur XML.

J'ai beau récupérer un fichier sous Unix en mode texte sur mon PC sous Windows, il ne me remet jamais en forme les retours à la ligne...

 
Mince, il est grand temps que je me mette au russe moi !

 
J'adore ton type Mime, très créatif, novateur même ! :-)

 
Au contraire, je pense que le problème est là, ton logiciel doit enregistrer ton document en us-ascii 7 bits  et pas en iso 8859-1 (logiciel en version US ?). Tu aurais pas une URL à nous indiquer qu'on aille voir de nous-mêmes ?

j'aime bien l'esprit de ce forum, franchement.
 
on vous emmerde à tout bout de champ "les normes y'a que ça de vrai, faut les suivre à la lettre".
 
t'as la bonne idée d'indiquer qu'une des recommandations d'une des normes est moins bandante qu'il n'y paraît, et systématiquement :
 
- dans un premier temps, on te contredit (j'adore)
- dans un second temps, ça devient "ta" recommandation, "ta" merde, de toute façon tu es un con, et j'en passe.
 
bien... ça occupe mes soirées au moins. si vous avez rien de mieu à foutre que de vous mettre des oeillères et d'imaginer que tout est beau dans le meilleur des mondes possible, c'est votre problème. moi je bosse pas de cette façon, désolé y'a une phase qui s'appelle étude dans un projet. quand vous aurez écrit une superbe application qui marche super bien sur votre serveur et qui sera incapable de tourner sur le serveur de production, vous irez demander à l'administrateur du serveur de prod de modifier la moitiée des paramètres pour vos beaux yeux, et changer la configuration de la moitiée du parc informatique de l'entreprise... continuez à croire qu'un P4 avec linux c'est un serveur, et qu'une appli utilisée par 20 personnes c'est une appli client/serveur de grande envergure, et qu'un superbe réseau de 50 machines c'est un réseau "d'entreprise". marquez d'un point vers votre CV, que je sâche la prochaine fois qu'on me consulte pour une ambauche à vous écarter des projets sur lesquels je travail.

 
"The ASCII character set is not sufficient for a global information system such as the Web, so HTML uses the much more complete character set called the Universal Character Set (UCS), defined in [ISO10646]. This standard defines a repertoire of thousands of characters used by communities all over the world."
 
http://www.w3.org/TR/html401/charset.html#encodings

 
Putain, t'as des yeux derrière la merde que tu as devant ?

 
Bah non, c'est toi qui en as plein les yeux et qui est tellement omnubilé par tes problèmes de xml que tu ne vois rien d'autre :
"J'ai un petit problème avec la validation d'un simple fichier XHTML."
 
Et que comme le html, le xhtml dépend de la RFC2646, pas de la 3023 car il est toujours envoyé en text/html, s'il était envoyé en application/xhtml+xml là tu aurais raison ("By virtue of all XHTML content being XML, it has the same considerations when sent as 'application/xhtml+xml' as does XML) mais les chances pour que ce soit le cas sont infimes puisque dans ce cas IE serait incapable de les afficher.

bon j'ai pas tout lu votre débat sur les charset, mais je récapitule ce que j'ai compris et le but de la chose.
Le but c'est que je suis en train de terminer une introduction XHTML pour noobs et à la fin je parle de la validation XHTML. pour ca, j'ai mis un code tout fait pour que le noob puisse tester, et que ca donne juste.
Donc je ne peux pas l'uploader sur un serveur dans le cadre de cet exercice.
ensuite, si je veux m'en sortir, je dois mettre les codes html pour les accents? et comment expliquer en langage noob le pourquoi de la chose?

 
et mes accents, comment ils sont transmis alors
 

 
t'as lu la doc ? il n'utilise que les caractères au-delà de 128, donc justement pas de problèmes avec ça
 

 
mais de quoi tu parles ? je vois pas le rapport avec les espaces... on s'en fout des espaces, je vois pas le rapport avec l'UTF8. Puis la conversion UTF8<->Unicode/WideString, à mon avis tous les langages qui gèrent l'unicode gèrent aussi cette conversion (perso je m'en fous, je ne programme qu'en Delphi, et là y a UTF8Decode et UTF8Encode )
 

 
non pas tous, pas en Delphi ni en C++Builder en tout cas o
 

 
heu ça c'est le parseur XML qui s'en charge hein ! m'enfin Quel parseur foireux tu utilises ?
 

 
faut dire que quand tu présentes des choses, au premier abord ça ressemble toujours à du grand n'importe quoi, là par ex quand tu me parles d'UTF8 on dirait que tu ne sais même pas comment c'est encodé
 

 
ça y est, t'es reparti dans ton trip

Hum...
 
si Content-Type = text/xml :
encodage recommandé = utf-8 ou utf-16
encodage par défaut = us-ascii
 
RFC 3023
 
Je sens un malentendu sur ces deux termes.

je vois pas comment en toute logique on peut recommander quelquechose qui n'est pas la valeur par défaut, surtout si cette dernière n'est pas compatible avec ce qui est recommandé.
 
je crois que certains ne maîtrisent pas la langue française si la grammaire des normes. y'a une différence entre recommandé et conseillé, préféré. ça ne veux rigoureusement pas dire la même chose, mais alors VRAIMENT pas du tout.
 
donc si on parle pas la même langue, on pourra jamais se comprendre. toujours est-il qu'il est impossible que l'UTF-8/UTF-16 soit RECOMMANDE par la norme si c'est l'us-ascii qui est utilisé par défaut.

je dois faire quoi moi alors    
arrêtez de vous engueuler sur mon topic bordel  

MagicBuzz > As-tu au moins relu la RFC ? (section 3.1 : Text/xml Registration)
Urd-sama > Si tu souhaites réellement valider ton contenu par W3C, encode-le en us-ascii. Ton système ne renvoie probablement pas au validateur le bon encodage de ton fichier uploadé sur le serveur (s'il en envoie un). C'est pourquoi il voit ça comme du us-ascii.

merci
vais tenter de finir le rapport avec ca

 
- Recommandé : encodage à utiliser dorenavent dans toute nouvelle solution
- Utilisé par défaut : encodage choisi purement pour raison de compatibilité avec l'existant. cf obsolete, déprécié, banni

Toi aussi, lis la RFC.
Par 'par défaut', ils sous-entendent quand l'encodage n'est pas spécifié, s'il est faux ou s'il n'est pas supporté.

 
Je sais bien ça, mais on pourrait se demander pourquoi ils n'ont pas choisit l'encodage recomandé comme encodage par defaut. La norme ne dit pas qu'il faut toujours indiquer l'encodage utilisé ?

1. Je ne sais pas. Peut-être que ça a été dit plus haut dans ce topic, mais je n'ai plus envie d'y regarder. Cette discussion commence à m'embrouiller.
2. Tu n'es pas obligé d'indiquer l'encodage, mais c'est fortement recommandé.

 
Pour connaître facilement ce qu'envoie ton serveur, tu charges la page avec Mozilla/Netscape/Firebird et tu tapes CTRL + I